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

111–120 of 435 posts

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

#111

Post by ConceptJunkie »

Tehchops wrote: post #26
pc86 wrote: post #5

> None of these "fancy" tools still builds by a traditional make command. Is there anything more "get-off-my-lawn" than "These tools don't use the thing I like!"

> "These tools don't use the thing I like!" Pretty much. I know several admins who appear to be joining a growing pool of luddites who rail against anything new. They're particularly butt-mad about anyone drawing more salary than them. "DevOps" is their favored totem to direct their ire at. I used to try and convince them otherwise, but it turned out to be a completely futile waste of time. At the end of the day, per…

Hey, if JCL was good enough for IBM, it's good enough for me.

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

#112

Post by [deleted] »

davexunit wrote: post #76
myWindoonn wrote: post #9

Reproducible build tools are a thing. Try Nix sometime. nixpkgs has, say, Hadoop. nixpkgs can make Docker containers too.

nixpkgs isn't rigorous about reproducible builds. Hadoop is actually a great example of this. They do not build it from source, a prerequisite for calling a build reproducible. Instead, they download the binaries that the Apache project has already built and run patchelf on them to make them work. https://github.com/NixOS/nixpkgs/blob/master/pkgs/applicatio...

[deleted]

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

#113

Post by mancerayder »

Angostura wrote: post #38
ProAm wrote: post #10

Earlier quoted context omitted.

In reality it's all peachy until stuff doesn't work and no one knows why, or how to investigate an issue or remotely where to begin to troubleshoot it. Change and evolution is good, but I think there is still a lot to be said about knowing the basics to anything. Levels of abstractions eventually hurt more than it helps.

I think that may be hehind some of these tales of 'luddite sysadmins'. Sysadmins need to keep things running and complexity and dependencies, even if they being convenience is something that makes them nervous. It's not about being a luddite, its about being able to hold a mental map of how it all works, so that when it stops working you can dive in.

And not to mention getting called at 2 am because something didn't build or the release bombed and having to examine, for the first time, some over-complicated mechanism to build things that goes through some pipeline where you're eyeballing large log files full of long exception chains.

Devs see the world as one where velocity and progress is among the most important, while 'sysadmins' (a term no longer used by companies and recruiters, unfortunately) have to worry about keeping the applications actually up so they can be used.

DevOps just seemed to have swept the sysadmin under the rug under some pretty words about breaking down barriers. It feels more that devs broke down the wall sometimes. The amount of infrastructure chaos and mess and confusion I see today (as a contractor bouncing around different places) seems higher than traditional infrastructure shops of 10+ years ago.

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

#114

Post by lima »

notyourday wrote: post #105
agentultra wrote: post #78

Earlier quoted context omitted.

I recall the idea of "devops" from this book: https://landing.google.com/sre/book.html The stated goal of putting both systems administrators and software engineers on the same team is to reduce friction and increase communication. One of the worst, productivity-killing situations you can find yourself in when developing network software and services is caused by the traditional "old school" mentality of separating t…

> Don't build your containers from public, un-trusted images! Build your own images. Run your own, protected, registry. You still have all of the compliance and validation necessary and you don't end up debugging failed builds because one machine out of a thousand is running on some minor shared library version not supported by your software. You have just lost all the speed to production advantages of containers.

That's how I always did it (building containers ourselves), and once the pipeline is in place, it's barely more work than pulling public images.

Speed of production advantages are absolutely not due to pulling untrusted containers. If anything, it makes your life harder.

Hard to imagine any serious production setup not doing this... In most cases, you need to modify the containers anyway to suit your needs, and how else are you going to rebuild them all when the next OpenSSL update comes out?

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

#115

Post by smrtinsert »

notyourday wrote: post #105
agentultra wrote: post #78

Earlier quoted context omitted.

I recall the idea of "devops" from this book: https://landing.google.com/sre/book.html The stated goal of putting both systems administrators and software engineers on the same team is to reduce friction and increase communication. One of the worst, productivity-killing situations you can find yourself in when developing network software and services is caused by the traditional "old school" mentality of separating t…

> Don't build your containers from public, un-trusted images! Build your own images. Run your own, protected, registry. You still have all of the compliance and validation necessary and you don't end up debugging failed builds because one machine out of a thousand is running on some minor shared library version not supported by your software. You have just lost all the speed to production advantages of containers.

Not true at all. One time setup cost, in house knowledge, secure tools, optimized Dev workflow etc

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

#116

Post by [deleted] »

