为何AWS Elastic Beanstalk中X-Ray daemon需作为扩展而非运行在Docker容器内

结论 #

可以直接将X-Ray daemon运行在应用所在的Docker容器内，该方案可正常运行，但不属于Elastic Beanstalk环境下的官方推荐实现方式，两种方案各有适用场景。

同容器部署的实现步骤 #

• 修改你的应用Dockerfile，添加X-Ray daemon的安装逻辑：如果使用Amazon Linux 2作为基础镜像，可直接执行yum install -y xray完成安装；其他发行版可导入官方预编译的X-Ray daemon二进制包。
• 配置容器启动逻辑，同时托管应用进程和X-Ray daemon进程，建议使用supervisord这类进程管理工具避免出现僵尸进程，保证任意进程崩溃后可被正确重启。
• 为Elastic Beanstalk关联的EC2实例角色附加AWSXRayDaemonWriteAccess权限策略，保证daemon有权限上报追踪数据到AWS X-Ray服务。
• 应用侧的X-Ray SDK无需额外修改配置，默认发往127.0.0.1:2000的追踪数据会直接被同容器内的daemon接收。

两种部署方案的差异 #

官方推荐将X-Ray daemon作为Elastic Beanstalk扩展运行，核心优势是daemon的生命周期完全独立于应用容器，应用重启、崩溃都不会影响daemon的运行，也不会占用应用容器的资源。如果是多容器部署的Elastic Beanstalk环境，主机上运行的单份daemon可以供所有应用容器共享，资源利用率更高。

同容器部署的适用场景 #

• 你使用的是Elastic Beanstalk单容器Docker部署模式，不想额外编写扩展配置文件
• 你需要保证本地开发和云端部署的环境一致性，本地直接运行应用容器即可获得完整的X-Ray追踪能力，无需额外在本地启动daemon进程

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