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)

#361

Post by nunez » Thu, May 17, 2018, 3:59 AM UTC

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!"

Sort of

Every build system is like Make, but more friendly for their language (IIRC Make was originally for compiling C and C++). Make just so happened to become generic enough to build damn nearly anything and also get bundled into most Linux distros.

I think the author is arguing that having to install a shit ton of dependencies to use some other Make-like build system is garbage. That’s true in some cases. But I wouldn’t want to use a Makefile for packaging Node; npm is great for that and understands how Node works.

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

#362

Post by nunez » Thu, May 17, 2018, 4:04 AM UTC

vlowther wrote: post #65

eropple wrote: post #50

Earlier quoted context omitted.

Blatantly false? OK, put up. Forget `sh`'s JSON parsing, I'll make it easy on you--show me its arrays. Arrays, plural, you can't use $@ as a bail-out; I need more than one. Show me hashes. Show me sets. Show me the basic building-block primitives of software , because build pipelines are software . It's 2018. If your language can't do this stuff without babysitting, it effectively can't do it because nobody's got the…

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... }

Have you SEEN how Bash array indexing works? It’s not exactly user friendly. Same with Bash hashtables (which I don’t think are really hashtables).

I love Bash and use it way more often than I should, but Bash is not a friendly language. Mocking and stubbing functions is really hard to do, which makes tests awkward, even with BATS. And you need to watch the file descriptor to which text is sent to avoid things get globes unexpectedly. And you need to properly scope your vars to avoid unexpected collisions. And everything regarding sourcing and importing dependencies. Etc.

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

#363

Post by nunez » Thu, May 17, 2018, 4:14 AM UTC

kazen44 wrote: post #202

Animats wrote: post #179

If you thought having to deal with old COBOL programs was a problem, it gets much worse. When there are 10 year old containers in production, and the parts to rebuild them are long gone, then you have a real problem. There's a reason that Google has internal systems which can and do rebuild everything from source.

This is actually a very important point that gets ignored a lot. What will happen if public container images are no longer available for building your application? Your in a for a world of hurt if a major dependency of your application doesn't work anymore because someone pulled the image.

The right answer is to use your own repository and pull those images in-house where they can be scanned and verified, I.e. , run a container from that image, scan it using security tools, then action from there.

You can also kind-of recreate a Dockerfile from an image using docker history: https://stackoverflow.com/questions/19104847/how-to-generate...

In the general case, it’s the same as a Ruby Gem or NodeJS module going away from rubygems or npmjs; once its gone, its gone

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

#364

Post by mmt » Thu, May 17, 2018, 4:15 AM UTC

commandlinefan wrote: post #349

mmt wrote: post #326

Earlier quoted context omitted.

Actually, as a sysadmin, I sympathize with you, since I consider that kind of situation to be a sign of, essentially, bad system administration. It also sounds like it might be at a larger company. Personally, I've always considered it a significant part of my job to make developers' jobs easier, especially with something like deployments and dependencies. As such, I disagree that we've brought our own "obsolesence"…

Like I said - it’s not all of them, but a lot of them. And yes, this is endemic in big companies, not in startups.

Sadly, this attitude among my fellow sysadmins is one of the reasons I avoid larger companies.

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

#365

Post by nunez » Thu, May 17, 2018, 4:22 AM UTC

JohnStudio wrote: post #195

I think the entire statosphere of DevOps is just about dead on the whole in 2018 .. in retro, after working with things like Docker .. and more specific industry variations beyond the Amazon tech, it makes no sense to dwell on the security / control of a dedicated systems admin professional since the tools are all outside the local domain anyway. The rest from VoIP to IoT to container services are managed whole-sale…

Nah, you’re right

The entire purpose of DevOps IMO was to close the gap between sysadmins and devs through code. Devs doing everything, including infrastructure, was and is the entire plan! Public cloud made this super duper easy.

The problem is devs don’t want to manage core infrastructure (VPCs, networking, modules for deploying lambdas and database clusters and container orchestration clusters, etc) and somebody has to do that stuff

Ideally, those would just be features like any other software team, as it’s all API calls at the end of the day. But lots of companies have issues with structuring their platform teams like software teams because its “not software” even though it is

This problem is more deeply entrenched at large companies with hundreds of millions of dollars of compute that they own that is owned by an old school IT function that can’t fathom the idea of either giving it up or making it accessible like cloud and would rather pay VMware tons for tools that make teams even slower than have their sysadmins become developers

Then there’s the whole protectionist “You’re taking my job” and “devs can’t possibly know this much about $infra” that isn’t dying off anytime soon

It’s complicated

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

#366

Post by nunez » Thu, May 17, 2018, 4:29 AM UTC

rambossa wrote: post #86

> Ever tried to security update a container? Wouldnt the approach for security updates be to replace the container?

Pretty much. Update the image or do the update in a container based off of the old image and package that

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

#367

Post by _bxg1 » Thu, May 17, 2018, 4:42 AM UTC

Seems like the security issue is easy to fix? Only installing binaries you trust and comparing them against a hash is basic computer admin 101; it's not specific to Docker. Just make sure you trust whoever made the docker image, and that they give you a hash to compare it against.

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

#368

Post by Ceezy » Thu, May 17, 2018, 5:20 AM UTC

gaius wrote: post #267

jcastro wrote: post #263

> Essentially, the Docker approach boils down to downloading an unsigned binary, running it, and hoping it doesn’t contain any backdoor into your companies network. I don't get why people still claim that this is "the Docker approach". This is not the docker approach, everyone hopefully knows this is an anti-pattern by now.

I don't get why people still claim that this is "the Docker approach". Because it is the Docker approach (as distinct from the container approach necessarily).

You can download images from trusted sources with Docker

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

#369

Post by AndrewUnmuted » Thu, May 17, 2018, 5:40 AM UTC

seorphates wrote: post #278

gm-conspiracy wrote: post #243

Earlier quoted context omitted.

A good sysadmin would not look like they are doing much work (everything is humming along and can self-heal minus physical problems), but a good devops person is constantly busy.

I sort of agree but a good sysadmin was never idle on the inside. I'm seeing good devops people getting worked well beyond what I'd consider reasonable expectations i.e. "Oh, look, you can do everything! Here's everything!". They're being perverted into a role having a full load of pure operations with shit for processes (and, often, systems) and an expectation that you have time to automate and shore up all the shit…

I think a lot of data engineers and transcoding folks would have similar reports. But you’re right; the problem with DevOps is the reach of their usefulness. If your whole company is built on code, your DevOps team will always be overworked and under appreciated.

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

#370

Post by seabrookmx » Thu, May 17, 2018, 5:57 AM UTC

jchw wrote: post #121

gaadd33 wrote: post #58

Earlier quoted context omitted.

Does that Dockerfile build a container that only has that app in and it's required dependencies? Almost all of the ones I've seen given as examples seem to have an entire copy of the OS in.

A container is basically a glorified chroot, so there is a few things not strictly needed, but I typically use Alpine as a base system, which has a shell, some core utils, and musl libc in just ~5 MB. Since it's on its own layer, it gets deduplicated both in build and at runtime with other Alpine containers (and many Dockerhub images have an Alpine option.) That being said, since Go binaries have no inherent dependen…

> I have indeed made Docker images containing exactly one file

To anyone reading this, you need some magic compiler flags in both Rust and GoLang to make sure it's a statically compiled binary (doesn't dynamically link against GNU lib-c).

But yes, this is super neat. I also like how it reads in the docker file:

FROM scratch ...