You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I noticed that on the latest multicontainer docker env on AWS with ecs agent in version 1.17.2 the container id is empty and this ends up in empty upstream blocks for my nginx config in nginx-proxy container which uses docker-gen. Starting from ecs agent 1.16 the letsencrypt comapanion was not able to get its own container id, so it started supporting the ECS_CONTAINER_METADATA_FILE variable which holds the containerID in very simply way (it is a JSON file). My question is why similar approach can not be used here instead of attempts of doing the regexp matching on the /proc/self/cgroup? We could simply check if ECS_CONTAINER_METADATA_FILE is defined and use it for fetching "ContainerID".
The text was updated successfully, but these errors were encountered:
Hi,
I noticed that on the latest multicontainer docker env on AWS with ecs agent in version
1.17.2
the container id is empty and this ends up in empty upstream blocks for my nginx config in nginx-proxy container which uses docker-gen. Starting from ecs agent1.16
the letsencrypt comapanion was not able to get its own container id, so it started supporting theECS_CONTAINER_METADATA_FILE
variable which holds the containerID in very simply way (it is a JSON file). My question is why similar approach can not be used here instead of attempts of doing the regexp matching on the/proc/self/cgroup
? We could simply check ifECS_CONTAINER_METADATA_FILE
is defined and use it for fetching "ContainerID".The text was updated successfully, but these errors were encountered: