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

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

vitavonni.de

Post reply on HN
Print view View original

61–70 of 324 posts

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

#61

Post by BlueTemplar »

ThreeFx wrote: post #10
arberavdullahu wrote: post #9

Earlier quoted context omitted.

I don't think you should put security at any case in tradeoff, by your argument one can save passwords in plaintext because its easy and comfortable, but its just not acceptable and this would effect not only your app but every app that your users use.

I see the value when running e.g. home instrastructure on some old laptops or other non-critical stuff. Most people have NAT at home and thus whatever services they pull and listen in their local network aren't exposed to the outside world, and they can enjoy mopidy/NextCloud/whatever without going through a lot of hassle setting it up. Of course once we come to enterprise environments the opaque build/deployment pro…

30% of the Internet already uses IPv6. NAT is obsolete and was never supposed to be used for security anyway...

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

#62

Post by apexalpha »

tomtomtom777 wrote: post #33
pram wrote: 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!

The article focuses on Hadoop, but the generalization to containers is spot on. Containers have become the first stop method to hide overly complicated build processes. When you've noticed your wiring has become a complete mess of knots, just put it in a box so no one will trip. It seems to me that containers are useful for deploying final setups, but should be a no go for packaging tools.

I would see it more as to dividing your wiring into segments with breakers in between so that one rogue device doesn't bring down the whole network.

Seems a good thing, to me at least.

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

#63

Post by Annatar »

the_duke wrote: post #58
pram wrote: 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 o…

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

Already done: Solaris zones. Available in the SmartOS distribution near you. Combine with OS packaging, imgadm and vmadm commands for maximum impact.

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

#65

Post by indigochill »

tomtomtom777 wrote: post #33
pram wrote: 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!

The article focuses on Hadoop, but the generalization to containers is spot on. Containers have become the first stop method to hide overly complicated build processes. When you've noticed your wiring has become a complete mess of knots, just put it in a box so no one will trip. It seems to me that containers are useful for deploying final setups, but should be a no go for packaging tools.

>When you've noticed your wiring has become a complete mess of knots, just put it in a box so no one will trip.

On the other side of the coin, putting stuff in boxes is the essence of architecture. CPU opcodes? Boxes. Compiling readable code into bytecode? Boxes. Objects? Boxes. Functions? Boxes.

Sure, it can be abused. There might be spaghetti in those boxes. The spaghetti should be chopped into digestible chunks (smaller boxes!). But putting it in a box makes that an implementation detail. Putting stuff in boxes is still progress.

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

#66

Post by rtpg »

was_boring wrote: post #54
pwagland wrote: post #37

Earlier quoted context omitted.

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.

checksums are a thing, as well as package mirrors or outright holding onto the file and checking in a binary.

There's loads of ways to know what you are using without needing to strip mtime's from zip files.

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

#67

Post by itg »

buzzkillington wrote: post #48
alfozan wrote: post #36

Earlier quoted context omitted.

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

Spark is worse because you need Scala as well as regular Java. I've tried building it for my day job, I would rather have a colonoscopy without sedation. It's more pleasant and dignified.

And then add PySpark on top of that. Couldn't leave my last job fast enough when they decided to use Hadoop/PySpark when the largest incoming files we received were at most a few GBs.

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

#68

Post by dig1 »

The same applies today for nodejs and go, but the same was happening with python, ruby and perl libraries in the past.

However, this only shows that standard distro packaging approach is broken or was broken all the time. First, if you want to distribute you application (or library) via distro packages, you'd either have to build them and publish on your site or have to go through long mailing process to satisfy distro specific packaging guidelines and hope that your package will end up in standard (or extended) distribution. Debian is also notorious for "reviewing" and modifying source code, without contacting authors (remember Debian SSH fiasco).

I had, not once, unpleasant experience with this process.

Today, things are much easier - pack your whatever and put on dockerhub, maven or github. No middleman and no headaches just to reach your users. Sure, there are drawbacks (like mentioned in article), but we'd have to leverage things like GPG and proper package signing. Now, that is totally different story, because cryptography, even the basic one, is PITA for most developers and users. You can't have both :D

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

#69

Post by y0y »

jwr wrote: 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 know you're taking some flack for making it about age, but I do think there's some merit there. I'm 34. I feel like I'm in the middle in terms of software developer / sysadmin age. Lots of bright minds came before me and there are lots of bright minds out there right now in their early 20s.

A key difference is I can remember a time when network connectivity was flaky. When it was hardly a given. Even when it was available, the download times alone could often constitute a large part of the overall build time.

I think that we have all become complacent with regard to internet connectivity and service availability, but I think the younger you are the more complacent you are likely to be. If github.com goes down entirely, let's be honest - there are a lot of Jenkins builds that are going to be in the red.

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

#70

Post by hvidgaard »

tomtomtom777 wrote: post #33
pram wrote: 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!

The article focuses on Hadoop, but the generalization to containers is spot on. Containers have become the first stop method to hide overly complicated build processes. When you've noticed your wiring has become a complete mess of knots, just put it in a box so no one will trip. It seems to me that containers are useful for deploying final setups, but should be a no go for packaging tools.

I don't think it's fair to blame containers for that. Just because someone programs a shitty product in Visual Studio, does not mean it's a problem with Visual Studio.

What containers does beautifully is dependency containment. I make something and put it inside a container, with the exact dependency it needs and it'll work alongside other containers with a program that might have a different incompatible dependency.

What we're seeing is not so much that developers suddenly decides to throw best practice into the wind. They just do not have to put the same amount of effort into fixing the broken process exactly because we have dependency containment. I believe we would see the same mess without containers, and the process change that would fix one would fix the other.

Post reply on HN