What is the best/correct way to set up automatic deployment of a Docker container on a Swarm cluster?

Question

Continuous Delivery

Good afternoon.
I'm setting up a test environment to automatically deploy containers on a cluster. There is a question how to configure correctly. The TeamCity agent collects the sources, tests, builds the container and puts it in the registry. Further a question how to lift it on a cluster?
Option 1. Using standard docker tools:

export DOCKER_HOST=swarm-master:4000
docker run -d -p 1234:1234 --name my_application --label my_application registry/my_application:${version}

Option 2. Docker-compose:

export DOCKER_HOST=swarm-master:4000
docker-compose up my_application

Option 1 is good because it works. But there is a problem with stopping services if there are several of them, plus the deployment config is written in TeamCity.
Option 2 is good because the deployment config is written in the project itself, but there is a problem with the launch. The service does not start from the TC agent ( Error response from daemon: failed to parse pool request for address space "GlobalDefault" pool "" subpool "": cannot find address space GlobalDefault (most likely the backing datastore is not configured) ). Though by the machine from a cluster it is launched. Where to dig? connect to cluster master copy docker-compose.yml there and run there? or docker-compos should work fine with the remote cluster?
UPD:
Problem with failed to parse pool request for address space"managed to solve. (It was necessary to add --cluster-store consul://consul-host:8500 --cluster-advertise eth0:2375 to the config of all cluster daemons")
The application is rising, but there was a problem with Reschedule:

restart: unless-stopped
    labels:
      com.docker.swarm.reschedule-policies: "[\"on-node-failure\"]"

when a node crashes, the container is successfully transferred to another one, but does not start...
UPD2:
The problem with Reschedule turned out to be that I turned off the machine on which there were both the SWARM node and the CONSULa node. If you cut down the machine on which there is no consul, then the service rises normally...

Answer 1

https://habrahabr.ru/company/hexlet/blog/258815/

Answer 2

As a result, the problem was solved by a self-written deployment script. It also solved the problem with zero down time, cutting down the old container and raising the new one in turn