Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Docker Swarm with image versions externalized to .env file

I used to externalized my image versions to my .env file. This make it easy to maintain and I don't modify my docker-compose.yml file just to upgrade a version, so I'm sure I won't delete a line by mistake or whatever.

But when I try to deploy my services with stack to the swarm, docker engine complains that my image is not a correct reposity/tag, with the exact following message :

Error response from daemon: rpc error: code = 3 desc = ContainerSpec: "GROUP/IMAGE:" is not a valid repository/tag

To fix this, I can fix the image version directly in the docker-compose.yml file. Is there any logic here or it that a bug? But this mixes fix part of the docker-compose and variable ones.

Cheers, Olivier

like image 694
Olivier Avatar asked Jun 22 '17 08:06

Olivier


People also ask

How do I override an .ENV file?

Overriding a single value in your docker-compose . env file is reasonably simple: just set an environment variable with the same name in your shell before running your docker-compose command.

Is docker swarm mode deprecated?

Docker Swarm is not being deprecated, and is still a viable method for Docker multi-host orchestration, but Docker Swarm Mode (which uses the Swarmkit libraries under the hood) is the recommended way to begin a new Docker project where orchestration over multiple hosts is required.

Is docker swarm still supported?

Users of Docker EE managed services should transition from Swarm to Kubernetes, because Swarm will not be supported in Docker EE in the future.

What happens by default when a docker service image is updated?

By default, when an update to an individual task returns a state of RUNNING , the scheduler schedules another task to update until all tasks are updated. If, at any time during an update a task returns FAILED , the scheduler pauses the update.


1 Answers

you can create a deploy.sh

export $(cat .env) > /dev/null 2>&1; docker stack deploy ${1:-STACK_NAME}
  • The .env parses without regular expressions or unstable tricks.
  • Errors on stderr produced by #comments inside the .env will be redirected to stdin (2>&1)
  • Undesired prints of all export and error now on stdin too, are redirected to /dev/null. This prevents console flood.
  • Those errors do not prevent .env being parsed correctly.

We can define STACK_NAME in our .env but we can also pass our customized stack_name

. deploy.sh <stack_name> (stack_name opcional)

This workaround gave me headaches for 3 nights

like image 170
mrcbns Avatar answered Oct 19 '22 03:10

mrcbns