cwyers wrote: post #54
tortasaur wrote: post #16

Earlier quoted context omitted.

Web servers hosting binaries seem to be compromised more often than git repos. Transmission comes to mind as a semi-recent example.

But this isn't a website hosting a binary. These are binary repos hosted by Apache, who self-hosts their VCS repos as well. The idea that Apache can be trusted to host one safely but not the other is absurd, and the idea that you are more likely to notice malicious tampering via MitM attack on 2.9 million lines of code than you are a binary is laughable.

[deleted]

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

#117

Post by aleph- »

notyourday wrote: post #105
agentultra wrote: post #78

Earlier quoted context omitted.

I recall the idea of "devops" from this book: https://landing.google.com/sre/book.html The stated goal of putting both systems administrators and software engineers on the same team is to reduce friction and increase communication. One of the worst, productivity-killing situations you can find yourself in when developing network software and services is caused by the traditional "old school" mentality of separating t…

> Don't build your containers from public, un-trusted images! Build your own images. Run your own, protected, registry. You still have all of the compliance and validation necessary and you don't end up debugging failed builds because one machine out of a thousand is running on some minor shared library version not supported by your software. You have just lost all the speed to production advantages of containers.

Have you really? Building a base container to base all further images off of takes about a half hour with our build system. Fuether app builds are down to 10 minutes at a max and can honestly still be optimized. How exactly are you losing all the speed advantages?

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

#118

Post by mst »

notyourday wrote: post #105
agentultra wrote: post #78

Earlier quoted context omitted.

I recall the idea of "devops" from this book: https://landing.google.com/sre/book.html The stated goal of putting both systems administrators and software engineers on the same team is to reduce friction and increase communication. One of the worst, productivity-killing situations you can find yourself in when developing network software and services is caused by the traditional "old school" mentality of separating t…

> Don't build your containers from public, un-trusted images! Build your own images. Run your own, protected, registry. You still have all of the compliance and validation necessary and you don't end up debugging failed builds because one machine out of a thousand is running on some minor shared library version not supported by your software. You have just lost all the speed to production advantages of containers.

"speed to production" is not meant to be the primary advantage of containers.

"knowing exactly what you're running and being able to reproduce it" is meant to be the primary advantage of containers.

What you're basically saying is "if your container system admins do their job properly rather than throwing security and reliability out of the window, it can take a bit longer than not bothering". This is trivially true, but not really the point agentultra was making.

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

#119

Post by gm-conspiracy »

ebiester wrote: post #41
megaman22 wrote: post #14

Earlier quoted context omitted.

But I just don't understand why we have to have 47 half-built over-complicated build systems or job runners or whatever the new fad term is for every language, when there's something that does what they all do, is battle-tested, and has been around for decades. Everyone repeat after me. Makefiles are not scary. I can write a shell script. Do I really need to learn grunt/gulp/webpack/npm/rake/fake/maven/gradle/ant and…

I've written a makefile from scratch. My challenge to you: I want a makefile that has 20 third party dependencies and can be built on osx, linux, and windows. I can do this within an hour with gradle, ant, or maven. The ecosystem doesn't exist for this in make, and anything I could come up with to make it possible would end up being a tool that would look like automake and the monstrosity that it entails.

"osx, linux, and windows"

and you've already made sure they are running the same JRE version, right?

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

#120

Post by kazinator »

jiveturkey wrote: post #87
megaman22 wrote: post #14

Earlier quoted context omitted.

But I just don't understand why we have to have 47 half-built over-complicated build systems or job runners or whatever the new fad term is for every language, when there's something that does what they all do, is battle-tested, and has been around for decades. Everyone repeat after me. Makefiles are not scary. I can write a shell script. Do I really need to learn grunt/gulp/webpack/npm/rake/fake/maven/gradle/ant and…

careful, your dinosaur scales are showing. make is so bad you need automake to manage it. there are much better tools. sadly, nothing LCD (least common denominator) so as to gain wide traction. That said, for anyone distributing software, shame on them for not packaging their custom build so as to be runnable via ‘make all’ (just using make to drive everything else).

Make is only bad under the Autotools mess. Every build-related struggle in an open-source project that uses Autotools can be traced to Autotools, not to make.

Autotools wasn't invented to overcome deficiencies in make, but deficiencies in C portability across Unix flavors.

Those deficiencies are greatly diminished today, both by POSIX standardization, and there being fewer viable surviving Unix variants that anyone cares to build for.

Post reply on HN