4 ms·
It feels downplayed in this article, so I would like to state for the record here, I am a happy user of Docker Swarm. Swarm has been shown to scale to tens of
by raarts 9y ago
It feels downplayed in this article, so I would like to state for the record here, I am a happy user of Docker Swarm.
Swarm has been shown to scale to tens of thousands of hosts, but I found it easy to start with, especially with the Gitlab CI support, which natively brings a Docker container registry.
So I commit, CI builds my containers, stores them in my private registry, and automatically deploys from there to the Swarm in various environments. All this was much easier to setup than the alternatives.
Also, I expect an easy transition should I need to move to Mesos or k8s. If I ever need to. In the mean time I like to keep it simple.
- Dawny33 9y ago*Marathon on Mesos. :P
- sandGorgon 9y agoI'm also a user of Docker Swarm - and I love it! I have extensively played with k8s and feel it has a lot of upfront complexity (especially ingress). I feel people who are beginning to scale from one machine to 10 will love Docker Swarm (and stick with it). While those who have about 100 machines will start with Mesos/K8s.
- gtaylor 9y agoThere's no direct migration path from Swarm to Kubernetes, so we chose to start out at a small scale with the latter. It was enough of a leap to fundamentally change how we were building and deploying things. We didn't want to do it twice! You can dodge much of the operational complexity in standing a cluster up by starting with Google Container Engine or a provisioner like kops. Once you have enough comfort, you can get more fancy and build something more customized to your cases.
- sandGorgon 9y agoactually - i think the other way. I'm not sure if people who start with Docker Swarm will want to migrate to k8s at all. It works damn well and i have been very happy with it. It has been demonstrated to work at scale. K8s does have Google behind it though
- lucaspiller 9y agoHow do you automate the updating of images on Docker Swarm?
- snorremd 9y agoI can't talk for the original poster, but I also deploy containers from Gitlab Registry via Gitlab CI pipelines and just use the standard docker swarm commands. So updating the image digest (version) of a service is as simple as running a shell command in a job in a deploy stage in your gitlab ci pipeline: docker service update --image <some-image:version> --with-registry-auth <some-service> Simplest example would be a job definition like this: https://pastebin.com/KsG0cDzR https://pastebin.com/KsG0cDzR This job would have to be preceded by building the new docker image you are going to update to of course.
- conradk 9y agoWhat I've found to work well is to push images to your registry with a different tag for each release. For instance, you have "web:1.0" running in production and want to update? Create a "web:1.1" image, push it to your registry and in Docker Swarm, point your "web" service to the "web:1.1" image instead of "web:1.0".
- raarts 9y agoI define a docker stack .yml file, and have GitLab CI run docker stack deploys.
- coding123 9y agoI do this: docker build -t $APPNAME:$timestamp . OUTPUT="$(docker service inspect -f '{{.Spec.Name}}' sv-$APPNAME || true)" if [ "$OUTPUT" == "" ]; then # Service does not exist echo "Creating service" docker service create --update-delay 5s \ --publish $PUBPORT:8080 --replicas 2 \ --mount type=bind,source=$(cd ../images; pwd),target=/images,readonly=true \ --mount type=bind,source=$(cd ../processed_images; pwd),target=/app/images \ --mount type=bind,source=$(cd ..; pwd)/config.json,target=/config.json,readonly=true \ --mount type=bind,source=$(cd ~/.aws; pwd),target=/root/.aws,readonly=true \ --name sv-$APPNAME $APPNAME:$timestamp else # Service exists echo "Updating service" docker service update --image $APPNAME:$timestamp sv-$APPNAME I haven't looked in a while, but it would be nice if they had some kind of "upstall" (update/install) kinda like upsert (update/insert) in CRUD land.