Or if you can't?
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.
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. And by the time you've got it completed and working nicely, you'll be ready to launch your own Docker competitor onto the market.
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 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.)
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.
Enjoy the learnings...
(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.
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.
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.
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.)
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.
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.
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..
... why would it be a problem ?
AWS ? GCP ? ... managed k8s or you running it ?
Outsourcing your operations and pretending the problem is cured by docker is just a bit silly.
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?
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.
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.
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.
Vagrant does this, too. Sure, it runs a VM, but so does Docker.
Every "Docker Considered Harmful" post I've read basically boils down to "Why would you use Docker if you can use the 10 technologies it wraps around and manage them yourself instead?" Why would I want to do that if I don't have to? Docker wraps these things well. There are weird defaults and there are some popular patterns in the community that are a bit backwards, but you have the power to work around it. Don't run your containers as root and run a dumb init process in your container. That's half of the posts complaints gone right there. Complaining about defaults is one thing, claiming that bad defaults make a technology "harmful" is just lazy.