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

141–150 of 435 posts

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

#141

Post by claviola »

sonaltr wrote: post #34

not to be pedantic but why should containers be patched for security issues? the entire point of containers (and orchestration systems) is the ability to push updates without downtime. Just update with a newer container....am I missing something? Also about container security - a strict process internally can easily help counter that (I believe Shopify had a nice talk about it at the Google Cloud Platform event in To…

How many people do you see setting up a deploy pipeline that includes pulling security updates into the base image and redeploying as needed? In my experience, it's much more common to see docker images that have been untouched for months with zero accountability of what exactly is running there.

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

#142

Post by icebraining »

YouAreGreat wrote: post #134
icebraining wrote: post #92

Earlier quoted context omitted.

Are you saying that every new black hat is immediately a professional? Or that there aren't any new black hats? In every other activity of human life, new amateurs appear as the older ones become professionals. Where are the visible exploits from the new amateurs?

> Are you saying that every new black hat is immediately a professional To a degree that's what I'm saying. Sentencing for "computer crimes" when perpetrated by non-corporate entities has reached epic levels. I'm sure qualified talent takes that into account.

Has sentencing significantly increase around the world? The US is not the only source of malware.

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

#143

Post by pvg »

cookiecaper wrote: post #123
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…

The thing is that any separation in the roles in ineffective. Things shift around some if you embed an ops guy into the dev team directly, but it doesn't resolve the core problem. This applies to DBAs as well as ops or any other software-side segmentation as well. The core problem is that there are "ops guys" and "dev guys". That creates conflicting incentives, even within the same team. It creates tension and a dyna…

The thing is that any separation in the roles in ineffective. [...] The right axis for separation is hardware v. software.

Any separation is ineffective except along this one particular completely arbitrary dividing line? If that were true we'd still be hunting and gathering and nothing else.

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

#144

Post by dullgiulio »

badloginagain wrote: post #99
emilsedgh wrote: post #33

Earlier quoted context omitted.

I think the logic is, if we didn't rely on Containers and prebuilt VM's, Hadoop had to be easier to build to be useful.

The point everyone seems to be missing, and the one I think most important, is that we're no longer building from trusted sources. Build systems just download and run random code from the internet without verifying that its the correct code, from the correct source. Its a ticking time bomb.

There is SSL/TLS, unless it's done wrong (invalid certificates get ignored by the dependencies manager), it's safer than the old "md5 of the file" systems.

Now, some dependencies are fraudolent (especially true in the Javascript world because it eventually targets a lot of user browsers), but nobody ever checked the sources anyway...

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

#145

Post by alfalfasprout »

mr_tristan wrote: post #91

This is definitely a rant that obscures the underlying point: the introduction of _untrusted_ or _unreliable_ network resources, frequently hidden in a string of dependencies. I'm baffled how often I see an someone throw this sort of craziness - "go fetch this thing from some random third party" - into very important places, such as the startup procedures of a container. It's something I see in a culture of the two p…

You know, I used to agree with you. But the reality is you have to weigh the massive productivity boosts that things like docker bring to the table vs. the potential issues it can bring. To a large degree, good perimeter security mitigates a lot of the concerns of containers themselves running slightly out of date software.

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

#146

Post by icebraining »

mcguire wrote: post #135
icebraining wrote: post #71

Earlier quoted context omitted.

I think that is the author's logic. Except it's not very logic, since Hadoop (or Bigtop) doesn't use either.

Picture this: you need to use Hadoop. Do you: A) work through building it yourself, or B) get a container that claims to have a running Hadoop and hope it works for you? If B wasn't on the table, what would happen?

If I need to use Hadoop, I'll download one of the pre-built binaries that they offer on their site.

You'll notice that the Debian Wiki users have given up on building it since 2010. That was three years before Docker even appeared. Almost nobody was using containers back then.

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

#147

Post by digi_owl »

gmfawcett wrote: post #107
eropple wrote: post #93

Earlier quoted context omitted.

Million+ line codebases were written entirely in COBOL. The world advances.

Some were, I guess, but hardly all of them. The Linux kernel is built with Make, for example.

There are been several attempts at introducing a new build system, but they have been all shot down over introducing dependencies.

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

#148

Post by mcguire »

eropple wrote: post #70
vlowther wrote: post #65

Earlier quoted context omitted.

Bash, but... > --show me its arrays declare -a > Show me hashes. declare -A > Show me sets. See above > Show me the basic building-block primitives of software, thing() { local localVar # Yes, it would be nice to have lexical scope as well as # dynamic scope, but... }

Sure. All of which are clunky, opaque, and harder to work with than any other language I have used in the last decade . And besides: if I can install bash, I can install something specifically better for whatever I'm doing instead.

Speaking as an (ex- (sort of)) sysadmin,

"All of which are clunky, opaque, and harder to work with than any other language I have used in the last decade."

Wrong question. A better one: Is it more clunky, opaque, and harder to work with than every other language that's appeared in the last decade? Because no one seems to agree on what is specifically better.

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

#149

Post by spiderjerusalem »

ex_amazon_sde wrote: post #63

Ex Amazon here. Most grumpy system engineers did not disappear: we got hired by Google/Amazon/etc to build large-scale infrastructure... and sometimes sell it back to you as a service. Believe me or not, most of the underlying infra does not run on the popular technology of the year. Far, far from it. That's why it works. Modern devops, with its million tools that break backward compatibility every month sometimes be…

What fascinates me about this is, and sorry for being morbid, but what happens when y'all die? Does knowledge of the lower levels of the stack go away with your generation, or will there be enough of us young ones picking the important stuff up?

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

#150

Post by wwweston »

Perhaps interestingly, I've had some similar complaints about package managers like homebrew.

I've noticed over the last decade that a certain level of knowledge about building from source seems harder to find via search or engaging in a community forum/chat. The assumption is often that everyone will be using the package manager (I'd say that's especially true on macOS, but it might be an artifact of me spending more time there since it's been my most used dev machine), so if you have trouble building something, the answer will frequently be "just use homebrew -- whoever maintains the formula will already have solved your problems for you."

There's two problems with this: first, that's presumably true for the source build, and if you can hit a case that the source build doesn't work for, chances are pretty good you can hit a case that brew doesn't work for (my experience is that more often than not they go together). Second... I'm happier to use package managers for applications meant to live on my machine and never go live elsewhere (heaven knows there's lots of stuff I just want to install and get on with my life rather than fiddle with), but for applications I'm deploying, it seems to me it's generally wise if someone involved in the project has a picture of the build details and dependency graphs in their head.

Some of the automation we're throwing at operations is really convenient. It's not simple, though. And depending on how much forethought is put into it, I'm starting to think of it as ... maybe not technical debt, but a technical credit card which is super convenient at times, but also can easily become debt if you're not careful with it.

Post reply on HN