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.
Why Docker Is Not Yet Succeeding Widely in Production
141–150 of 290 posts
Re: Why Docker Is Not Yet Succeeding Widely in Production
#142"However, for many production users today, the pros do not outweigh the cons. Docker has done fantastically well at making containers appeal to developers for development, testing and CI environments—however, it has yet to disrupt production." I keep hearing about people putting Docker in dev and test environments and not production. This use case makes no sense to me as you would throw away the entire point of conta…
We are looking at using Docker to help make our dev environments a little bit more sane. We deploy to Heroku so we use the Heroku docker image to give us (what is hopefully) as close to production environment in dev as possible. I have got docker working in a proof of concept project but the performance on OSX when using volumes, so you can actually dev on it, pretty terrible.
Re: Why Docker Is Not Yet Succeeding Widely in Production
#143Earlier quoted context omitted.
Yup. At my last gig we built out a Mesos cluster and were deploying Docker containers, but we couldn't answer "how do we practically secure this to the same level as independent virtual machines?" and, finding no good answer, we went back to auto-scaling groups and baked AMIs.
Yes, doing the same thing here as well. Still using docker to streamline deployments though, but one docker container/role per instance, no "orchestration" for containers (baked AMIs, ASGs).
I did that at one place, but I wasn't super satisfied with the process--having to download container images on spin-up was annoyingly slow and I didn't feel like we were getting better dev/prod consistency versus Vagrant and Packer.
Re: Why Docker Is Not Yet Succeeding Widely in Production
#144Earlier quoted context omitted.
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…
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 - Yes it does. This is a system problem more than a docker problem. For any relatively experienced engineer, they should be capable of realizing the logs must be stored somewhere and can plan around it.
2 - If a system dies and it has a state, then what do you do? If a dockerized process dies, and it has a state, then what do you do? This isn't some new problem to Docker. If my database service dies, you know what happens? It starts back up and connects to the persistent volume. Personally speaking, yes all of my services / systems are distributed.
3 - Most people don't need to start their services exactly at this point and then stop at another certain point (which is why I pretty much brushed over it). If they do, there's plenty of tools to do this that can also utilize docker.
4 - What if a system died? Does this mean you SSH'ing in isn't a viable option? (yes...)
5 - Yes, you love negativity so clearly this is your favorite
6 - ...? What? Do you have something more to say?
It's cute that you like to poke holes and personally attack people, but really my comment was just how I go about things on a day-to-day basis. This is coming from someone who has 6 major Docker services abstracted out running all the time across 3 environments.. all capable of being updated via a `git push`. I think I have decent, practical advice to offer for other docker-minded practitioners and just decent advice to newcomers.
Your grievances circle around logs not being centralized, easily-accessible (1, 2, 4).. You also don't outline any solutions yourself.
Re: Why Docker Is Not Yet Succeeding Widely in Production
#145The security point here is something that confuses me about the current state of the ecosystem.
The article mentions that "most vendors still run containers in virtual machines", presumably since if someone hacks an app in a container they might be able to break out of the container and access other apps running on that host. But clustering systems like Kubernetes, CoreOS, AWS Container Service, etc. seem to be all the rage these days and they seem fundamentally at odds with this. The cluster might schedule multiple containers on the same host at which point somebody who hacks one can hack all of them.
How do you reconcile this? Do people running these clusters in production typically run tiers of separate clusters based on how sensitive the data they have access to is?
Re: Why Docker Is Not Yet Succeeding Widely in Production
#146Earlier quoted context omitted.
> is that if it ain't broke, don't fix it. I hate being passive-aggressive so I'll be directly aggresive here: this mentality is a way to say, "I don't want to revisit the operational aspects of my system because I don't like to do that work. Find someone else." Like any aspect of your system, your ops and deploy components can rot. Pretending otherwise is outright ignoring a consistent lesson offered by those who ca…
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 meaningful in the space due to a proposed risk aversion. My personal opinion is that we're all pretending we didn't write incredibly delicate and brittle provisioning and monitoring code with very dated tools.
Many people I know, and more than a few I respect, ultimately point to all their provisioning shell scripts as the ultimate reluctance to change things. "It will be really hard to migrate and test these! Generating them is a pain!" Of course, the elephant in the room is we all knew this going into it and we all know we SHOULDN'T have been doing things like generate shell script execution and using git to provision on production boxes and w/e other hacky shit we've done.
Of course, what we have is not any one thing but all too often an amalgam of spare hours and quick fixes and patches laid over some existing provisioning system like salt, ansible (or just a whole shit ton of puppet work).
Counter-intuitively, suddenly everyone has become a devops luddite when it comes to a genuinely novel approach even though container abstractions have already proven themselves at scale. People hem and haw and suggest that somehow it's not ready for production. Meanwhile major players in the space are already using them, even for core services, with excellent results.
Lightweight containerization has been used to solve this for awhile now. Docker as a product and initiative is relatively new, but to suggest it was the first example of a container engine used in production ignores the actual history of lightweight containers.
Re: Why Docker Is Not Yet Succeeding Widely in Production
#147While the article goes into the more technical reasons for not using Docker in production, the practical reason "Why Docker Is Not Yet Succeeding Widely in Production" is that if it ain't broke, don't fix it. The advantages of Docker do not necessarily outweigh the opportunity cost of rewriting the startup's entire infrastructure. Docker will likely be more prevalent in a few years with startups who have built their…
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, community services, or at the extreme end personal services.
When you aren't operating at absurd scale, "Google-style" infrastructure doesn't do you any favors. But the industry sure wants to convince us that scalability is the most important property of infrastructure, because then they can sell us complicated tech we don't need and support contracts to help us use it.
(Disclosure: I'm the lead developer of https://sandstorm.io, which is explicitly designed for small-scale.)
Re: Why Docker Is Not Yet Succeeding Widely in Production
#148Earlier quoted context omitted.
There's no need to say that at all. Just address the points and let everyone form their own opinions.
Because opinions are not the same as facts/best practices (nor is everyone's opinion equal). If you want to argue "this is the right way", be prepared to bring data and defend your statements. People here might be making critical decisions based on knowledge shared here, and they deserve the most accurate information possible.
I agree, and would enjoy a thoughtful discussion as to why my stack doesn't work and why I'm an idiot. Instead, it's just been countered by 5 bland rebuttals and a debate about whether or not I am an idiot and if I should be referred to as such.
Not sure what you're implying either, but you can tell in my comment, I never came out of the gates saying "This is the best way!"
Re: Why Docker Is Not Yet Succeeding Widely in Production
#149Earlier quoted context omitted.
Do you have a better way to say "your advice is bad. stop spreading misinformation"?
"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 seat on an airplane. Hell, if you look fat they should put you on a goddamn cattle scale and make you pay extra.
Re: Why Docker Is Not Yet Succeeding Widely in Production
#150So far my experience with Docker has been quite exciting, but I'm still to find a real good use case for it.
Also moving around a 700MB+ image when you can deploy some Debian package (or even setup a virtualenv, I do mostly Python), sounds a waste of resources. Add to that that moving volumes around is still an issue and... well, Docker has a lot of potential, but I doesn't fit very well in any of the projects that I'm involved in.