I'm struggling to understand the docker context documentation as it compares to my real-world experience so far.

I thought it would be interesting to see if I could quickly and easily convert a docker-compose.yml file to a running application stack on a server somewhere. Ideally I could simply upload the file to a repo somewhere but, in any case, the most oft-suggested solution was the aws-ecs docker compose integration.

According to this documentation, the process is

1. Have a given docker-compose.yml locally on your machine
2. Using a combination of aws cli and docker context , use docker cli commands to deploy the containers to aws ecs

The critical command seems to be docker context use {{name}}. Here's where I'm confused.

I successfully deployed a container stack to ecs (apparently, I have no idea how to see this in aws UI, but the app is available at a URL so it worked. I hope I'm not being charged...), but then, I wanted to do some local development on another project.

I opened another terminal and tried to run docker commands. Apparently, the docker context persisted, so I had to docker context use default to switch back. When I did that, my deployed app crashed. I switched back to another terminal, did docker context use {{name}}, and now even though my local development containers for another app are seemingly running, requests to them fail on all ports.

Am I to understand that the deployed container stack on amazon ECS is dependent upon some status of my local machine? What about when I turn this machine off? I can't do any other docker development now? If that's true, is there some better way to use the docker ecs integration, because obviously that's basically unusable if that's all true.

CodePudding user response：

docker config context use records the context name in a configuration file (on my current MacOS/Docker Desktop system, in $HOME/.docker/config.json). So changing the context this way changes it for all shells in all terminal windows.

Docker also supports a $DOCKER_CONTEXT environment variable, and like all environment variables this will be local to the current shell. If you're trying to use this support to deploy to a cloud environment then setting the environment variable only for the commands that do the deploy might be a good idea.

export DOCKER_CONTEXT=ecs
docker-compose up -d
docker ps -a
unset DOCKER_CONTEXT

I'd be very surprised if the deployed ECS application had any dependencies on your local system, or if running docker context use locally caused your cloud-hosted application to break. The context setting only affects what Docker daemon or other API endpoint local docker commands talk to; it doesn't make any persistent changes outside of your immediate system. The ECS application probably doesn't know anything about your local system (unless you've included its DNS name in environment-variable settings or similar configuration) and may not even have a network path to call back to it.