Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Docker Is Not Yet Succeeding Widely in Production

sirupsen.com

Post reply on HN
Print view View original

191–200 of 290 posts

Re: Why Docker Is Not Yet Succeeding Widely in Production

#191

Post by kitwalker12 »

mkulke wrote: post #189
kitwalker12 wrote: post #129

Earlier quoted context omitted.

It's pretty complicated with GCE itself. for GCE, I followed this http://kubernetes.io/v1.0/docs/getting-started-guides/gce.ht... guide. I eventually wanted to set it up in Rackspace where my company cloud lives. I used corekube( https://github.com/metral/corekube ) heat templates to set it up but the way to add more minions to the cluster wasn't simple. On top of that there's this complicated networking I have to se…

Corekube is somewhat complex template (and not supported by kubernetes currently). Just attempt to roll your own, it's actually not that hard. You can use the official coreos "getting started" cloud-config files as a starting point. Etcd & flannel are required, the rest is just wiring a set of binaries. Adding nodes is pretty straightforward, you just create a server with the proper cloud-config, they should auto-reg…

yeah. I actually abandoned corekube and followed this guide (https://github.com/GoogleCloudPlatform/kubernetes/blob/maste...) from the main repo. In the end it was the networking that wore me down.

Re: Why Docker Is Not Yet Succeeding Widely in Production

#192

Post by toomuchtodo »

Leon wrote: post #179
eropple wrote: post #170

Earlier quoted context omitted.

Ahh, gotcha. That's a neat approach, though the double hit of Docker builds + AMI builds feels a little weird to me. Thanks for the insight.

I also do what the other poster does, but we take it a step further and make sure that the layers on the image have smaller and more variable layers near the last layer add. On instance startup we can do a docker pull and bring down only a few k of bytes for docker image updates. This way we can update the ami less often (which it takes longer anyway) and we don't worry too much about pushing updates to the container…

If you're in AWS, I wouldn't worry about how many bytes docker image updates take. Our registry is using S3 as its backend, and I can pull images under 100MB in a few seconds.

Re: Why Docker Is Not Yet Succeeding Widely in Production

#193

Post by regularfry »

acdha wrote: post #168
iopq wrote: post #162

Earlier quoted context omitted.

Yeah, but then there's still the issue of secrets, you need to have testing PayPal credentials, testing mailing service credentials, etc. There's the issue of deploying changes fast without leaving files in an inconsistent state (you don't want half of some file to run). How about installing the required dependencies? I don't use Docker, but those are problems I can think of off the top of my head.

Credentials have to be managed separately from Docker anyway. > There's the issue of deploying changes fast without leaving files in an inconsistent state (you don't want half of some file to run). How about installing the required dependencies? rpm / dpkg also install dependencies, are quite fast and well tested. They have the advantage of working in a standard environment which most sysadmins know but the disadvant…

> the disadvantage that you need to configure your apps to follow something like LSB (e.g. install to standard extension locations rather than overwriting system files, etc.).

Common misconception. You only need to do this if you're going to try to push the packages upstream. If they're for your own consumption, you can do what you like. Slap a bunch of files in /opt, and be done with it - let apt manage versions for you and be happy.

As with many things, this is one area where you've just got to know what to ignore. It's simpler than it looks.

Re: Why Docker Is Not Yet Succeeding Widely in Production

#194

Post by acd »

mrweasel wrote: post #130
mariusmg wrote: post #42

Maybe because Docker isn't really needed ? I mean if your app needs the entire fucking OS to provide isolation from other apps, then you are clearly doing it wrong.

Don't underestimate the amount of people doing things wrong. Docker could be much more successful in the Windows world, the ability to package very precise versions of databases, libraries, weird obsolete application into one image that can be deployed easily would be extremely helpful in many companies. It would be the wrong solution, but an easy work-around for broken upgrade paths.

Docker is called App-V when it is runs on Windows instead of Linux. App-V virtualizes the registry, provides app portability.

Unfortunately full App-V is only for Windows enterprise customers.

Re: Why Docker Is Not Yet Succeeding Widely in Production

#195

Post by regularfry »

spoondan wrote: post #181
tracker1 wrote: post #172

Earlier quoted context omitted.

That's a bit of my point... If you're building relatively small independent services with Docker you can deploy service A with node 0.10 as it's tested environment and service B with iojs 2.4 on the same server, without them conflicting... when you need to update/enhance/upgrade service A you then can update the runtime. The same can be said for ruby, python and any number of other language environments where you hav…

> The same can be said for ruby, python and any number of other language environments where you have multiple services that were written at different times with differing base targets. I've seen plenty of instances where updating a host server to a new runtime breaks some service that also runs on a given server. This is a solved problem in Python and Ruby. In Python, use virtual environments. In Ruby, use RVM. You w…

You're correct, but I can see that there's certainly a place for having a single solution that works across all ecosystems.

Also, RVM in production? Sledgehammer to crack a nut :-)

