The biggest issue I've had with Docker is that Dockerfiles aren't designed to be reproducible, so regressions are practically guaranteed. If there were tooling around pinning versions of Linux distro packages, and maybe a few select PL package managers like Go, Node, Python, Ruby, it would make a huge difference. I tried to do this by hand and finally gave up.

You can stack layers (where you install exactly what you want) and create an image that is deterministic.

Even if you install from repos in the dockerfile, they should have version numbers.

How is this different compared to creating a new VM for every single application?

IDK, I don't use docker or a separate VM per application.

I guess I'm old school but I install the stuff on my linux instance or server and work out the dependencies so they don't clash.

I haven't found it that difficult.

Just cos the devs want to throw some ill conceived container over the fence onto my systems, doesn't mean I let them. ( I mean I guess they can, but only if they get the support calls instead of me.)

This can work for simple projects where the dependencies are all similar but it doesn’t scale well and, if you’ll forgive the unsolicited career advice, I would be worried that the breaking point is “We switched to the cloud and told your boss’s boss’s boss that you had been holding us back”. I much prefer finding some balance which doesn’t position you as the Department of No.

“We switched to the cloud” isn’t a decision made by development orgs in any non-software company. In most businesses, supportability by IT and boring bureaucratic processes are king.

“Adopt whatever buzzword shit developers are into” is about the worst career advice you can actually give sysadmins that work in non-cutting edge companies.

> “We switched to the cloud” isn’t a decision made by development orgs in any non-software company. In most businesses, supportability by IT and boring bureaucratic processes are king.

This might have been true in your experience but it hasn’t been in mine (.com, .edu, .gov). There’s common term (shadow IT) for what inevitably happens: someone hires their own staff, gets their own servers, arranges their contractors to host it, architects their application requirements so it can’t be run by central IT, etc. The reason it happens is that the IT department is not listening to its users and thus giving them a strong incentive to find alternatives to accomplish their jobs — and they’ll almost always win unless the CIO is politically untouchable and has an iron hand on the budget.

This is especially true in these cases: using the cloud or containers is what senior management are hearing from all of their consultants, and likely many peers. If you’re trying to hold that back without a really good reason, it is unlikely to end well for you unless you’re related to the CEO, especially since it’s easy to find people with equivalent or greater experience who can point to good results from having adopted what are now relatively mature technologies with plenty of case studies.

> “Adopt whatever buzzword shit developers are into” is about the worst career advice you can actually give sysadmins that work in non-cutting edge companies.

If you think that’s true, I would suggest you reread my comment and ask whether that’s a fair reading of my suggestion about finding a way to balance concerns. There is a huge amount of space between “no” and “you can run whatever you want”.

I deploy big complex projects this way.

I've built sophisticated automation to achieve this, so it's all reproducible.

I just don't use Docker that's all. It doesn't bring anything to the able that I can't achieve more simply some other way. And it has it's own problems.

I've been a sysadmin for 25+ years and I've administered production DNS server, mailservers, web server, app servers, routers, switches ...

I think stuff like docker and k8 appeals to people today because it promises that you don't have t understand any of that old stuff.

But to me it just makes my life harder because I don't need the underlying tech abstracted away. If anything it makes my life harder to add an unfamiliar layer on top.

I'm not worried, there will always be market for guys like me. When the fancy new stuff stops working, someone has to fix it.

I've also been doing that for about 25 years, with a similar list, and full automation since ~2001 or so. I haven't found that approach to scale very well because it requires a much higher level of sysadmin skill & application-level knowledge, maintaining a somewhat extensive list of backports or custom builds, and the ability to customize each application to work with a filesystem layout which avoids the conflicts which inevitably arise. Automation is important to making that work at all but it still means that any time things change hands there's a non-trivial amount of code to review before you are confident about making changes and it tends to require elevated privileges or greater levels of coordination between the developers and operators.

The reason why containers are popular is that you get a simple way to manage all of that and it's completely standard on every project. App A doesn't need to be modified to coexist with App B because they're running in an isolated environment, the sysadmin doesn't need to learn how the container was built just to manage services or deploy new instances, builds are much faster because of the layering model, you can deploy a single tested image with no chance of differences creeping into your automated deployments in testing & production, etc. All of that is something which you can achieve with other tools but there's a huge win to not having to reinvent each wheel when you encounter it and being able to reuse other people's work easily.

Note also that I said “containers” instead of Docker — some people might prefer, say, podman / buildah but the key concepts of having a clear support boundary with an isolated-by-default filesystem model are really more important than the implementation.

> the sysadmin doesn't need to learn how the container was built just to manage services or deploy new instances

I disagree on that point.

Just taking a docker image from a developer and deploying that to production does not work to well in my experience, and guess who gets the support calls when things break?

If a sysadmin gets a say in how the container images are configured, it usually works out much better.

Also partitioning the filesystem to avoid dependency clashes used to be more important when I used rack mounted servers. Now it's easy enough to deploy separate cloud instances to partition things. And it's a real VM with real tools on it so I can diagnose problems if they arise.

> Just taking a docker image from a developer and deploying that to production does not work to well in my experience, and guess who gets the support calls when things break?

In my experience, that's been about the same for any mode of deployment by a developer without ops experience. The main thing Docker added was standardizing the mechanics and avoiding certain classes of errors like not having reproducible builds or deploying local artifacts inconsistently.

You know why docker is being used instead of this approach?

Because your automation is made by you, and for you, no one else can take it over if you leave. And even if they can take it over, they will have way higher salary - compared to the container based system.

To be fair, pretty much every single place I've seen docker in use there have been custom automation systems in place. Docker creates artifacts, not automation, so it really doesn't help solve that problem. Kubernetes on the other hand, does help, though you'll never get away from some custom parts in a delivery system, as all systems are different. That's not a bad thing.

This sounds like an immature attitude to take towards the people that work with you and just makes you sound like the stereotypical basement sysadmin that needs to control everything and knows better than everyone else.

Containers are terrible for bureaucratic institutions. It moves security patch management to the development org that builds the containers and development orgs typically don’t have the tooling/process to do this.

Source: consulted for a company that got bitten by allowing containers without a patch management process for vulnerabilities.

Perhaps but they are happy with the results.

They tried it their way for a couple of years, and there were performance problems and outages.

Good luck doing something like that at scale with thousands of instances.

I think you just pinpointed what Docker should have been focused on from the beginning to monetize their creation. There are so many obvious ways to make Docker work for enterprises.