Why Docker Is Not Yet Succeeding Widely in Production • Hacker News Board

Re: Why Docker Is Not Yet Succeeding Widely in Production

#251

Post by jordanthoms » Wed, Jul 29, 2015, 4:33 AM UTC

theatraine wrote: post #246

jordanthoms wrote: post #239

Earlier quoted context omitted.

I do agree with you, but we're on Heroku and that also has it's downsides - the biggest one we've found is that CPU performance on 1x and 2x dynos is very unpredictable - We've had to move to Performance dynos ($500/month each!) to get decent performance and prevent random timeouts. Services like Cloud66 are interesting (they manage deployments onto your own EC2 or other cloud infrastructure), but the developer exper…

Azure App Service ( https://azure.microsoft.com/en-us/services/app-service/ ) is Azure's Heroku competitor. It's quite close in features and ease-of-use. Disclosure: I work for this team.

That looks quite nice in the few minutes I spent looking at it. The lack of Ruby support is a issue though, and we're also all on OSX and prefer CLI interfaces for most stuff.

Also, one of the killer features of Heroku (which few services seem to replicate) is log drains - I can easily add a http or syslog endpoint and have Heroku send the logs over. The other killer feature which isn't often replicated is One-off dynos, where we can spin up a new instance and get a console attached to it in one command - useful for running database migrations or using Ruby as a CLI to access data.

If we were on .NET that would probably be attractive, but it's still not really competing with Heroku.

Re: Why Docker Is Not Yet Succeeding Widely in Production

#252

Post by nulltype » Wed, Jul 29, 2015, 4:40 AM UTC

garthk wrote: post #240

davexunit wrote: post #173

Earlier quoted context omitted.

>Docker might still be nice for perfect reproducibility Docker actually doesn't help reproducibility at all, because the underlying reproducibility problems present in the distro and build systems are used are still present. See GNU Guix, Nix, and Debian's Reproducible Builds project for efforts to make build truly reproducible. I had a good laugh when I read "the Rube Goldberg Machine development anti-pattern". This…

> It's like static linking an entire operating system for each application. You say it like it's a problem, but that's the most concise description of Docker I've yet read. It rhymes with the way all the fed up oldies using Go like its static linking.

This is pretty much how I view Docker as well. Except it's not really the entire operating system. A VM image is the ultimate static linking.

Re: Why Docker Is Not Yet Succeeding Widely in Production

#253

Post by Gigablah » Wed, Jul 29, 2015, 4:42 AM UTC

statico wrote: post #242

stephenr wrote: post #241

Earlier quoted context omitted.

I'm definitely no fan of Docker or the ridiculous containerisation trend, but I think I may disagree with one key thing you said: > Focus on your product, outsource the rest. What do you mean by outsource the rest? Do you mean, "hey we're using AWS -as-Service because we don't want to manage a DB cluster or deal with a load balancer? Or do you mean, rely on existing available tools and stop reinventing the wheel ever…

> What do you mean by outsource the rest? iamleppert means: Identify your company's core competency and do that in house, but outsource or avoid that which is not your core. For example, we're making a game. Gameplay, art, and tech is all done in-house and not with remote contractors because it needs to be -- it's the part of the product we love and the part our players will end up loving. Email, forums, chat, HR, ap…

But if you're making a game, and create your own chat service instead, you end up as Slack.

Re: Why Docker Is Not Yet Succeeding Widely in Production

#254

Post by whitenoice » Wed, Jul 29, 2015, 4:43 AM UTC

lucaspiller wrote: post #111

TheDong wrote: post #79

Earlier quoted context omitted.

If this is your advice then you shouldn't give advice. 1) 'docker logs' relies on using the json logdriver which means the log file is stored in /var/lib/docker/..... and grows forever. No rollover. No trimming. FOREVER . 2) What if your container dies? What if your host dies? Do you have any state at all or have you abstracted that out? Are your systems distributed 3) Always running does not answer finding where to…

> 1) 'docker logs' relies on using the json logdriver which means the log file is stored in /var/lib/docker/..... and grows forever. No rollover. No trimming. FOREVER. Even without that issue, I'd prefer my logs to be centralised. So as well as my app should I be running a logging daemon, process monitoring, etc for each docker instance?

Similar to hibikir's reply, what we do is attach a volume container to all app containers and logs are written to that. The run elk stack to view parse logs. For process monitoring we run cAdvisor on each host to view the resource usage of each container. Since your apps are containerized it easy to monitor them for resource usage, hook it to nagios etc. We have built custom gui to do all this.

Re: Why Docker Is Not Yet Succeeding Widely in Production