Re: Why Docker Is Not Yet Succeeding Widely in Production

#196

Post by acdha »

regularfry wrote: post #193
acdha wrote: post #168

Earlier quoted context omitted.

Credentials have to be managed separately from Docker anyway. > There's the issue of deploying changes fast without leaving files in an inconsistent state (you don't want half of some file to run). How about installing the required dependencies? rpm / dpkg also install dependencies, are quite fast and well tested. They have the advantage of working in a standard environment which most sysadmins know but the disadvant…

> the disadvantage that you need to configure your apps to follow something like LSB (e.g. install to standard extension locations rather than overwriting system files, etc.). Common misconception. You only need to do this if you're going to try to push the packages upstream. If they're for your own consumption, you can do what you like. Slap a bunch of files in /opt, and be done with it - let apt manage versions for…

I think we're actually talking about the same thing – I said “like LSB” simply to denote following some sort of consistent pattern, which will vary depending on how widely things are shared.

/opt is defined in FHS for local system administrator use, so installing your company's packages there is actually the recommended way to avoid conflict with any LSB-compliant distribution as long as you use /opt/ instead of installing directly into the top-level /opt:

http://www.pathname.com/fhs/pub/fhs-2.3.html#OPTADDONAPPLICA...

Re: Why Docker Is Not Yet Succeeding Widely in Production

#197

Post by robszumski »

maratd wrote: post #167
iopq wrote: post #162

Earlier quoted context omitted.

Yeah, but then there's still the issue of secrets, you need to have testing PayPal credentials, testing mailing service credentials, etc. There's the issue of deploying changes fast without leaving files in an inconsistent state (you don't want half of some file to run). How about installing the required dependencies? I don't use Docker, but those are problems I can think of off the top of my head.

> Yeah, but then there's still the issue of secrets How would Docker help with this? Genuinely curious. I store them in bash scripts outside the repo that populate the relevant data into environment variables and execute the code. The code then references the environment variables. > How about installing the required dependencies? There are two kinds. On the OS level and on the platform level. On the OS level, you ca…

Kubernetes secrets are a really great solution to this problem. [1] They are stored at the cluster level and injected into the pod (group of containers deployed together) via a file system mount. This means that each pod only has access to its secrets which is enforced by the the file system namespace. If an entire machine is compromised, only the secrets of pods currently scheduled onto that machine are able to be stolen. That's a high level, but it's worth taking a look at the design doc.

Edit: forgot to mention, the file system mount means that they don't need to be in env var, which are fairly easy to dump if you have access to the box or are shipping containers around in plain text.

1. https://github.com/GoogleCloudPlatform/kubernetes/blob/maste...

Re: Why Docker Is Not Yet Succeeding Widely in Production

#198

Post by regularfry »

why-el wrote: post #160
emergentcypher wrote: post #141

My application compiles to a jar that runs on a server and expects an accompanying config file. I've tried giving Docker a whirl a few times and I never fully understood what need I had that it was solving.

Is your application just a jar? In the yes case your conclusion is correct. Throw in a database, a cache server, couple of versioned libraries your jar file needs, and more developers, and suddenly a reproducible image with all this packaged will make a lot of sense.

In that instance, docker doesn't buy you much over vagrant. Docker stands to win where you've got 15 different apps which all need to come up together so you can QA the combined set of services in a single VM on a tester's desktop.

Re: Why Docker Is Not Yet Succeeding Widely in Production

#199

Post by jayfk »

therealmarv wrote: post #190
mseri wrote: post #77

Earlier quoted context omitted.

In this regard I think the remarks of McKinley's "Choose Boring Technology" [1,2] is quite relevant. [1]: http://mcfunley.com/choose-boring-technology-slides [2]: http://mcfunley.com/choose-boring-technology

Big thanks for this links. Actually this is really true for Docker and DevOps. There are proven concepts and known unknown but for Docker the unknown unknown part is really scary especially regarding security for production. Maybe for bigger companies this is no problem but for small dev teams this is very risky and time consuming. Just one non trivial example: I can secure Ubuntu against sshd attacks pretty good and…

CoreOS is not docker. You can run docker on ubuntu and install fail2ban on it. I don't see the problem here.

Re: Why Docker Is Not Yet Succeeding Widely in Production

#200

Post by geggam »

superuser2 wrote: post #188
geggam wrote: post #166

Earlier quoted context omitted.

what is the benefit to any isolation of a process for a single tenant ? and why cant you just run cgroups without the overhead of docker ? see : bocker

>what is the benefit to any isolation of a process for a single tenant? Build, test, and ship the same artifact. Whether it's a Vagrant on your Mac, AWS, or metal in your colo datacenter. >and why cant you just run cgroups without the overhead of docker ? If you're running cgroups, you've created your own half-baked implementation of Docker in giving yourself a reasonable API to work with. This might make sense if yo…

cgroups is docker now ? what does that make systemd-nspawn ?
Post reply on HN