Best practice and details in container

[svrooij]

For my new project IdentityProxy I need the hostname and the assigned port set as a environment variable on the container itself.

In the best practice it says that I better use the _container.Hostname and that I should not assign a static port. Is it possible to set an Environment variable in the container with some sort of template?

Like .WithEnvironment("EXTERNAL_URL", "http://{container-host}:{assigned-port}") or is it possible to know the port and the hostname that will be assigned before the container is created?

The port part is currently fixed by:
https://github.com/svrooij/identityproxy/blob/5cc583ffc5cd67a57b85abe3ea35fd4f007333e9/Testcontainers.IdentityProxy/IdentityProxyBuilder.cs#L47-L52

But that does not follow the guidelines on the hostname.

Background is that I'm returning a metadata url (for authentication) where I want to change a single entry jwks_uri to point to the container, hence the fact it needs the url where it's reachable from the tests.

[HofmeisterAn]

If the service running inside the container needs to know the randomly assigned host port, it usually requires modifying or adjusting the entrypoint and the container startup configuration. For example, Kafka has similar requirements, and we use the following configuration for it:

testcontainers-dotnet/src/Testcontainers.Kafka/KafkaBuilder.cs

Line 82 in a0f1f76

startupScript.Append("export KAFKA_ADVERTISED_LISTENERS=PLAINTEXT://" + container.Hostname + ":" + container.GetMappedPublicPort(KafkaPort) + ",BROKER://" + container.IpAddress + ":" + BrokerPort);

This allows multiple Kafka instances to run simultaneously without encountering any port clashes. Hope that helps.

[HofmeisterAn]

I'm however afraid it won't work because of the fact that it's one of those new "chiseled" containers (which by design don't even have bash 💪)

This might be a bit tricky. The randomly assigned host port is available only after the container starts. The startup order is as follows:

1. Create the container
2. Start the container
3. Wait until the ports are mapped
4. Call the startup callback (WithStartupCallback(Func<TContainerEntity, CancellationToken, Task>))
5. Wait until the readiness check completes

You can upload files as we do in the Kafka configuration in step 4, but you need to keep the container running somehow and then start the actual service. By the way, you can even copy files to created containers (not just to started ones).

If you figure out a working approach, I am curious to know how you did it.

[svrooij]

This seems to work: https://github.com/svrooij/identityproxy/blob/94c836d14071f920b20b5642bbe9bc5e65c95ae0/SvRooij.Testcontainers.IdentityProxy/IdentityProxyBuilder.cs#L68-L82

The dotnet api that is actually running, by default, will reload if the config files change. By only injecting the absolute necessary (43 bytes on average), it injects the files fast enough for the api to just start, (and then tries to load an url in the readiness checks, which will only return something if it has the correct configuration)

https://github.com/svrooij/identityproxy/blob/main/IdentityProxy.Api/Program.cs

[HofmeisterAn]

Ah, I see. My assumption was that you needed the setting right at the start of the app, but making it a runtime setting and utilizing the reload mechanism is a good idea. If reloading the settings is properly implemented, this could be a good general approach.

[svrooij]

Being able to have it right at the start would be nice for some use cases, but when working with dotnet you have the refresh mechanism.

Would it be possible for it to create (but not start) the container, then add a file with the callback and then start it and run the wait for ready part? In docker this is possible, just not implemented here?

[HofmeisterAn]

Would it be possible for it to create (but not start) the container, then add a file with the callback and then start it and run the wait for ready part?

Yes, this is possible, but not with the startup callback. You can add files to a container before it starts using the resource mapping API. However, be aware that you cannot get the randomly assigned host port here; for that, you need to start the container first.