Compiles ok but wont connect to dynatrace at runtime - any help gladly accepted

[sorenlloyd]

I can successfully compile my dynatrace based spring boot application now. I can see it use the bindings to get the oneagent from the DT saas server.

My problem is at runtime, i don't think it is then successfully using the bindings to connect to dynatrace.

Do i need to set environment variables to make it connect to my dt server with the api key?

We are deploying in GCP cloud run

Any help gladly accepted - in cloud run it is pertty much impossible to examine the oneagent log - i did look at the container that was created and the one agent dynatrace-env.sh does not look set up

[sorenlloyd]

i can confirm that to make it work i had to go to

https://myserver.live.dynatrace.com/api/v1/deployment/installer/agent/connectioninfo

I then took the tenantUUID, tenantToken and formattedCommunicationEndpoints and set them into DT_TENANT,
DT_TENANTTOKEN and DT_CONNECTION_POINT.

Once i set these env vars it worked.

I think these should really be set in the layer - any chance we can fix?

[dmikusa]

I think these should really be set in the layer - any chance we can fix?

We specifically do not set these in the layer because they are secrets and you do not want to put secret information into a container image, as it will be very easy to leak that information.

If you want to push them into the container image regardless, you can do that with the environment variables buildpack. See https://paketo.io/docs/howto/configuration/#image-embedded-environment-variables.

The intended workflow in a nutshell is this:

1. You provide your binding when you build the image. The bindings are defined here -> https://github.com/paketo-buildpacks/dynatrace?tab=readme-ov-file#behavior
2. You need to provide the same binding information at runtime. There is a small helper that will take the binding information and translate that to the DT_* env variables in memory.

You can set the environment variables directly at runtime if you prefer that approach. Using bindings is recommended, as these are typically a bit more secure (although that depends on your container orchestrator).