> CoreOS is an operating that can only run Docker and is exclusively intended to run Docker. This is a patently false statement and needs to be revised, especially given: > I will not comment on it. P.S. I'm getting downvoted for speaking the truth, no matter how pedantic it may seem. CoreOS can run rkt containers and is not exclusively intended to run Docker. One possible reason is because Docker is the 800 lb. gori…
Docker in Production: An Update
21–30 of 97 posts
Re: Docker in Production: An Update
#22Second part TLDR - "If you are locked-in on Docker and running on AWS, your only salvation might be to let AWS handles it for you.". Use Docker-For-AWS that sets up Cloudformation + Swarm mode.
Google offers containers as a service, but more importantly, as confirmed by internal sources, their offering is 100% NOT Dockerized. That is a huge label of quality: Containers without docker. Actually, this is deliberate. Containerd. For example, rkt support on GKE is "coming soon" . https://www.mail-archive.com/google-containers@googlegroups....
Re: Docker in Production: An Update
#23I am neither a Docker expert nor evangelist, and I have my own gripes and frustrations with it, but this article is full of misinformation and FUD. To wit: > CoreOS is an operating [system] that can only run Docker and is exclusively intended to run Docker. No, it isn't. (Maybe if you substitute "Docker" with "containers.") > First, the main benefit of Docker is to unify dev and production. Having a separate OS in pr…
> Docker Issue: Breaking changes and regressions
Yes, it's new, and it changes regularly. This is why you do what you do with any other piece of software in an enterprise environment: Pick a stable release (e.g. 1.7), deploy it, then upgrade your development environment to the next stable release (e.g. 1.11) and work through the breaking changes. Regressions are frustrating, I'll agree, but it's free software: report the regressions and help the community fix them.
> Docker Issue: Can’t clean old images
A built-in feature to do so was added in 1.13 (a few months after this article was published).
> The only way to clean space is to run this hack, preferably in cron every day: docker images -q -a | xargs --no-run-if-empty docker rmi
That's not a hack, that's how you do things in Unix.
> As a long-standing goal, the AUFS filesystem was finally dropped in kernel version 4.
> There is no unofficial patch to support it, there is no optional module, there is no backport whatsoever, nothing. AUFS is entirely gone.
While the first point is technically true (actually, based on some light googling, I'm not sure it was ever merged in the first place), many distributions provide it as an optional kernel module. For example, Ubuntu provides it in linux-image-extra. Yes, Virginia, you can build kernel modules from source.
> How does docker work without AUFS then? Well, it doesn’t.
It does: Btrfs, Device Mapper, ZFS...
> So, the docker guys wrote a new filesystem, called overlay. [..] Note that it’s not backported to existing distributions. Docker never cared about [backward] compatibility.
Docker supports multiple storage drivers, one benefit of which is to be able to support older systems: AUFS on older distributions, OverlayFS on newer. The container abstraction allows you to not care about the underlying storage subsystem.
> Right now. We don’t know of ANY combination that is stable
In November 2016? Are you kidding?
0. https://thehftguy.com/2016/11/01/docker-in-production-an-his...
Re: Docker in Production: An Update
#24> CoreOS is an operating that can only run Docker and is exclusively intended to run Docker. This is a patently false statement and needs to be revised, especially given: > I will not comment on it. P.S. I'm getting downvoted for speaking the truth, no matter how pedantic it may seem. CoreOS can run rkt containers and is not exclusively intended to run Docker. One possible reason is because Docker is the 800 lb. gori…
Re: Docker in Production: An Update
#25I am neither a Docker expert nor evangelist, and I have my own gripes and frustrations with it, but this article is full of misinformation and FUD. To wit: > CoreOS is an operating [system] that can only run Docker and is exclusively intended to run Docker. No, it isn't. (Maybe if you substitute "Docker" with "containers.") > First, the main benefit of Docker is to unify dev and production. Having a separate OS in pr…
It's Linux. It's Debian. You can run any kernel you want. The guy works in finance, not an area where you can typically say "oh, no worries, we'll just push out this distro with a non-standard kernel." Enterprise IT, and specifically finance (and healthcare) have different requirements. Currently working with a client where not only the full technology stack has to be certified by accountable vendors, but all the int…
Re: Docker in Production: An Update
#26I still think that Solaris zones are / were a superior technology. Sadly it died with the demise of Solaris as an operating system. Still in use in some "must have enterprise" types of companies. I would not run anything serious on docker (definitely not yet) if I would not be heavily invested in understanding and contributing to the technology (docker codebase + related). Docker is a nice to have but absolutely abst…
There's also FreeBSD jails that can be used to contain applications. I'm not sure about the timeline, but I think jails came first. Sun engineers wanted to achieve the same so they ported the same technology over to Solaris.
Re: Docker in Production: An Update
#27> As confirmed by internal sources, they experienced massive troubles to get Docker working in any decent condition I call B.S. on this. Amazon wouldn't have spent so much effort on ECS if this was true.
Has Amazon spent a lot of effort on ECS? I am totally ignorant here, but the people who I consider more knowledgeable about AWS things have said in a nutshell that "in 2015 the things I heard about ECS were not good things, and I have basically not heard any new things since then." Basically stating that ECS was Amazon's attempt to plant a flag in the container-space and that it was half-hearted, not done with the ri…
Re: Docker in Production: An Update
#28I use Docker at work, and I 1) don't have any loyalty to their brand and 2) try as hard as I can to abstract away their specific APIs.
For example, we use Convox [0] to deploy containers to AWS. I could care less what Convox and/or AWS are doing under the hood. They could switch out Docker for rkt under my feet, and I probably wouldn't even notice.
It is kind of like POSIX to me. My apps are designed to run in a POSIX environment, not specifically CentOS or Debian. And just like it's easy for a new Linux distro to come along, give me POSIX, and give me some other shiny features I like, it will be easy for any competitor to come along and replace the Docker interfaces I use.
Re: Docker in Production: An Update
#29> Google merely exposes a Docker interface, all the containers are run on internal google containerization technologies, that cannot possibly suffer from all the Docker implementation flaws. Google running their own containerization tech with a Docker interface seems a bit far-fetched given the level of integration of Kubernetes with Docker. That's totally possible though, I'd like to read more about it.
Re: Docker in Production: An Update
#30There's just not a ton of substantiated content here. It's mostly really lousy anecdata like:
> Sadly, I am not aware of any serious companies than run on Ubuntu.
I am troubled by the direction of Docker and there are serious issues, some of which were raised in this post. However, whatever signal there is in this post is lost in a sea of noisy ranting.
My advice to anyone who doesn't already have strong opinions:
* Complement any reading that you do with your own research.
* Don't try to invent your own container orchestration system.
* If you aren't sure how to best do something, ask someone!
And for the love of everything holy:
* Don't run stateful systems on Docker if you can't handle failure or data loss!
Docker and orchestration systems like Kubernetes can be an excellent pairing. It's going to require research, a change in how you develop, build, test, and deploy systems, and a gradual building of operational experience. It will not be a quick process, and it's not for every org. But for some orgs and usage cases, it's an excellent way to go!