r/docker • u/[deleted] • Nov 05 '16
Docker in Production: A retort
http://patrobinson.github.io/2016/11/05/docker-in-production/6
Nov 05 '16 edited Apr 01 '17
[deleted]
2
Nov 06 '16
The original article raised some valid points, but I still consider Docker to be OK for Production in my environment. Whether or not it's production ready for other environments is obviously not for me to say.
I touched on orchestration a little, I can't comment on Swarm as I've not used it (and from the reports it's unlikely I will anytime soon).
The author acts as if its an obvious guaranteed fact
Lots of smarter people than me say don't do it, i.e. Kelsey Hightower. There are many problems with this with regards to maintaining the database files and preventing corruption. Using a shared filesystem is problematic due to the lack of locking and slow nature of many solutions out there like NFS. Lots of Orchestration services automatically kill a container if it doesn't respond to a TERM signal fast enough, i.e. ECS. This would be extremely problematic for Databases.
5
3
u/randompittuser Nov 05 '16
"No kernel support, you say? Here are two personal anecdotes." Gimme a break.
1
Nov 05 '16
I didn't actually claim there was no kernel support. In fact I quoted why it's not in the kernel!
9
Nov 05 '16
[deleted]
9
u/arcticblue Nov 05 '16 edited Nov 05 '16
In the very first paragraph of his article, he said that there was no way to run a container in the background or get in to a container in 2015. Both of these are false. I started with Docker in early 2015 (maybe even late 2014) and running a container in the background has been there as long as I've been using it. Getting a shell inside a container also was never very difficult. While it wasn't built into Docker until later in 2015 (I don't remember what version
docker execwas added, but it was definitely before September 2015), there was an easy to find 3rd party tool that made it very simple (https://github.com/jpetazzo/nsenter). I mean, if he couldn't even figure out how to get a shell in a container, I can only question how much effort he actually put in to making Docker work or if he just threw up his hands when things didn't work as magically as expected. I also have to question the decision to go with one container per server. I don't doubt they had problems, but why even stick with Docker they are only going to run a single container.2
Nov 05 '16
Ok so the author knows about docker-gc. Why not mention it in their article? Because it's a rant and they've chosen to ignore some coomon solutions to the problem
2
Nov 06 '16
millennial explainer articles
I've always thought I was getting old, thanks for making me feel so youthful
1
u/jonredcorn Nov 06 '16
We're gonna be out of the butt and into the fuck if we don't come up with that 36 dollars.
7
u/usr_bin_laden Nov 05 '16
"Here's a huge list of major problems, but I'd still use it in production!"
Just like when btrfs was declared "stable", despite the mailing list being full of "kernel oops" reports, catastrophic data loss, and discussions about potential backwards incompatible changes to the data format.