Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The What, Why and How of Containers

annwan.me

Post reply on HN
Print view View original

121–130 of 132 posts

Re: The What, Why and How of Containers

#121

Post by bravetraveler »

forgotmyinfo wrote: post #57
bravetraveler wrote: post #43

Earlier quoted context omitted.

Considering my peers, same for system administrators/SRE/Operations people I'm the resident expert because I bothered to piece together "containers" = "applied namespaces"

I can't speak for anyone else, but I definitely feel like there's no time to actually learn about all of these tools before being thrown into them by management/other well-meaning ICs. The end result is everyone is using a tool they know nothing about, with predictable results.

Totally agree. There are many, many pulls for attention - I don't really fault these people I mention. It's just notable that with all of this noise, the smallest bit of specialization can go a long way.

Honestly, habits/being adaptable are most of it. For example, don't waste time searching if you know 'ansible-doc' or 'man 5 something.conf' has it

Re: The What, Why and How of Containers

#122

Post by flaminHotSpeedo »

codethief wrote: post #27
otabdeveloper4 wrote: post #22

Earlier quoted context omitted.

> Turns out that's exactly what containers are a packaging of! Well, no. When people say "containers", they always mean "Docker". And Docker also comes with a daemon with full root permissions and ridiculous security policies. (Like, for example, forcefully turning off your machine's firewall, #yolo. WTF!) P.S. I actually run systemd-nspawn in production, but I am probably the only person on earth to do so.

> Well, no. When people say "containers", they always mean "Docker". Not really / not necessarily. https://github.com/opencontainers/runtime-spec

Those in the know are familiar with OCI, etc. but (without hard data to back me up) I think it's still fair to say that the majority of people (lay people, if you will) consider them the same thing by virtue of ignorance.

Re: The What, Why and How of Containers

#123

Post by ianburrell »

zer00eyz wrote: post #38
silverquiet wrote: post #10

Earlier quoted context omitted.

Funny - it looks like you’re being downvoted for asking what I think is a very natural question. It’s one I’ve asked before; have we just created a more elaborate statically-linked executable via containerization? In the end, Docker/OCI seems like the universal Linux package manager. I’m sure I don’t have the full picture since I’m far more ops than dev though.

If you have a go/rust/zig binary as your application do you need a container to run it? Maybe, but it makes less sense at that point. If your doing Node/Ruby/Python/PHP then yes the container makes sense to drag your runtime to the server... Do containers (docker) make sense for dev. Sure, to a point. Because our dev (win/Mac) might not look like our deploy (linux).... If we move to a standardized remote dev model th…

The huge advantage of containers is that can use the same mechanism to run anything. Don't care if it is a single Go binary, dynamically linked binary, or Ruby interpreter and thousand files.

You might start off writing Go programs, but then need to run Postgres database for development. Or discover that need special library in some other language and easier to make its own service. Or need to run third-party service. With Docker, you run the image and don't care what's inside, and the isolation gives some assurance that won't escape.

Re: The What, Why and How of Containers

#124

Post by ianburrell »

zinodaur wrote: post #114
kube-system wrote: post #108

Earlier quoted context omitted.

That is one of the reasons why. Containers share the kernel and system resources. When you want to start running a bunch of containers in a particular configuration, that's when you'd use a container orchestration tool like kubernetes to define how and where you want those containers to run across multiple systems. While you could schedule containers manually, or just run your application on VMs or hardware manually,…

I guess I would prefer "kubernetes but with VMs instead of containers". The overhead of running in a VM is not very high, and a hypervisor can restrict resource usage much more effectively - so that we could still bin pack map reduce jobs on the same machines as live site services

Kubernetes has pluggable container runtimes. There are ones for running VMs, including the new lightweight VMs. They use standard OCI images.

Using VMs with Kubernetes only makes sense when you need the strict isolation. If you are running own code, then containers are faster. Containers also perform better because they can share resources on host. In Kubernetes, containers can have minimum and maximum limits, which means they can dynamically use space not used by other containers. VMs need to be allocated memory when they start.

Re: The What, Why and How of Containers

#125

Post by remram »

mikewarot wrote: post #116

