Live data from Hacker News

The sad state of sysadmin in the age of containers (2015)

vitavonni.de

51–60 of 324 posts

Re: The sad state of sysadmin in the age of containers (2015)

#51
I'm looking at this from a relatively neutral newbie POV. I've tipped my toes in both administering machines the "classic" way and with tools like Docker and Docker Compose. To me both have their benefits and drawbacks but Docker looks a bit better overall. Here's why:

1) The idea of immutable systems rocks. It feels like the logical next step from containers.

2) This is maybe just because of me but I have the feeling services that can easily be (automatically) updated (like with Docker) are gonna be more up-to-date on average than when I have to build every new version myself. (Although that could be automated probably.)

Re: The sad state of sysadmin in the age of containers (2015)

#53
post #42
post #15

Ever tried to security update a container? The whole point of using a container is that you can destroy it and build a new one easily. The new one should be built using up-to-date packages with security patches applied (and tested, obvs). Using the 'pets versus cattle'[1] analogy, patching a container feels like you're treating it like a pet. You should just kill it and get a new one instead. [1] https://thenewstack.…

The whole point of having a distro with a good reputation is that you can incrementally outsource your trust to them, one package at a time. OpenSSL needs a fix? One package update per machine, and if you have lots of machines, you update that. With VMs, you can use the same tools you use with any other machine. With containers, you are responsible for figuring out which ones need which packages and how to re-build t…

The "one package at a time" model assumes you care about per-instance uptime and bandwidth costs. The "reset the world" model assumes rebuilds and reboots are cheap enough not to have to.

I don't think either is necessarily wrong; there's not a huge distance between `apt-get install unattended-upgrades` and a daily (weekly, whatever) container rebuild except that you need to cron the latter. Unless you're using a different OS between the two cases, they can use the same package database, the same tooling, and so on.

Re: The sad state of sysadmin in the age of containers (2015)

#54
post #19

I recently had a similar discussion with people using npm for building a CSS framework library. I tried to explain the concept of getting a pre-downloaded tarball and using "make" (or similar) to produce target artifacts from source files in a deterministic, repeatable and reliable manner, without relying on any third-party servers being available and without pulling in dependencies that might have changed. It seems…

Don't turn it into an ageist thing, unless you are particularly old, there will be plenty of older developers that also don't understand this. It largely comes from understanding _why_ reproducibility is a good thing, and there are _lots_ of open source maintainers that understand this that are likely "younger than you". The vast majority of developers though focus on other things, that SQL injection attacks are stil…

It is way bigger then security, and hits upon quality of life and reliability.

Without a deterministic build I don't know what I check in actually works across environment, or if the deployment artifact works.

Re: The sad state of sysadmin in the age of containers (2015)

#55
post #36

Looked at the Debian wiki the OP linked to: >Debian currently does not include Hadoop packages. There are a number of reasons for this; in particular the Hadoop build process will load various dependencies via Maven instead of using distribution-supplied packages. Java projects like this are unfortunately not easy to package because of interdependencies; and unfortunately the Hadoop stack is full of odd dependencies…

Who still uses Hadoop anyway? https://spark.apache.org/ https://www.iguazio.com/data-science-post-hadoop/

Sell talk and buzzwords. Either author has no idea that Hadoop is ecosystem and Spark depends on it or deliberately mix Hadoop and Kubernetes, which aren't much related.

And good luck running Spark without Hadoop ;)

Re: The sad state of sysadmin in the age of containers (2015)

#56
post #8
post #2

I don't know that much about the state of container systems these days, but to me it seems it's the "comfortable" way in the "security vs comfort" tradeoff. Use where applicable and hope for better days.

But there are some environments where security is (almost) the only relevant factor, e.g. banking IT-infrastructure. I don't want my bank to pull arbitrary images from Dockerhub because that increases their comfort. Conversely, if I were sysadmin at a bank I would most definitely be concerned what was running in my network.

In 2015 I was running docker containers for a Gov organisation, where:

- docker containers were built from source

- Dockerfile published with the code

- Built in a new CI environment

- Pushed, Pulled and deployed from the sha

- Collecting network traffic, undertaking protective monitoring, that looks for those backdoors.

Just because you can pull arbitrary bullshit doesn't mean you have to.

Though for the record, the same sysadmins that whine about newer tools are generally the same ones that implicitly trust their older toolsets. Just because you can compile it, doesn't make it secure, so you need to be running monitoring solutions and hedging your bets no matter the tech.

Re: The sad state of sysadmin in the age of containers (2015)

#57
post #19

I recently had a similar discussion with people using npm for building a CSS framework library. I tried to explain the concept of getting a pre-downloaded tarball and using "make" (or similar) to produce target artifacts from source files in a deterministic, repeatable and reliable manner, without relying on any third-party servers being available and without pulling in dependencies that might have changed. It seems…

I sometimes have problem doing `./configure && make` because dependencies varies across different distro, which have some subtle differences that make it not easy as expected.

True. But at least it doesn't auto-download half the internet (with new and improved vulnerabilities of the day) and dump it all in your "project directory" (whatever that might be, I'm still fuzzy on the exact definition).

Re: The sad state of sysadmin in the age of containers (2015)

#58
post #6

Terrible article IMO. Hadoop is an awful mess, but it has nothing to do with Docker, which is simplistic in comparison. "Ever tried to security update a container?" Yes, I have! In fact you can maintain patch compliance in a container pretty much the same way you'd maintain a VM or bare metal Linux installation!

You missed the bigger point.

Just look at the popular images on Docker hub.

A lot of them involve messy build steps, including downloading binaries or source tarballs without verification.

It's often hard to know which dependencies a Docker image has, and therefore hard to track vulnerabilities and redeploy fixed images.

A lot of docker containers end up either running for a long time, or get rebuilt and redeployed often, but have pinned versions of base images or dependencies which still leaves vulnerabilities in place.

This is compensated a bit by the fact that Docker does provide somewhat decent isolation, and most containers are run in a cloud environment, behind load balancers and with decent security constraints. But there are many pitfalls in the whole process.

Containers provide a lot of advantages, and are certainly where things will continue to go.

But we need to figure out the tooling and ecosystem story to build, verify and update container deployments securely.

Re: The sad state of sysadmin in the age of containers (2015)

#59
post #19

I recently had a similar discussion with people using npm for building a CSS framework library. I tried to explain the concept of getting a pre-downloaded tarball and using "make" (or similar) to produce target artifacts from source files in a deterministic, repeatable and reliable manner, without relying on any third-party servers being available and without pulling in dependencies that might have changed. It seems…

I don’t think it’s age so much as it’s “well, that’s just what everyone does now”.

If you want to work in this industry you have to follow the herd; for better or worse.

I certainly don’t agree with it, but people have bills to pay.

Re: The sad state of sysadmin in the age of containers (2015)

#60
post #49

Standard Makefiles are really under appreciated today. They are simple and can be used with most any language, version controlled and have been around for decades.

But it's not a product you can sell or artificially inflate its monetary value so out the window it goes.
Post reply on HN