Comment by gspr | Hacker News Reader

Comment by gspr | Hacker News Reader

A little bit off-topic, but I hope it's relevant enough: can someone who's well-versed in Docker give me some pointers as to how I can use it in a better way? Let me elaborate.

I'm a bit of an old fart when it comes to software development. I prefer stable, slowly evolving solutions. I am a fan of the role of classical distributions. I abhor bundling every piece of software with all its particular versioned dependencies until everything works. I'm not gonna change. And that means I'm probably not the type to use Docker to deploy anything. That being said, I do see great value in it as a way for sysadmins to let semi-trusted people run their own OS on shared hardware without stepping on each other's feet. I love that it lets all of us run each our OS of choice on our compute machines at work. But that's just it: when I use Docker, I pretend it's a VM. I really would like to learn to use it in a better and more appropriate way, but whenever I try to seek out information, quality search results are absolutely covered in garbage 10-second-attention span "just type this until it works" blogposts.

Any pointers?

(Alternative question: are there some cleaner solutions than Docker out there for the workflow I describe above?)

You are confusing two different things.

One is using Docker as a deployment packaging method. The other is using Docker only for development and still deploying traditionally. Sure you can do both, but it doesn't have to be this way.

>when I use Docker, I pretend it's a VM

Also check anti-patterns 1 and 4 here

https://codefresh.io/containers/docker-anti-patterns/

Anti-pattern 1 perfectly describes how I am (hamfistedly) using Docker. Thanks! However, it doesn't really explain how to fix my mindset. It just says that I should ;-)

Could you give me some hints?

"There is no easy fix for this anti-pattern other than reading about the nature of containers, their building blocks, and their history (going all the way back to the venerable chroot)."

Basically learn the basics (cgroups, namespaces)

You should also study this https://github.com/p8952/bocker

> Basically learn the basics (cgroups, namespaces)

I think I have a basic grasp of those things, but still don't get how Docker uses them.

> You should also study this https://github.com/p8952/bocker

Cool! That's very usefl!

This is an important distinction and one that sometimes gets lost in the back-and-forth over Docker.

I feel like a lot of the complaints levelled at Docker pertain to the packaging and deployment use case. Where Docker really shines - even for small teams or solo devs - is as a development tool.

You have an increasingly rarefied perspective, and you should hang onto it.

Docker is a treadmill. Docker leads to Docker Compose leads to Kubernetes leads to whatever. It's a lot of noise and motion; you will increasingly encounter engineers who grew up on this stuff and assume it as a prerequisite, and are eager to climb the treadmill, thinking it's a ladder. You know about other options, and can decide when to stop.

Yeah I appreciate this. And since I'm a researcher rather than an engineer I'm also not forced to get on the threadmill. But like I said, I do see some value in using Docker as a tool to let a bunch of researchers run wild as semi-trusted superusers (by "semi-trusted" I mean we can be trusted not to purposefully do evil, but not trusted not to accidentlaly step on each others' fet). So I'd still like to learn a bit :-)

Try thinking of it as `git` but for an entire OS instead of merely a filesystem, and that you have multiple branches of your git tree opened simultaneously in different locations.

Or think of it as a set of databases that include the combination of the current state and the code ("migrations") to achieve that state, while allowing those databases to share the same history.

In other words, containers are a solution to state problems, not only "works on my machine" problems. The benefits are reproducibility and shared resources. It is "functional OS" as in "functional programming," a pipe of common operations to apply to inputs to generate a consistent output, and which can be forked anywhere in the history/pipeline long as the pipeline does not hide held state.

Coming back to the `git` analogy, a traditional VM with Snapshots is like saving ProjectV1, ProjectV2, ProjectV3, ProjectV2_fixed, ProjectV2_fixed_final, while a container solution is saving only the history and places where histories diverge.

To answer your alternative question, nix package manager (which can also be run as a standalone OS, NixOS) is an interesting alternative solution from Docker. Reading its documentation may also help in appreciating the alternative set of perspectives.

So, like ostree? https://ostreedev.github.io/ostree/

Yes, similar idea, except a change in a dependency in nix triggers a rebuild of all dependents, whereas it does not in ostree.

In Docker...it depends.

Reply on news.ycombinator.com