Live data from Hacker News

The sad state of sysadmin in the age of containers

vitavonni.de

401–410 of 466 posts

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

#401
Incidentally I feel like my admin "skills" have never improved faster than since I started working with docker.

Docker lets me iterate on system configuration faster than ever, and that means learning the details and quirks of certain software faster. Then again, I usually don't use prebuilt VMs and containers, but have to prepare them for people who don't want to pay for good sysadmins..

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

#402
post #300

Earlier quoted context omitted.

Hadoop is insane. The elephant is fitting. Is it really the best choice, or has someone done something cleaner in golang or c++11?

Apache Spark is a good replacement for Hadoop now. It's written in Scala.

Spark is a good replacement for MapReduce. MapReduce != Hadoop.

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

#403

Earlier quoted context omitted.

There are many more depressing examples of this at http://curlpipesh.tumblr.com

Funny tumblr but makes me care-confused. I understand that curl pipe sh could have security problems but I also don't see it as that much different than the "normal" and "ok" way of doing things. I would consider something like the below pretty normal. wget https://whatever.io/latest.tgz tar xzf latest.tgz cd whatever-stable ./configure && make sudo make install Because of familiarity, we aren't going to be too worri…

You're first example allows for:

* Using checkinstall to create a local deb/rpm which can be easily installed/removed later instead of "make install". * What if installer.sh says "rm -rf /tmp/PACKAGE-build" and the connection is interrupted just after the first "/", you now have "rm -rf /". Oops. * configure will tell you what files it needs, and apt-file will tell you want dependencies to install. * I know what make install does. I know make. Who wrote installer.sh? Do they know anything about writing good software? Steam wiped out home directories, who knows what these people do

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

#404
post #269

Earlier quoted context omitted.

>> No one can tell you how to build hadoop? Well, figure it out. I get the impression that several people working on debian couldn't work this one out!

I think most people who use debian would tend to install things using debian packages, which in this case usually means adding cloudera to your apt sources list and using apt-get. It is a pretty straightforward process: http://www.cloudera.com/content/cloudera/en/documentation/cd...

I think the complaint was that it's difficult figuring out how to build Hadoop from source. That page you linked is how to install pre-built binaries, which you rightly point out is fairly trivial.

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

#405

Earlier quoted context omitted.

Nah, man pages are usually completely useless. I use man when I remember exactly what I want to do and just aren't sure if the flag was -f or -F. For everything else there's google.

