We were using docker up to about a year ago, and ripped it out for just this reason - we didn't have the time available to keep coding the workarounds. Great if you have the time, not so great if you don't.
We were too deep in already unfortunately, but 1.10 introduced a whole new barrage of bugs and regressions, wasting hours and days working around it. If they don't devote some time getting the basics right and getting the core stable, we need to really consider alternatives. I'm already scared what 1.11 will break.
Please make sure to report any issues so they can be fixed.
> DNS round robin load balancing: It’s now possible to load balance between containers with Docker’s networking. If you give multiple containers the same alias, Docker’s service discovery will return the addresses of all of the containers for round-robin DNS. wait wait wait. I'm kind of new into docker world. And so far i've been struggling in understanding how to replicate a container in order to scale. For example…
You can use nginx to have zero-time redeployments without gross hacks haproxy requires to do that.
I would also recommend nginx. For pure proxying it's rather convenient, and offers some nice high level caching if you desire it.
> DNS round robin load balancing: It’s now possible to load balance between containers with Docker’s networking. If you give multiple containers the same alias, Docker’s service discovery will return the addresses of all of the containers for round-robin DNS. wait wait wait. I'm kind of new into docker world. And so far i've been struggling in understanding how to replicate a container in order to scale. For example…
Why load balance three copies of a container on the same server? Just set your cpu and memory constraints to what you need for one.
> (is this the right approach btw?) This is why I use hipache for load balancing / routing - it is the only solution I've found where you can change the routing or add new backends in a live system without any downtime. Here is the main problem though: Its load balancing isn't exactly smart, for example it won't keep the same client IP on the same replica, thus creating problems when a client writes something on one…
you might want to take a look at fabio: https://github.com/eBay/fabio
I love Fabio. The Consul stack in general is fantastic.
Been watching #consul IRC for a while now though, and the vast majority of the setup problems are due to Docker's weird networking and security. Fabio/Consul run like a charm but Docker throws a wrench in the machine.
Or simply use containers technology that's been around for a decade and is battle tested and stable, like FreeBSD Jails - https://www.freebsd.org/doc/handbook/jails.html Linux is not the only OS around, and Docker is not the only container technology available, that's important thing to remember.
Thing is, on top of being stable, it should be useful . If you're using containers just for your own code - fine. If you mix and match other repos and ecosystems like we and many others do, good luck with FreeBSD. 60% of the time, interesting repos already have a Dockerfile and if they don't, it's usually pretty easy to write one. With FreeBSD containers, I'd have to do all the wiring myself - if and only if it even…
Well, sure, but how is that different from writing workarounds for all these Docker quirks? At least you end up with self-baked solution based on stable technology, instead of self-baked solution for unstable technology.
And when it comes to software, its hard to find one that doesnt work on FreeBSD (there's over 24k of precompiled packages available!), not to mention FreeBSD's Linuxulator, that is Linux kernel emulation, built in, so that sentence may be considered spreading a FUD.
This is a huge upgrade that is super welcome. Recently (on 1.9) we have seen quite a few cases where we had "zombie" containers, these are container that can no longer be started or stopped due to cgroup misconfiguration or something along those lines. The new architecture means that for weird cases like this all we need to do is kill off runc without forcing every container on the box to restart (by restarting the d…
I particularly like that in addition to refactoring the architecture, they worked on stabilization.
> With the containerd integration comes an impressive cleanup of the Docker codebase and a number of historical bugs being fixed. In general, splitting Docker up into focused independent tools mean more focused maintainers, and ultimately better quality software.
> A few months ago we added the ability to sign images with hardware Yubikeys in the experimental channel of Docker. This is now available in the stable release. I understand that you used to have to install a separate version of Docker to access this feature, but does the change in 1.11 also mean you no longer have to set the DOCKER_CONTENT_TRUST environment variable, or will that be made default at a later time?
Still need to either set the envvar or pass the equivalent flag.
> DNS round robin load balancing: It’s now possible to load balance between containers with Docker’s networking. If you give multiple containers the same alias, Docker’s service discovery will return the addresses of all of the containers for round-robin DNS. wait wait wait. I'm kind of new into docker world. And so far i've been struggling in understanding how to replicate a container in order to scale. For example…
Why load balance three copies of a container on the same server? Just set your cpu and memory constraints to what you need for one.
you got a point indeed. My idea was to handle more things in parallel for services that are not heavy in resources. such as a service that checks the auth of a user from a ID/Key. anyway, with the swarm I could put the containers in various machines.
> DNS round robin load balancing: It’s now possible to load balance between containers with Docker’s networking. If you give multiple containers the same alias, Docker’s service discovery will return the addresses of all of the containers for round-robin DNS. wait wait wait. I'm kind of new into docker world. And so far i've been struggling in understanding how to replicate a container in order to scale. For example…
Yes, for ex:
docker run -d --name web1 --net prod --net-alias web
docker run -d --name web2 --net prod --net-alias web
resolution for 'web' will return IPs of both the containers. You might still have to watch out for the DNS caching at the application level.