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

vitavonni.de

Post reply on HN
Print view View original

191–200 of 466 posts

Re: The sad state of sysadmin in the age of containers

#191

Post by shanemhansen »

Khaine wrote: post #174
blfr wrote: post #4

This bothers me as well. Even tasks as simple as adding a repository are now being "improved" with a curl | sudo bash style setup[1]. However, installing from source with make was (and remains) a mess. It may work if you're dedicated to maintaining one application and (part of) its stack. But even then it usually leads to out of date software and tracking versions by hand. Many people have this weird aversion to doin…

Some of this is self inflected. Go look up how you install snort or bro on centos. You have to either install from source, or install from a rpm from there website which may or may not have issues. This means you lose dependency management, and update management. Pure madness

I've decided that unless you're ok with running a very restricted set of ancient applications, don't even try to use CentOS. I've seen multiple billion dollar companies who can't seen to avoid f'ing up the yum repos on CentOS.

I'm not able to go full docker on my machines @work, but I do have some statically linked tarballs. There is a reason apps that deploy in hostile environments (skype, chrome, firefox) bundle most of their dependencies.

Re: The sad state of sysadmin in the age of containers

#192

Post by vacri »

eropple wrote: post #170
vacri wrote: post #86

Earlier quoted context omitted.

then you are doing containers wrong... The old-school sysadmins I know scoff at Docker's idea of 'containers'. Linux containers were already a thing, and don't need an entire copy of an OS ported around with them. To them, containers are a way of enveloping a process to limit it, not a way of distributing packaged software. They may or may not be doing 'docker' right, but they certainly know what 'linux containers' a…

> Linux containers were already a thing, and don't need an entire copy of an OS ported around with them. Neither do Docker containers. You can build off scratch and put the literal bare minimum you need in it. I've done it a few different times. It's rarely done because the time and effort almost never makes up for the complexity and cost, but if your old-school sysadmins are scoffing it's on them.

Response to exactly that idea from one of these guys: "Why do you need docker to just build an executable?"

Re: The sad state of sysadmin in the age of containers

#193

Post by corobo »

microtonal wrote: post #122
tormeh wrote: post #92

Earlier quoted context omitted.

It's just automated copy-pasting of commands you don't understand from the internet, which is something everyone who runs Linux (and is not a wizard) does all the time. It's really really bad, but people will continue doing it until commands/things become so easy we can actually understand what we're doing. Unfortunately, this has never been a priority in Unix-land as far as I've gathered.

It's really really bad, but people will continue doing it until commands/things become so easy we can actually understand what we're doing. But it isn't all that hard to understand a clean Unix. I have never copied or typed a command that I don't understand. One problem may be that most Unices these days is not as clean anymore as, say OpenBSD or NetBSD. E.g. the recent X stack, with D-BUS, various *Kits, etc. is qui…

> I have never copied or typed a command that I don't understand.

To note that it's trivial to change what goes into the clipboard too. Copying and pasting commands from potentially untrustworthy sites should be ruled out too, even if understood

Re: The sad state of sysadmin in the age of containers

#194

Post by NathanKP »

ploxiln wrote: post #150
oskarth wrote: post #112

At my last job we used a micro-service architecture on AWS (EC2 and RDS). Using Ansible playbooks for various types of servers and roles for each service, we created a new server instance every deploy. All servers were running FreeBSD and using daemontools to control services. For testing, hotfixes, and manual checking of logs, it was easy to complement with manual ssh. Save old and new instance in case something goe…

I also learned from a place with good practices, which used daemontools to run services and a custom deploy system in bash and python which actually did the right kinds of things. (and I was fully-manually admin-ing my own linux systems for years before that) As an early employee at a new place, I'm now using ansible and docker because nowadays people want to use that stuff, and it is a lot faster to get started with…

This is the key. The OP's major complaint is with prebuilt containers from potentially untrustworthy sources, but he passes this off as a fundamental problem with containers themselves.

The reality is that you can (and probably should) build your own container rather than using a public one from docker hub. You know exactly what is in it, and can trust it completely.

Re: The sad state of sysadmin in the age of containers

#195

Post by andrewvc »

tobz wrote: post #188

An interesting point that I didn't see the author bring up is the concept of how Docker images can be built in a layered fashion, and the potential for a false sense of security. For example, you start with some sort of base image -- say phusion/baseimage-docker[1] -- and proceed to layer your application on top of it. You "trust" Phusion. They do Phusion Passenger, it's a real piece of software you heard of, and it'…