Can you give an example of what you might turn to google for (and what you'd search for) that is more productive than checking a manpage/help output?

OK, recent simple example:

Google query: git display file at revision. Immediate answer (without even having to click any links, it's in the result description): `git show revision:file`

Total time: 5 seconds

Trying to reproduce with man and help:

  man git
search for display, finds nothing

start scrolling down

notice git-show (show various types of objects); sounds like a likely candidate

  git show  
..no output

  git show -h

  usage: git log [] [..] [[--] ...]
     or: git show [options] ...
.. useful

  man git show
  man git-show
OPTIONS ... The names of objects to show. For a more complete list of ways to spell object names, see "SPECIFYING REVISIONS" section in git-rev-parse(1).

  man git-rev-parse
a lot about specifying revisions, nothing about how actually specify a file

Give up. Google it.

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

#406
post #402

Earlier quoted context omitted.

Apache Spark is a good replacement for Hadoop now. It's written in Scala.

Spark is a good replacement for MapReduce. MapReduce != Hadoop.

Fair enough, but the original article was about Hadoop MapReduce wasn't it? It specifically says:

"without even using any of the HBaseGiraphFlumeCrunchPigHiveMahoutSolrSparkElasticsearch (or any other of the Apache chaos) mess yet."

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

#407
post #324

I agree that many of these convenient setups are embarrassingly sloppy, but it's the sysadmin's responsibility to insist on production deployments being far more rigorous. No one can tell you how to build hadoop? Well, figure it out. Random Docker containers being downloaded? Use a local Docker repo with vetted containers and Dockerfiles only. I don't even allow vendor installers to run on my production systems. My e…

> it's the sysadmin's responsibility to insist on production deployments What decade are you from? No startups are hiring sysadmins to do any kind of work anymore. They're hiring "dev-ops" people, which seems to mean "Amateur $popularLanguage developer that deployed on AWS this one time." That's the whole problem with the dev-ops ecosystem. None of these dev-ops people seem to have any ops experience.

> That's the whole problem with the dev-ops ecosystem. None of these dev-ops people seem to have any ops experience.

Thanks for painting all of us that do "devops" with a wide brush. If you're a dev shall we enumerate all of the XSS and SQL injection holes you've added to products over your career?

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

#408
post #197

Earlier quoted context omitted.

> 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…

> Every time you run a container from that image built from a Dockerfile, you'll get the same filesystem & environment

The image (and thus container) are the same. Trying to rebuild it from scratch leaves it not the same, typically because the way people put together Dockerfiles and build images does not follow a standard. And it has to do with the container culture.

Let's take a Dockerfile for the CentOS 7 version of nginx (https://github.com/CentOS/CentOS-Dockerfiles/blob/master/ngi...)

  FROM centos:centos7
  MAINTAINER The CentOS Project 
  
  RUN yum -y update; yum clean all
Right off the bat I think: what the hell? Why are they doing a yum update? A yum update today may very well leave the system in a completely different state than a year ago. There's likely been some package updated in that time, which changes the state of the system. Right off the bat we're screwed.

  RUN yum -y install epel-release tar ; yum clean all
  RUN yum -y install nginx ; yum clean all
And what the hell is this?! There's no version, no build, no checksum. What the hell did we just install? If those packages change in a year, we're screwed. Not to mention 'epel-release' and 'tar' should be set as dependencies somewhere, and the type of dependencies too.

  ADD nginx.conf /etc/nginx/nginx.conf
  RUN echo "daemon off;" >> /etc/nginx/nginx.conf
Oh, cool, just use whatever the hell this config is which may or may not be different from the one that shipped with the original package. And let's just modify it for no apparent reason, too. And definitely make sure we have no way to know what version of that file we're using for this image. Lovely.

  RUN curl https://git.centos.org/sources/httpd/c7/acf5cccf4afaecf3afeb18c50ae59fd5c6504910 \
      | tar -xz -C /usr/share/nginx/html \
      --strip-components=1
The hell? We're pulling some random git sources from a git server which i'm willing to bet has no standard mirrors? On closer inspection it doesn't really look like a git server, but a host named git which hosts files whose names are a checksum, though we don't know where this is from or what exactly it refers to. If this server or file disappears, good luck knowing what in hell was being downloaded here.

  RUN sed -i -e 's/Apache/nginx/g' -e '/apache_pb.gif/d' \ 
      /usr/share/nginx/html/index.html
  
  EXPOSE 80
  
  CMD [ "/usr/sbin/nginx" ]

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

#409
This "working out of the box" phylosophy is the direct result of devs using Windows and OSX platforms for creating those programs. They now think "Linux and *BSD should be as easy to use as Mac.". Indeed, the majority of devs is mediocre amateur sysadmins. They know next to nothing beyond their preffered language.

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

#410

System administration is as important as ever. Docker and other containers just simplify system administration across many different machines. The standard Unix user land tools are excellent and very flexible, but they are fucking god awful at configuration management. Docker solves the problem of "how do I make sure I have the same versions and configurations of everything on all 500 of my compute nodes without havi…

Many places are rolling this type of sysadmin work up into DevOps. This scares graybeard sysadmins, because they see DevOps automating them out of a job. Nope, not really. just wait till you move to a new job, and you inherit a docker/rockit/etc system. You need to patch openssl/glibc/etc however, half the containers are built with an old build system that's been replaced. You've got 15 containers based on fedora20 w…

Sounds like someone who knows their tools and doesn't know the state of the art.

>An example, Say you want 10 VMs of x size. If you have a coheesive system, you could email/phone/talk to a guy and you'll have some machines. If your provisioning team had thought ahead they'll have made an API that spins up machines, ties them to your accounting code, and configured them to your environment. That's not technology, that just good practice.

Or you know, I have a fleet of ten thousand machines that I can schedule whatever docker containers I want into.

Your nonsense about software being out of date and EOL is absolutely no different than a scenario without docker. At least docker gives you the change to have a declarative way of reconstructing the image.

I can't honestly believe that was what you went with to try to make containers look bad. You're just showing your age is all.

Post reply on HN