Just wondering if anyone uses docker compose/swarm on production. From most of my colleagues experience they seem to shy away from it and choose Kubernetes.
I personally like using Docker-Compose to set up the local development environment and using Minikube just adds another language and layer of complexity but at least it is closer to what production is using.
However, I haven’t really heard much evidence as to (as of current versions of docker, … why not?)
The only thing I can think of is on Windows they have a race condition with their volumes and the machines that use them (I haven’t verified if it happens on Linux, but as of this moment single node Docker on Windows machines with volumes are not restartable).
I am in charge of a project that started experimenting with Docker Swarm mode; we thought Kubernetes to be a lot of trouble to get going, and swarm mode gave a lot of the same thing, right? Not so much. Swarm mode turned out to crack and be tough to manage and get it to do what we wanted when load went up. We changed over to OpenShift (Kubernetes) and have not looked back. Entering production shortly. Looks good.
Can you elaborate on the cracks? I know Swarm mode does not do anything like automatically spawning off replicas and removing them at least not with what came with it.
I also know that Swarm mode cannot get the actual IP address of the source, you get a virtual IP which prevents you from using GeoIP analytics.
I might be a little off-topic but we will use Swarm (classic mode) in production and we are very pessimist for now. We always had to update to latest (stable) and there are still problems even now (mostly overlay network issue, inconsistent container list, endpoints, etc.). There are always workarounds but stil…
Maybe latest Swarm mode is better.
We are using almost latest Swarm image 1.2.6 and almost latest docker-ce-17.06.0 in CentOs 7.3. All of this was latest a month or two ago. Also, Swarm classic mode is still maintained.
Sounds scarily bleeding edge. Given that if you had a cloud provider it may be more cheaper to just have individual machines rather than risking things with images.
Are we comparing Docker CE with commercial OpenShift? To be fair a comparison should be done for Docker EE and OpenShift, where vendor support is available to solve issues.
There are already enough large-scale Swarm production sites that testify its maturity. Me myself I stick to Swarm for as long as I can (a lot easier and a much much much better deployment model), and so far none of my customers had to change afterwards.
I am thinking more of Docker Compose with swarm mode but generally whatever production environment. Of course I would like to see the parity with the development environments too so having everything managed I would say is not scope of this discussion.
My point is that EE is the equivalent of LTS in Docker.
People here described production issues in larger environments. Switching
to k8s will likely be changing a set of problems for another.
Distributed systems are inherently hard on their own. Even Swarm or k8s
will not be a magic box - whatever you choose (and I choose Swarm always,
for the compose/Swarm experience is great) you should bring along (and
build knowledge on) tools & techniques. Debugging and troubleshooting is
this world is hard, but worth it.
At some point vendor support should make sense. I insist on the subject
because blaming the product and switching is a never ending loop - unless
you are really sure the product is broken.
I think the problem that people that abandoned docker in the earlier versions was that it was an immature 1.0 product and expecting it to work with no issues from the product for their happy path scenrarios.
For myself I found that having something simple as work after a restart and having a race condition with the volume mounts not being mounted on time for the container to pick up speaks a bit to the quality of the product.
For analytics losing the source IP information prevents geoip in the analytics instead a work around where a web server that is not containerized has to extract and pass the data down or utilize some request ID correlation from google analytics.
However i don’t have much experience with k8s so it may also have the same issues. My experience with k8s has been less than stellar in terms of being intuitive compared to docker compose with swarm.
I agree. But docker/swarm technology is new. I mean, lots of features appeared in 2017! In a few years, I think docker will be really stable and mature (as mature as VM technology for eg).
Over last few months we’ve moved our build infrastructure (Jenkins slaves, Gitlab CI runners, Prometheus\Grafana stack, etc) from VMs to Docker containers, and now in the middle of moving them to swarm \ stack mode.
Our scale is not that big though - about 100 Xeon cores in total, locally hosted.
We use Ubuntu 16.04 LTS and Windows 2016, and indeed Windows stability is lacking behind, but my perception is that it’s improving.
You mentioned Windows containers not restarting after reboot - we got that in the past. Problem with HNS starting slow. Which I see as problem on the Windows (Hyper-V) side, rather than Docker. Especially as we know Windows loves to reboot so often.
Anyway with the latest version (17.06.2-ee-6) and delayed start for Docker service (sc.exe Config Docker Start= Delayed-Auto) problem seems to be gone.
I absolutely love the simplicity and power of docker compose\stack and swarm. And the fact that “batteries are included” - just install Docker engine, and you’ve got swarm and stack built-in.
I’m really impressed with the recent announcement that docker-compose syntax and Kubernetes YAML will be both supported in Docker EE, with ability to deploy either of them to swarm or k8s.
IMHO I would stay with Swarm for as much as it suits us, as my favourite Agile principle is: “Simplicity - the art of maximizing the amount of work not done - is essential.” But then again our scale is not huge, and we don’t require auto-scaling features.