#255

Post by boundlessdreamz » Wed, Jul 29, 2015, 4:47 AM UTC

Nyetan wrote: post #238

kosma wrote: post #233

Earlier quoted context omitted.

Until a few days ago I was a DevOps engineer at a medium-sized tech company. My primary responsibility was dockerizing their applications and infrastructure. I quit the job. The scenario played out just as you said: I ended up single-handedly and poorly re-engineering something that already existed (they did have a working Ansible setup) for no visible gain. "Swimming in containers upon containers" is exactly what ha…

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…

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 is that it is idempotent and the changes it makes to the system are the same ones you make manually or via bash scripts. So it is quite easy to debug

Re: Why Docker Is Not Yet Succeeding Widely in Production

#256

Post by statico » Wed, Jul 29, 2015, 4:48 AM UTC

Gigablah wrote: post #253

statico wrote: post #242

Earlier quoted context omitted.

> What do you mean by outsource the rest? iamleppert means: Identify your company's core competency and do that in house, but outsource or avoid that which is not your core. For example, we're making a game. Gameplay, art, and tech is all done in-house and not with remote contractors because it needs to be -- it's the part of the product we love and the part our players will end up loving. Email, forums, chat, HR, ap…

But if you're making a game, and create your own chat service instead, you end up as Slack.

We in fact started with an HTML5 group chat application very much like Slack but ended up making a game.

Re: Why Docker Is Not Yet Succeeding Widely in Production

#257

Post by Nyetan » Wed, Jul 29, 2015, 5:03 AM UTC

boundlessdreamz wrote: post #255

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…

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!

Re: Why Docker Is Not Yet Succeeding Widely in Production

#258

Post by chasb » Wed, Jul 29, 2015, 5:22 AM UTC

kosma wrote: post #233

iamleppert wrote: post #227

I've said it before and I'll say it again: pre-mature infrastructure optimization is the root of all evil. Do me a favor and if you got a startup, stay clear of all this. Everyone wants to reinvent their own flavor of heroku and make your deployment and build pipeline god-awful complex. Their tool of choice? Docker. Before you know it you'll be swimming in containers upon containers. Containers will save us, they'll…

Until a few days ago I was a DevOps engineer at a medium-sized tech company. My primary responsibility was dockerizing their applications and infrastructure. I quit the job. The scenario played out just as you said: I ended up single-handedly and poorly re-engineering something that already existed (they did have a working Ansible setup) for no visible gain. "Swimming in containers upon containers" is exactly what ha…

We run Docker in production, as a PaaS no less, and this reads like a list of reasons to use a new-generation PaaS.

Re: Why Docker Is Not Yet Succeeding Widely in Production

#259

Post by agiamas » Wed, Jul 29, 2015, 5:48 AM UTC

jordanthoms wrote: post #251

theatraine wrote: post #246

Earlier quoted context omitted.

Azure App Service ( https://azure.microsoft.com/en-us/services/app-service/ ) is Azure's Heroku competitor. It's quite close in features and ease-of-use. Disclosure: I work for this team.

That looks quite nice in the few minutes I spent looking at it. The lack of Ruby support is a issue though, and we're also all on OSX and prefer CLI interfaces for most stuff. Also, one of the killer features of Heroku (which few services seem to replicate) is log drains - I can easily add a http or syslog endpoint and have Heroku send the logs over. The other killer feature which isn't often replicated is One-off dy…

you summed up the reasons I use Heroku myself, gz.

Re: Why Docker Is Not Yet Succeeding Widely in Production

#260

Post by kordless » Wed, Jul 29, 2015, 5:49 AM UTC

laichzeit0 wrote: post #149

gknoy wrote: post #105

Earlier quoted context omitted.

"There are some problems with your approach, and it could bite you in the tail when you least expect it. Here's what you should also know: ... (rest of GP's points)" This avoids saying "You're an idiot", which is nearly never constructive or helpful, and instead makes education and cooperation its goal. Most people respond better to that.

Sometimes people need to know they're idiots without the person calling them an idiot having to tip-toe around the issue. Just like how some children are smarter than others and could actually benefit from ring labeled as such, put in a separate environment and given advanced problems to work on instead of lumping them with the rest of the herd. Just like fat people should be told they're fat and pay a premium for a…

Without fully knowing what a person is thinking (and I'm talking in whole here), and the context they are thinking it in, it is impossible to always determine if what someone said is "idiotic" or not, much less be capable of determining if they themselves are an idiot. Given this provable fact, that means there exists a possibility someone ends up calling a savant an idiot for saying something that is viewed by them, or a group as a whole, as "idiotic".