Containers are a bad take on a solved problem. The problem was encountered, studied[0] and solved, decades ago. During the Viet Nam conflict, the Air Force needed to plan missions with multiple levels of classified data. This couldn't be done with the systems of that era. This resulted in research and development of multi-level security, the Bell-LaPadula model[2], and capability based security[1]. Conceptually, it's…

Containers are not a security mechanism, they are a deployment mechanism.

Re: The What, Why and How of Containers

#126

Post by pjmlp »

marcosdumay wrote: post #106
usrusr wrote: post #97

Earlier quoted context omitted.

I keep wondering where we would be now if we had not spent a decade or two eagerly running down that lane, before reassessing the be all end all solution nature OOP promised encapsulation to be. Perhaps not as far as we are after doing the meandering that we did, I think OOP has contributed a lot to the post-OOP world we live in now. It's not gone, it has just been demoted from ideology to tool.

We could argue that we've down the agents road since the microservices craziness. But this one backfired visibly and very soon and most people noped out of it in a blink. The OOP humanity is so heavily invested on has very little relation to that vision on the GP.

You mean Services Oriented Architectures, or Common Object Request Broker Architecture, or maybe Distributed Computing Environment?

Re: The What, Why and How of Containers

#127

Post by pjmlp »

adamgordonbell wrote: post #2

If you use chroot to run something, it's interesting how the dynamic libs you need to get in place grows until you are mirroring a whole linux in a subtree. It gives you a sense for how you end up with containers. One thing that is wild to me is how nix solves this problem, of things needing to be linked together. It doesn't solve it with containers, but by rewriting the location of the links in the executable to be…

That wasn't the deal in HP-UX vaults, Solaris Zones, System 360/MVS virtualization,...

The way they are used on GNU/Linux is indeed a solution to GNU/Linux's software distribution issues on a highly fragmented landscape.

Re: The What, Why and How of Containers

#128

Post by pjmlp »

rdtsc wrote: post #96
nurple wrote: post #73

Earlier quoted context omitted.

This^ This is one of the biggest issues with containers IMO. This and the layering system, which I think is poorly designed both to configure and to actually do the tasks it's meant to(build and delivery caching). The solutions to this problem in the space have basically been to provide scanners to crack open the containers and detect things with known vulnerabilities. But I have not seen (m)any solutions around thes…

It's like for a few years the whole computing world forgot about security updates and went on a container bender, when woke up one morning realizing what they've done, and then started adding various clunky solutions on top: mutable tags, various tooling to take apart container images and inspect the junk in there, notify and scan for issues etc.

You mean like proposing JSON as XML replacement, rebuilding from scratch all the XML tooling including validation, and when almost done with it, replacing JSON with YAML?

Re: The What, Why and How of Containers

#129

Post by pjmlp »

ianburrell wrote: post #124
zinodaur wrote: post #114

Earlier quoted context omitted.

I guess I would prefer "kubernetes but with VMs instead of containers". The overhead of running in a VM is not very high, and a hypervisor can restrict resource usage much more effectively - so that we could still bin pack map reduce jobs on the same machines as live site services

Kubernetes has pluggable container runtimes. There are ones for running VMs, including the new lightweight VMs. They use standard OCI images. Using VMs with Kubernetes only makes sense when you need the strict isolation. If you are running own code, then containers are faster. Containers also perform better because they can share resources on host. In Kubernetes, containers can have minimum and maximum limits, which…

So does plain Docker runtimes nowadays, specially since the company had to pivot into something else.

Re: The What, Why and How of Containers

#130

Post by rdtsc »

pjmlp wrote: post #128
rdtsc wrote: post #96

Earlier quoted context omitted.

It's like for a few years the whole computing world forgot about security updates and went on a container bender, when woke up one morning realizing what they've done, and then started adding various clunky solutions on top: mutable tags, various tooling to take apart container images and inspect the junk in there, notify and scan for issues etc.

You mean like proposing JSON as XML replacement, rebuilding from scratch all the XML tooling including validation, and when almost done with it, replacing JSON with YAML?

Exactly! YAML apparently is now terrible as well, but not sure what's next in the pipeline, toml perhaps?

I think it would be funny if we reverted back to s-expressions and started the cycle all over.

Post reply on HN