> Sure, your ops team can put together a bunch of stuff manually. And then you can create a bunch of extra stuff that makes it easier for development to handle all of that inside virtual machines, and get the network bridging between those apps and the host machine working properly, and all that fun stuff.

I think this is one of the biggest reasons people use Docker, although they tend to forget to mention it since it's not exactly a technical advantage of Docker; in many ways, it allows developers to bypass DevOps or sometimes eliminate them all together. No more creating Jira tickets just to have a specific version of Imagemagick installed on a server.

I think it's one of the two biggest reasons. The other, possibly bigger, reason is that it gives you a way to install fairly complex software and have it reasonably configured and running right out of the box.

I use Docker to run stuff like PostgreSQL on my dev box. Not so much because it's a technically superior option (in truth, it's slower and eats more memory than installing it directly on my machine) as much as because it reliably lets me get up and running in a few minutes, just the time it takes to download the image, really. All the other options I've tried invariably require some fiddling, especially if you need an older version.

I suspect that all the other codepoints that have ever been spilled on the subject are mostly just an attempt to get ops on board with it.

(Disclaimer: All above comments are a mix of wild speculation and Freudian projection. I tend to come down against using it in production.)

At my work, we've had mixed results using it in production. I'd still prefer to using to avoid Ops, but besides that Docker comes with its own bag of issues even though it eliminates versioning conflicts.

For development, on the other hand, I absolutely love it. Being able to have different docker-compose.yml files for each of my projects and being able to spin up isolated versions of database services(each with their own volumes!) has been a tremendous win for me.

This right here. Can confirm, the #1 benefit of using Docker is that 98% of our "Ops" issues has gone away.

No they haven't. They are lurking around the corner waiting to hit you when you least expect it. The mugging you are about to get is what your ops team has had and are trying to prevent.

Enjoy the learnings...

There is only one possible place where this can really grow to be that kind of a problem: It's when ops isn't being involved.

