101–110 of 290 posts
Earlier quoted context omitted.
> If this is your advice then you shouldn't give advice. Stop with the blaming statements.
Do you have a better way to say "your advice is bad. stop spreading misinformation"?
From my experience it is still buggy. For example, this bug: https://forums.docker.com/t/docker-export-intermediate-size-... No one seems to know anything about it. Also, when we upgraded from 1.6.3 to 1.7, devicemapper started having issues. On top of the bugs, the limited networking support is very, well, limiting. I would be very hesitant about using it in production at the moment. That said, I can also see the po…
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.
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…
Earlier quoted context omitted.
> If this is your advice then you shouldn't give advice. Stop with the blaming statements.
Do you have a better way to say "your advice is bad. stop spreading misinformation"?
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.
Earlier quoted context omitted.
Do you have a better way to say "your advice is bad. stop spreading misinformation"?
There's no need to say that at all. Just address the points and let everyone form their own opinions.
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 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…
While 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…
> 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…
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...
Earlier quoted context omitted.
I have zero problem with a hybrid setup. I'm not running Docker just for the sake of running Docker. I'm running Docker (specifically Dokku) because it drastically simplifies deploying new builds, and graduating those builds between environments. I know a large part of this article was that Docker complicates rather than simplifies the situation. I guess if you're trying to be a Docker purist (for no reason) then sur…
If the goal is to simplify deployment process, why not use something like Capistrano or Fabric? You can run 'Cap deploy '
Something that's more declarative is definitely superior. Why? Because it will be shorter and easier to debug. I am not a fan of `git push` as a deployment strategy (because git is a version control tool, not a deployment tool), but it does force you to create and use a system that's by definition declarative. This is why I use dokku for my new projects.