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

281–290 of 290 posts

Re: Why Docker Is Not Yet Succeeding Widely in Production

#281

Post by novaleaf »

kentonv wrote: post #147
inopinatus wrote: post #82

Earlier quoted context omitted.

Docker solves a problem that most people don't have. It's not a PaaS, rather, it's (some of) the building blocks to create your own PaaS. Most folks don't need that. Most folks want to put files on a server and start a process. For those folks, Docker in the raw ends up being a whole lot of confusing & unnecessary scaffolding.

Moreover, Docker / Kubernetes aims to solve the problem of building services that can easily scale to hundreds of machines and hundreds of millions of users, "Google-style". That's great, if that's what you need. But most people aren't building a service like that. HN, I believe, runs on one machine, with a second for failover purposes. And HN still has many, many more users than typical company-internal services, co…

i just use google cloud's HTTP Loadbalancer and AutoScale. it automatically spanws/remove's VM's based on load.

Re: Why Docker Is Not Yet Succeeding Widely in Production

#282

Post by oldmantaiter »

Using Docker as a local development system (especially with boot2docker on OSX creating a bunch of containers with different major versions of OS (el6/el7 for example) and being able to develop/test multiple apps at the same time is the only benefit I can justify for Docker.

But that's as far as I will take it, Docker is mainly used (from what I've seen) as a nice way to package something without having to write an actual package (RPM/deb) that will work across multiple platforms (for the most part). If you take the time to learn how to properly package your application, docker is unnecessary in almost every case.

Re: Why Docker Is Not Yet Succeeding Widely in Production

#283

Post by kosma »

pnathan wrote: post #280
Nyetan wrote: post #238

Earlier quoted context omitted.

Bother you for a little advice? I'm working at a mid-sized tech company and am evaluating Docker for CI, testing and limited, internal deployment usages. The services in question are built with a hodge-podge of shell scripts and build tools, so getting them all to compile locally is a challenge, let alone deploying them. My hope was that containerizing the builds would isolate any configuration problems, and that con…

Contra most of the trend on this thread, I am super pro-Docker (I'm actually surprised so many people are unhappy with it - it seems to be clearly head and shoulders over other systems). I would argue that in your situation you need to use docker as your build system at the least. Something like the following docker run -v `pwd`:/tmp/buildresult your-weird-hodpodge build-command Among other things, I see docker as an…

The moment you do

    docker run -v `pwd`:/...
you're no longer running pure Docker, but Docker + a shell script. Those shell scripts bloat horribly, are not portable, and are a pain to maintain. This is precisely my problem.

Re: Why Docker Is Not Yet Succeeding Widely in Production

#284

Post by [deleted] »

joslin01 wrote: post #61
zaargy wrote: post #47

Earlier quoted context omitted.

I still love Docker and do think it solves a genuine problem. But yes, where to put your logs, how to manage state, how to schedule containers on machines, how to coordinate processes, how to inspect an app when something goes wrong, how to measure performance, how to manage security, how to keep consistency across your docker containers... are all problems you need to solve from the get go with Docker and they are a…

I'm not sure how much you know about docker, so to anyone in whom this list scares: > Where to put logs Well, I just throw them aside and use `docker logs [container]` > How to manage state One container should perform one service. I haven't run into a problem here. > How to schedule containers ECS :) But honestly, I subscribe to the approach that containers = services and thus should just always be running. > How to…

[deleted]

Re: Why Docker Is Not Yet Succeeding Widely in Production

#285

Post by pnathan »

kosma wrote: post #283
pnathan wrote: post #280

Earlier quoted context omitted.

