The sad state of sysadmin in the age of containers (2015) • Hacker News Board

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

#81

Post by pbalau » Mon, Dec 09, 2019, 12:26 PM UTC

onion2k wrote: 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 easiest analogy is that containers are like binaries. If you find a problem in nginx, you don't go on and patch /usr/bin/nginx, you uninstall that one and replace it with a binary that has the problem fixed.

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

#82

Post by etimberg » Mon, Dec 09, 2019, 12:31 PM UTC

radicalbyte wrote: post #43

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 like using Artifactory for this, you keep a local copy of all NPM / nuget / etc dependencies hosted next to your build infrastructure. What shocked me most about NPM is that it used to have absolutely 0 verification built in, yet it was being heavily promoted by very well known, educated and experienced tech celebs. All at a time when it was basically a hobby toy.

Last time I tried to use Artifactory for it's caching it barely worked. Would randomly 404 when a package was not in it's cache yet and you'd end up retrying a CI build for a while until everything was there.

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

#83

Post by dig1 » Mon, Dec 09, 2019, 12:32 PM UTC

smabie wrote: post #75

dig1 wrote: post #55

Earlier quoted context omitted.

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 ;)

Spark doesn’t have a hard dependency on Hadoop. Spark doesn’t have a storage engine, but you don’t necessarily need one.

Yes, but my comment was about serious, production grade setup.

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

#84

Post by pbhjpbhj » Mon, Dec 09, 2019, 12:32 PM UTC

regularfry wrote: post #44

maple3142 wrote: post #34

Earlier quoted context omitted.

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.

If you can do `./configure && make`, you can also do a `checkinstall` on debianesque systems, which gives you a package so you don't have to do it again.

checkinstall does rpm/slack too (or did), not sure how debianesque they are.

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

#85

Post by outadoc » Mon, Dec 09, 2019, 12:36 PM UTC

_wldu wrote: 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.

They don't solve any dependency management problems.

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

#86

Post by marmaduke » Mon, Dec 09, 2019, 12:40 PM UTC

lmm wrote: post #77

You've got to look at this in a context where platform package managers like apt are simultaneously 1) platform-specific 2) jealous, insisting that every language has to conform to their way of doing things and 3) fundamentally not very good, having very limited ability to do things like install packages for a single user or install multiple versions of the same package. Platform package managers like maven have been…

No I don't. I use Debian derivatives because I can apt get all my stuff without thinking hard, because those package maintainers have done the hard work.

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

#87

Post by Doxin » Mon, Dec 09, 2019, 12:44 PM UTC

lmm wrote: post #77

You've got to look at this in a context where platform package managers like apt are simultaneously 1) platform-specific 2) jealous, insisting that every language has to conform to their way of doing things and 3) fundamentally not very good, having very limited ability to do things like install packages for a single user or install multiple versions of the same package. Platform package managers like maven have been…

That's quite a negative view of the situation. The debian maintainers definitely don't insist that everything has to do things the apt-way. They only insist that packages for the official repos do so, which seems sensible enough to me. Everyone is still free to build their own deb packages or distribute their applications through install scripts or app images or any one of a hundred thousand different ways to distribute programs.

But if you want a package in the official repos you have to play by the rules they set, the primary one being that official packages ought to only depend on official packages. It'd simply be impossible to have any guarantees about the quality of a package otherwise.

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

#88

Post by pojntfx » Mon, Dec 09, 2019, 12:45 PM UTC

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…

18yo JS/Ruby/Go dev here. `make` is certainly known to us; it's just that platform-specific build systems (`mage` for Go, `rake` for Ruby, `gulp` for JS etc.) are simply more sane to set up per languages than using `make` for all languages and allows for efficient code reuse.

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

#89

Post by lmm » Mon, Dec 09, 2019, 12:48 PM UTC

marmaduke wrote: post #86

lmm wrote: post #77

You've got to look at this in a context where platform package managers like apt are simultaneously 1) platform-specific 2) jealous, insisting that every language has to conform to their way of doing things and 3) fundamentally not very good, having very limited ability to do things like install packages for a single user or install multiple versions of the same package. Platform package managers like maven have been…

No I don't. I use Debian derivatives because I can apt get all my stuff without thinking hard, because those package maintainers have done the hard work.

Well, clearly not, since you can't install Hadoop. Before you blame that on Hadoop, remember that it only requires some really quite basic things from its package manager, which apt is nevertheless completely unable to do: use libraries in the normal recommended way, play nice with Java, work cross-platform.

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

#90

Post by Havoc » Mon, Dec 09, 2019, 12:48 PM UTC

And it seems to be getting worse lately with everyone talking about their cloud-y build "pipeline". Which invariably seems to involve stringing together a bunch of different service offerings from startups that might not be here tomorrow.

It's hard to imagine something more fragile