(And if the relationship between development and ops has broken down to the point that each one is trying to work around rather than with each other, you're already screwed. The rest is just details.)

If ops is involved, then there's no real reason they can't take charge of making sure that anything that is running in production is being built up from minimal images where they can keep track of the technology stack and all the different versions of xyz lib that are running in production. They've just got to do it using a different tool chain.

And if ops isn't involved, I'm not sure how different this really is from the typical status quo, which involves unquestioningly running whatever uberjar full of unknown (to ops) 3rd-party packages that probably have their versions being selected using Maven's default version conflict resolution strategy, so that nobody, not even dev, really knows what exactly is running in production.

Your last argument is true of any software outside of the Docker ecosystem. Are you really going to read through every single directory in node_modules/ to make sure you know exactly what you're running? I don't believe anyone who answers yes, besides in the sense that NPM will produce vulnerability reports.

If ops does their job well, that's great. A lot of people aren't that effective at their jobs, and if someone in ops is stuck in PHP Land, unwilling to learn Docker, they're going to become a huge bottleneck in short order. Some people are incompetent, but there is a lot of people who don't particularly like their jobs yet get a sadistic joy out of playing the gatekeeper role, being the ultimate decider of whether someone else gets what they want. All the worse if upper management sides with them by default since, well, they're the "webmasters".

Yeah, I'm pretty biased because I've had situations like that on a few occasions.

I'm not necessarily saying that the production situation is always improved by Docker, but what I described is not an uncommon situation and I think it often leads to teams gravitating towards Docker when their last person in ops finally leaves.

> Are you really going to read through every single directory in node_modules/ to make sure you know exactly what you're running?

What, you don’t? Each dependency comes with a license notice. Everything needs to be pinned. The npm mess that comes out of pinning and unbounded versioning is precisely why we steer clear of it.

> Are you really going to read through every single directory in node_modules/ to make sure you know exactly what you're running?

Of course we are.

Not manually, of course, but we've got automated tools that generate a report of every dependency, including transitive dependencies, and its license and version, for all the platforms we use. We definitely keep an eye on these reports.

"But it's haaaaarrrrd" isn't a great excuse for letting things get out of control. We're developers. Taking obnoxious labor-intensive manual processes and making them quick and easy is the entire reason why our profession exists in the first place.

(Granted, the fact that a single import can bring in hundreds or even thousands of transitive dependencies to worry about is a big reason why I avoid the Node ecosystem like the plague. So there is that.)

> (And if the relationship between development and ops has broken down to the point that each one is trying to work around rather than with each other, you're already screwed. The rest is just details.)

IMO 90% boils down to that, regardless of what technology one side or other wants to use. If Ops is trying to push Dev to use a particular technology or vice versa. This happens whether you're talking Docker or a particular programming language.

Either side will see their preference as solving the problem of doing their job in the best way possible. If both sides are deaf to the problems seen by each other, it becomes a problem.

Honestly, the place where I see this stuff more than anything is when developers want tools that make them more productive, because the technological merits are harder to convey.

>>Either side will see their preference as...doing their job

And in your example they’d both be wrong. Such folks shouldn’t spend as much time worrying about their job description as about what will make the company successful?.

Companies don’t become great by everyone waiting around for only managers to decide when new roles or practices should come online. Employees at any level are allowed to consider the big picture. Why do they sometimes feel they’re not allowed to or would be discouraged from doing so?

If you carefully and thoughtfully put some time into slowly baking your opinions in a way you best guess helps your company end to end to achieve its most strategic goals with dev/ops as one part of that, your opinion will be more respected and influential.

It’s also a management test. Walk into your VP’s office, dispassionately and without self emphasis, make your case about how you should be doing xyz because it makes sense within the big picture.

Most times you can’t lose, even if the plan isn’t rolled out you’ll gain credibility. If you get your hand slapped, it’s a clear signal to switch departments or companies because leaders like that have low success rates, as well as usually not being much fun to work for.

Totally agree.

I think the "issues" they are talking about are not necessarily the ones that ops people are meant to solve, but about the issue of ops acting as "gatekeepers" that often create perceived friction in the deployment(and even development) process. By Docker putting the power of what prerequisites are made available to individual applications running on servers, it bypasses the middle-man and gets the job done faster. That's not to say there aren't trade-offs when using Docker with ops as a service, but some (usually developers) would say the trade is worth it. Let's just hope they are writing their Dockerfiles with security in mind. :)

I’d love for this to be true. Have you had anyone come in and do an audit? I find crazy stuff when I show up at No Ops shops and poke around.

Last year we had a $NAME come for an audit. Well known company and they did not know how to audit inside containers.

Still not sure how a corporation who runs RHEL contractually is able to use alpine and ubuntu based containers but it happens.

I dont work there anymore and I am glad because when the containers finally do get an audit and the customer is told for X years they havent been in compliance.... well..

> Still not sure how a corporation who runs RHEL contractually is able to use alpine and ubuntu based containers but it happens.

... why would it be a problem ?

We've done two audits now, only minor items

Can you expand on the crazy stuff you've seen?

Curious... What is your setup ?

AWS ? GCP ? ... managed k8s or you running it ?

Outsourcing your operations and pretending the problem is cured by docker is just a bit silly.

Docker on EC2. We had been running bare on EC2 before Docker using a homegrown chroot solution.

Where do you run your containers?

AWS Fargate. No infrastructure to patch or worry with. Just code and Dockerfiles.

You run your containers on a hypothetical platform that hasn't been released?

We half of all our QA processes to Fargate sometime around April, more than halved our compute costs. After the big summer milestone there is another big project to move the rest to Fargate. I prefer running my own k8s/kops cluster, but our B team got it stood up in a week and have had no issues in at least a quarter.

You are misinformed. Fargate is out and it works. I have containers running on it right now and they have been for several weeks now. You can select it or the old EC2 approach. Try it, you may like it.

In default docker installation on most Linux boxes, communication to docker socket itself requires elevated privilege. You can't even do `docker ps`.

In jobs I held - people who can pull images and run container on servers, they also could install stuff if they wanted. Is running privileged containers blocked? It just seems something broke down in engineering process, if developers has to bypass admins to install stuff on a server. What happens if that server crashed and burned?

Access vs authorization. You can use docker to get yourself local root. If you do it and admins find out you'll be in hot water.

Seriously. Just to circumbent the silly restriction of system you don't have root on? GNU Hurd was right all along.

> implementations for OS X and Windows

But they use virutal machines. For me, the disk access speed is very slow for a virtual machine. For example, elasticsearch daemon starts in 8s in Debian on real hardware and takes more than 30s in a VirtualBox. Everything that touches disk works slower.

It empowers developers to side step many of the best practices learned in SDLC over the last 20 years and ship code they shouldn't

The code is then running on a fault tolerant platform which masks the bugs and makes ops life hell when it comes to actual debugging.

Additionally upgrades and other assumptions about the base OS and system management are simply swept under the carpet with pretending those issues no longer exist.

Effectively it makes much much more work when things break and is great when it runs well or you run it in GCP where they take care of that part for you.

> you run it in GCP where they take care of that part for you

Although I'm generally inclined to agree with your positions on this thread (biased as I am due to my Ops profession), this doesn't seem like a valid criticism.

If Docker-on-GCP actually does address all the issues from the perspective of the developers/customers/users, then it's a plausible solution. The only consideration would be cost.

> One feature driving Docker adoption that I think a lot of people miss is that it's got fairly workable (if warty in one case and obnoxious in the other) implementations for OS X and Windows. That removes a lot of friction for developers who work in companies where IT won't support Linux on employee workstations.

Vagrant does this, too. Sure, it runs a VM, but so does Docker.

What does this mean? Docker does not run a VM. It runs cgroups, namespaces, etc.

Inside of Linux, yes Docker does utilize cgroups, namespaces and some other stuff for isolation. However, the GP is almost certainly talking about "Docker for Windows" and "Docker for OS X", which do not run directly on the host OS, and need to be run inside of Linux VMs (like Vagrant).

aye

Vagrant runs a VM per app. Sometimes more. Big difference.

Since when? I run multiple apps on vagrant every day. That is pretty standard.

And most likely you are running those multiple apps on multiple VMs.

Well, a VM per sensible unit of configuration management the user is supposed to choose. An "app" is a very slippery concept.

Well, there is a big difference, but not the one you've managed to come up with. Vagrant is normally used to run full VMs (although you can use it to drive Docker), so while you might run App, Supporting App, PHP, Apache, Node, Nginx, MySQL, Mongodb, and Redis all as separate containers, you'd probably put them all on the same VM. Your comment almost makes it sound like you don't understand Vagrant or VMs.