Contra most of the trend on this thread, I am super pro-Docker (I'm actually surprised so many people are unhappy with it - it seems to be clearly head and shoulders over other systems). I would argue that in your situation you need to use docker as your build system at the least. Something like the following docker run -v `pwd`:/tmp/buildresult your-weird-hodpodge build-command Among other things, I see docker as an…

The moment you do docker run -v `pwd`:/... you're no longer running pure Docker, but Docker + a shell script. Those shell scripts bloat horribly, are not portable, and are a pain to maintain. This is precisely my problem.

The strong pressure I'm laying on people in my company is that Check Your Stuff In, so there might be a run-docker.sh that's checked in, which then can be reviewed and evaluated. It's not per se ideal, but it's a sight better than a nest of Jenkins scripts outside of source control.

Re: Why Docker Is Not Yet Succeeding Widely in Production

#286

Post by feld »

KirinDave wrote: post #146
feld wrote: post #108

Earlier quoted context omitted.

I disagree. It's all about "the evil you know". And then there's the part where Weave is slow, so you might as well stick to VMs or hardware... http://www.generictestdomain.net/docker/weave/networking/stu...

On Weave, yeah. Not the best performance, and improving. Flannel is obviously better, and one of the reasons we're excited about rocket. That changes almost nothing for shops hoping to move to containerized architectures now. It's only for existing early adopters. The idea that docker introduces that much uncertainty is outright fear mongering. There is a huge amount of recalcitrance in the community to do anything m…

Show me how I can easily audit all my docker containers for vulnerabilities from spacewalk

Show me a docker-aware Rapid7

There are a lot of tools for security and compliance completely thrown out with the bathwater when you move to containers. You're not going to get enterprises to bite until you can satisfy the auditors.

Re: Why Docker Is Not Yet Succeeding Widely in Production

#287

Post by KirinDave »

feld wrote: post #286
KirinDave wrote: post #146

Earlier quoted context omitted.

On Weave, yeah. Not the best performance, and improving. Flannel is obviously better, and one of the reasons we're excited about rocket. That changes almost nothing for shops hoping to move to containerized architectures now. It's only for existing early adopters. The idea that docker introduces that much uncertainty is outright fear mongering. There is a huge amount of recalcitrance in the community to do anything m…

Show me how I can easily audit all my docker containers for vulnerabilities from spacewalk Show me a docker-aware Rapid7 There are a lot of tools for security and compliance completely thrown out with the bathwater when you move to containers. You're not going to get enterprises to bite until you can satisfy the auditors.

Cool. I'm glad that I'm in the only top 10 bank in the US using stacakto.

Re: Why Docker Is Not Yet Succeeding Widely in Production

#288

Post by fatherlinnux »

vezzy-fnord wrote: post #131
fatherlinnux wrote: post #127

Earlier quoted context omitted.

Yeah, but the layered images and copy on write nature of Docker has not and IMHO, that is what is novel about this new wave of containers.

Union mounts? Those are at least 25 years old.

Just add registry server, that's where the magic is.

Re: Why Docker Is Not Yet Succeeding Widely in Production

#289

Post by xorcist »

Nyetan wrote: post #257
boundlessdreamz wrote: post #255

Earlier quoted context omitted.

I think you will get more bang for the buck by using something like ansible or salt (I have only used ansible and love it and I have heard salt is comparable) You don't have a standard repeatable way to set up an environment now. You need to do that first before jumping on docker I think. Once you have that, you can start replacing parts of the setup with docker and see if it fits your needs. The advantage of ansible…

Aah, brilliant -- and they even have a book :D thanks for the recommendation!

The big pro with Ansible and similar tools is that the scripts are actually very readable, with clear best practices.

If you come to a new place and "there's an error in here somewhere", the difference between layers of images held together with shell scripts and a Ansible/Puppet/Chef script is like night and day.

Re: Why Docker Is Not Yet Succeeding Widely in Production

#290

Post by pjotrp »

Docker for reproducible Science is an intermediate solution. While a Docker image can be moved and rerun (with some luck) the content of a Docker image is actually not transparent.

Reproducibility implies being able to regenerate the full container including software version control and visibility of the full dependency chain all the way down to BLAS and glibc! You can't do that by using apt, rpm, Perl CPAN, rubygems, Python pip and the like. None of these package managers have been designed for true isolation of packages and full reproducibility. That is why today people go with Docker. The shortcomings of these package managers drive people to Docker.

The technology for regenerating exact Docker containers exists in the form of GNU Guix and/or Nix packages. The fun fact is that when using GNU Guix, Docker itself is no longer required.

Watch GNU Guix.

Post reply on HN