Is this question somehow related to how any particularities of Amazon Web Services; or are you asking about how to deploy to a Docker Swarm (running Swarm Mode) in general?
We’re running a self-hosted self-managed Docker Swarm (in swarm mode) and deploy using a combination of Jenkins, Python and SSH. I can’t speak for managed solutions, but for solutions which you manage yourself you somehow need to bridge the gap between (1) having built your code artifacts and (2) have those code artifacts run in production.
The managed solutions out there probably handle this for you in some way, but as far as I can tell there is no (self-hosted) “out of the box” software which handles the “I have all these images in my local Docker repository and now I want to deploy one of these images to a Docker Swarm”. Rundeck is - to my knowledge - the closest thing you get to this but you still need to set up deployment jobs. After all, it’s a generic piece of software.
What we do right now is that we build code artifacts and a Docker image for the artifact(s) in the same build job using Jenkins, and then have Jenkins to push that image to a local docker registry. Jenkins then log on (SSH) to each swarm node, pull the image, and updates the swarm service with that image. You could probably skip that SSH step if you don’t mind exposing dockerd on the Docker nodes’ network interface. We do this for staging.
We deploy to production using Jenkins as well, but then it’s just a matter of having Jenkins to log on to the production swarm, pull the same image we initially built for staging (we need to configure the Jenkins job for this on each deploy to make sure we deploy the correct image) and that’s it.
We’re still working on this setup. I’d say Rundeck would be much better for deploying to production, because you can have rundeck to fetch available images from the registry and present that in a GUI, and then consequently log on to each Docker node and run a script which will pull that image and update the service. It probably takes a little work, but then again most things do.
P.S. : We mostly use the REST API exposed by dockerd, as you get more functionality here. The docker client often lags behind and does not necessarily implement all the functionality you get via the REST API. Examples of this is network scoped additional DNS entries for services, meaning that a service can be assigned multiple hostnames within a given overlay network - and not just the default service name. This made a big difference to us, and is not supported by the docker client.