Furthermore this is run as part of a Preview Environment (PR #7). Also I’ve tested the fluent-bit configuration locally using Docker compose and it listens for incoming tcp traffic and works fine.
I think the issue may be with the dockerCommand set in the Blueprint. The Docker Command in a service notes:
Add an optional command to override the Docker CMD for this service. This will also override the ENTRYPOINT if defined in your Dockerfile.
As it’s overriding the CMD and ENTRYPOINT, the command you’ve set in the screenshot doesn’t appear to run anything? Maybe it needs to be prefixed with /fluent-bit/bin/fluent-bit as shown in the original image?
Adding the /fluent-bit/bin/fluent-bit explicitly in the render.yaml indeed causes it to now launch. So thank you for the help, but I want to mention that this does illustrate some shortcomings with the platform:
It should pass errors from the docker daemon back to the developer so he/she can debug the issue themselves. Instead of showing an opaque “Exited with status 128”
The behaviour of needing to provide the executable explicitly in this situation diverges from the behaviour of how docker handles it. i.e: docker run <the_image> -i tcp -o stdout works just fine. As does docker compose
Thanks for the update and glad to hear you got it working.
Also thank you for the feedback:
I agree, and we’re always working to improve logging to help customers self-diagnose/resolve.
The Render dockerCommand is noted as overriding both CMD & ENTRYPOINT, so a fully-formed command would be required. The majority of Render Docker configurations I come across are done at the environment level (vars or secret files), then the optional dockerCommand doesn’t need to be set at all, using the CMD/ENTRYPOINT as set in the image. I’m not familiar with Fluent Bit, so I’m not sure if that style of configuration is possible, but I will pass on your feedback here.