Live data from Hacker News

Docker in Production: An Update

thehftguy.com

21–30 of 97 posts

Re: Docker in Production: An Update

#21

> 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…

You're not wrong, CoreOS can also run arbitrary go binaries (or anything else that can be statically linked) rigged up into systemd or fleet units, without any containers at all.

Re: Docker in Production: An Update

#22
TLDR of the first 60% of the blog post - "I cannot comment on the LTS 16 as I do not use it. It’s the only distribution to have Overlay2 and ZFS available, that gives some more options to be tried and maybe find something working?"

Second 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

#23

I 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…

And a quick run through the previous article[0]:

> 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…

It is an especially silly statement considering that CoreOS had a much-publicized falling-out with Docker and created rkt to replace it.

Re: Docker in Production: An Update

#25

I 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…

I have (or had, I guess) an 11 year career in Fortune ~100 finance and healthcare. Agreed on all points. However, they're already experimenting with Debian, Ubuntu LTS (just not 16.04), kernels, custom AMIs, and different Docker versions. It's not a stretch to imagine they have the ability to deploy a back-ported kernel, or build and/or use an AMI that includes one. Also, HFT practices (or lack thereof) are far from the staid enterprise practices you may be thinking of.

Re: Docker in Production: An Update

#26

I 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…

Solaris within Oracle is as good as dead from the latest reports. However, Illumos is a Solaris descendant that is very much alive. It has all the good systems stuff that came out of Sun (zones, ZFS, DTrace) and is backed by Joyent (now part of Samsung).

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
post #11

> 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…

Don't know about ECS but ECR (the registry) is a freaking godsend.

Re: Docker in Production: An Update

#28
I have to agree when it comes to the business perspective. I can't imagine how Docker is going to survive financially.

I 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.

[0] https://convox.com/

Re: Docker in Production: An Update

#29
post #6

> 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.

It is far-fetched 'cause it's not AFAIK true. My experience for this is having set up a GKE Kubernetes cluster last night, it was definitely running Docker.

Re: Docker in Production: An Update

#30
I get the sense that this person wrote a sarcastic, vaguely entertaining piece that drew lots of views. Hoping for lightning to strike twice, they did this again because who doesn't love traffic? That seems to be the entire motivation behind this post, from what I can tell.

There'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!

Post reply on HN