Live data from Hacker News

Why Docker Is Not Yet Succeeding Widely in Production

sirupsen.com

21–30 of 290 posts

Re: Why Docker Is Not Yet Succeeding Widely in Production

#21
I'm confused by this paragraph

> Every major deployment of Docker ends up writing a garbage collector to remove old images from hosts. Various heuristics are used, such as removing images older than x days, and enforcing at most y images present on the host. ...

More specifically, I'm confused by this sentence, from the above paragraph in TFA:

> Most people discover their need by accident when their production boxes scream for space.

When did Docker become a replacement for Ops or Devops which are aware of their servers, monitoring systems that let you know when you're getting close to the "Yellow Alert" warning, and some sort of plan for growth and expansion?

Hardware isn't free, but it seems like some want Docker to make hardware free; delivering on the promise that full-OS VMs couldn't realize, which was trying to deliver on the promise that HT couldn't make happen. I'm sorry, but if you have 24 cores and 64GB of RAM, there's only so many ways to schedule and swap to maximize use of those resources.

---

Copy on Write (COW) sounds like Thin Provisioning. Thin Provisioning is known for 2 things: 1. Slower performance than "Thick Provisioning" where the entire allocated space is zeroed on allocation, instead of on write. And 2. Ease of overallocation - you can take a 100GB disk and create 10 virtual disks of 100GB each; this is like reserve banking, and it's only a problem if someone actually wants to use the entire resource that you say they can access.

I'm curious if they'll have an NTFS option. Actually, with Microsoft's recent open sourcing, I'd be interested to see NTFS open up a bit; maybe get an official Linux driver of some sort.

Will there be other write methods? Perhaps one that's more similar Thick Provisioning?

---

I'd hate to see VMs die. The flexibility and value they provide to the Microsoft world is unparalleled. I could see Dockers replacing Linux etc VMs -- no need to run CentOS(?) to host your LAMP stack when you can just have each letter in its own cluster of containers.

Maybe if each Windows component was rerolled as a container image; we could have Domain Controller (DNS/AD/LDAP/Kerberos/ACL) containers, IIS containers, SQL containers, DFS containers that were backed by SAN or NAS, FTP containers, TFS containers, etc. And there would have to be RDP/VDI containers, where users could remotely connect, and work in the environment with a desktop and GUI tools, since that is such a core part of the Microsoft ecosystem.

---

Looking at the Security and Image Layers and Transportation sections makes me realize how young this technology is. In a few more years, a few more iterations, and this could definitely replace numerous VM Appliances and Middleware devices. The time for Dockers and containers isn't quite today, but it's very close.

Re: Why Docker Is Not Yet Succeeding Widely in Production

#22
post #16

I would be sold on Docker if that would be easy. I have e.g. this stack: - 1 webserver/proxy, let's say nginx - 1 simple Rest API server, let's say in flask - 1 database, let's say PostgreSQL and I want to connect all 3 things and I want to preserve logs for the whole time and preserve the state of the database (of course). Also not to forget make all bulletproof for the Internet. And here all sorts of problems arise…

Kubernetes solves this by mounting external volumes (say NFS or iSCSI) on the host and then exposing them to one or more docker containers. This seems like a pretty ideal solution for any Docker user.

thanks I will definitely look more into Kubernetes.

Re: Why Docker Is Not Yet Succeeding Widely in Production

#23

I would be sold on Docker if that would be easy. I have e.g. this stack: - 1 webserver/proxy, let's say nginx - 1 simple Rest API server, let's say in flask - 1 database, let's say PostgreSQL and I want to connect all 3 things and I want to preserve logs for the whole time and preserve the state of the database (of course). Also not to forget make all bulletproof for the Internet. And here all sorts of problems arise…

docker-compose comes to save the day when it comes to how to connect containers. Your Dockerfile will specify which underlying OS is used. Preserve state of your database with data volumes.

docker-compose is no magic, it only maps a YAML file to docker's command arguments. While I think docker-compose is useful in some cases, I strongly advise to not use it at first so you understand how docker actually works.

Once you understand how docker works, using the YAML file can become useful to lighten your load.

Re: Why Docker Is Not Yet Succeeding Widely in Production