FWIW you can easily recreate a base image by just copy/pasting the Dockerfile for that image at the top of your own.

I did this for the Jruby images we base our stack on.

I've been doing both dev and ops work for nearly a decade. I feel for what the guy is saying, but these aren't tech problems, they're process problems.

Relying on apt packages for everything makes using more recent features ridiculously hard and slows up the works in pushing features out. I'll trade a little security to be more nimble. I say that because as someone who's worn the hats of operations, development, and co-founder, I realize that you can't have it all. There simply isn't enough time and bandwidth in most companies.

Re: The sad state of sysadmin in the age of containers

#196

Post by TeMPOraL »

dschiptsov wrote: post #184
TeMPOraL wrote: post #111

Earlier quoted context omitted.

> Programmer must be aware of which version of what API implemented with what version of package or library he using and explicitly assert and maintain these requirements, like all the very few sane software projects (git, nginx, redis, postgress) do. Except that when you're doing anything that looks like an actual end-user application (as opposed to infrastructure), you end up using dozens of libraries which themsel…

> as the only reasonable way for giving a service application to people to deploy on their machines Take a look how git or nginx compiles from the source on any machine imaginable. There is absolutely no fundamental problem with ./configure; make; make install .

Does it work well when you have third-party dependencies?

Re: The sad state of sysadmin in the age of containers

#197

Post by cgb_ »

peterwwillis wrote: post #163
cgb_ wrote: post #80

This rant is about containers, prebuilt VMs, and the incredible mess they cause because their concept lacks notions of "trust" and "upgrades". Prebuild VMs? Sure, I wouldn't touch them except for evaluating a project, and for commercial software you may not have a choice. But docker containers at least usually provide a dockerfile that describes exactly how a binary image is built. You just clone the source repo, aud…

> If you are trying to be an old-school sysadmin that expects to console or SSH in and run 'yum upgrade' or 'apt-get upgrade' your containers then you are doing containers wrong... A container is a chroot environment for running a service. Basically. It's perfectly possible to 'yum upgrade' or 'apt-get upgrade' them. I think what you're trying to say is this is a bad idea because containers are not supposed to be man…

I corrected myself for the other person to mean '[..] upgrade your docker containers'. I heavily use LXC containers (and had used openvz and vserver before that) and treat them as individual servers.

All your points about bad sysadmin practices are OS & container agnostic - they can happen on any platform, don't drag Docker into it. Sure there is a culture of 'docker run somebinaryimage [..]' but those people are the ones that do "curl | sudo bash" as well.

Your claim about non-reproducibility of Dockerfiles is bogus. The result of a Dockerfile build gives you precisely the reproducibility you desire. Every time you run a container from that image built from a Dockerfile, you'll get the same filesystem & environment.

Docker 1.6's "Content Addressable Image Identifiers" addresses your build in a year concern by allowing dockerfiles to refer to a digest to ensure you are building against exactly the image you expect (rather than the result of some build process that yum -y upgrades etc, which I think is what you were getting at).

Re: The sad state of sysadmin in the age of containers

#198

Post by TeMPOraL »

shanemhansen wrote: post #183
TeMPOraL wrote: post #95

Earlier quoted context omitted.

https://xkcd.com/1168/ comes to mind. And yes, I Google half of the command invocations too (but usually type them in by hand so that I can remember them faster instead of copy-pasting).

I usually get tar right on the first try. I only have to remember 2 variants (extract file and create file): tar xf ./foo #automagically works with bz2 and gz files tar cf /tmp/out.tar . #add z for compression

Oh cool. So that works? I've already memorized:

    tar -xvvzf foo.tar.gz
    tar -xvvjf bar.tar.bz2
    tar -xvvf  baz.tar
Thanks!

Re: The sad state of sysadmin in the age of containers

#199

Post by TallGuyShort »

highmastdon wrote: post #53
skratlo wrote: post #37

Earlier quoted context omitted.

Same for "framework" which is: I have no idea what I'm doing

Same goes for 'abstraction', it hides the essence of what is happening. Therefore every abstraction is evil.

I think you should strive to understand what is happening under the abstraction, but abstraction is a useful tool. It's a bit like calling something a "crutch". Sounds bad, but what if you have a broken leg? Crutches allow you to get over the problem and make progress. I have to write software that runs on any hardware from any number of vendors and multiple operating systems. Not using abstractions would destroy my effectiveness.
Post reply on HN