#24
Just my personal opinion but Docker still reflects the developer-centric culture that inspired it and by that I mean security is still getting more mature but isn't quite there yet.

For instance there's still work being done to add native PAM and by extension Kerberos support, and the daemon runs as root, thus requiring extra caution about who may run docker commands.

If you're (for example) in an enterprise where developers may never have root access under any circumstances, you end up with a chicken and egg scenario: if developers don't have the ability to test container creation (because doing so might grant them root access in a container), who does?

Re: Why Docker Is Not Yet Succeeding Widely in Production

#25
post #11

TL;DR It's too damn complicated if you're not Google/Twitter/Netflix. Most people would be fine just deploying OS packages and keeping their stacks as simple as possible.

Yes, exactly. I really can't recommend that my company use this right now because of the complexity. The Hello World image is easy, but after that, there's quite a bit involved. And my company is already happy enough with spinning up VMs.

Re: Why Docker Is Not Yet Succeeding Widely in Production

#27
post #6

I still haven't been sold on Docker. Why would an otherwise competent company that runs things just fine, ditch it all and adopt Docker? Just because it's the shiny new thing? What do we actually gain here in production?

Because "running things just fine" across production, continuous integration and on dev machines is actually quite a hard thing to do. But then, if you don't feel like you need it, that's probably because you don't need it. (If people are downvoting your question, it's probably because you're giving off a bit of a "I don't understand Docker so it must be crap" vibe, which is not helpful.)

OK, now we're getting somewhere. What is difficult about getting things right across production and CI? What are the pain points? What are the exact problems we're being asked to solve here? I don't think dev environments need to be harmonized the same as production. If your tests are good, you should catch most of the "it worked on my laptop" problems.

Sorry if my initial question came across with a weird vibe. I'm generally curious. I have colleagues working at places and they actually are being asked to drop everything and implement Docker. I asked why and what's driving this and got the predictable response of "management/dev/someone wants something new".

Re: Why Docker Is Not Yet Succeeding Widely in Production

#28
post #16

I would be sold on Docker if that would be easy. I have e.g. this stack: - 1 webserver/proxy, let's say nginx - 1 simple Rest API server, let's say in flask - 1 database, let's say PostgreSQL and I want to connect all 3 things and I want to preserve logs for the whole time and preserve the state of the database (of course). Also not to forget make all bulletproof for the Internet. And here all sorts of problems arise…

Kubernetes solves this by mounting external volumes (say NFS or iSCSI) on the host and then exposing them to one or more docker containers. This seems like a pretty ideal solution for any Docker user.

Are you suggesting that a person with a total of 3 nodes use a system like Kubernetes which requires at a minimum (correct me if I'm wrong) 5 nodes just to function? If you really, really want to use Docker with a typical Nginx-App-DB setup just whip up the necessary shell commands to start/stop/log containers and throw that in Ansible or the like.

edit: I guess you can cram all of the various Kubernetes master/etcd servers on a single node but whoops there goes reliability.

Re: Why Docker Is Not Yet Succeeding Widely in Production

#29
post #17

Earlier quoted context omitted.

containers provide a reasonable level of abstraction/isolation for applications, and have been used in production for some years now. Docker may be shiny, but containers not so much.

But why the need for abstraction and isolation? If I'm a reasonably well run web shop that knows how to run their apps and balance out server load, what does Docker get me? Also, shout out to the fanboys for downvoting my question, which was just a question asking for thoughts and answers and didn't make any statement whatsoever.

Isolation - so you can run / snapshot / restore multiple applications not influencing each other on one machine. Abstractions so that you code doesn't have to worry about different os-es, cloud providers, etc.

Re: Why Docker Is Not Yet Succeeding Widely in Production

#30
post #17

Earlier quoted context omitted.

containers provide a reasonable level of abstraction/isolation for applications, and have been used in production for some years now. Docker may be shiny, but containers not so much.

But why the need for abstraction and isolation? If I'm a reasonably well run web shop that knows how to run their apps and balance out server load, what does Docker get me? Also, shout out to the fanboys for downvoting my question, which was just a question asking for thoughts and answers and didn't make any statement whatsoever.

@mateuszf can you give actual examples of each? I can upgrade nginx on my servers without affecting memcache or MySQL or redis or....Why the need for isolation there?
Post reply on HN