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

331–340 of 466 posts

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

#331

Post by getsat »

Alupis wrote: post #317
api wrote: 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?

> Is it really the best choice, or has someone done something cleaner in golang or c++11? What does the language have to do with the program? Hadoop is what it is because it's a complex problem with a fittingly complex solution. Simply re-writing it in your pet language won't somehow make it "better".

Go and modern C++ are both quite a bit more terse than Java. They also produce binaries which don't necessarily require a runtime to be available on every server (just ABI compatibility).

(I have no horse in this race, I am just writing what I think the grandparent comment was referring to)

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

#332

Post by stephenr »

squar1sm wrote: post #314
matt_kantor wrote: post #266

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…

I wouldn't consider what you presented as the "normal" or "ok" way of doing things either, especially not on anything resembling a live (i.e. not development/sandbox) environment.

A distro (or official vendor, or possibly a trusted third-party) repo of pre-built, signed packages would always be my first choice.

If one of those isn't available, my next step would be to create a package for the tool in question, part of which is setting up a file for `uscan` to download new source archives, and compare against the signatures.

In this scenario we (as in the organisation) are now responsible for actually building and maintaining the package, but we can still be assured that it's built from the original sources, we can still install it on production (and even dev, staging, whatever) servers with a simple call to apt/aptitude, and dependencies, removal, upgrades, etc are still handled cleanly.

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

#333

Post by ossreality »

chrissnell wrote: post #321
dysinger wrote: post #316

This 1 page poorly titled wrong rant is the #2 story on this site? "Ever tried to security update a container?" lol. you are doing it wrong. "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." nope https://blog.docker.com/2014/10/docker-1-3-signed-images-pro... "»Docker is the new 'curl | sudo bash'«" no i…

I think you're wrong. I think most users are not installing trusted builds from their OS vendors. Piping curl to bash is incredibly common--many popular software packagers are doing it [1]. About a year and a half ago, I was playing around with Docker and made a build of memcached for my local environment and uploaded it to the registry [2] and then forgot all about it. Fast-forward to me writing this post and checki…

Shit, it's going to blow your mind to know that people download EXEs from the internet and run them every fucking day.

this thread is a joke.

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

#334

Post by stephenr »

Anderkent wrote: post #221
stephenr wrote: post #121

Earlier quoted context omitted.

I would argue that anyone who is reasonably comfortable in a command line would resort to `man command`, `command --help` or `command -h` before googling for usage.

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?

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

#335

Post by mjibson »

Alupis wrote: post #317
api wrote: 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?

> Is it really the best choice, or has someone done something cleaner in golang or c++11? What does the language have to do with the program? Hadoop is what it is because it's a complex problem with a fittingly complex solution. Simply re-writing it in your pet language won't somehow make it "better".

I spent an entire day last week attempting to build hadoop with LZO compression support. There are many outdated guides on the internet about how to do this, and I eventually gave up and spent a few hours getting the cloudera packages to install in a Dockerfile so I could reproduce my work later.

Figuring out which software packages I needed, how to modify my environment variables, which compiler to get, and where to put everything in the correct directory was the entire difficulty.

If it were written in Go instead of Java, I could have done `go get apache.org/hadoop` and it would have been done instead of giving up after hours of frustration.

Go has almost no new features that make it an interesting language from a programming language perspective. Go's win is that it makes the actual running of real software in production better. Hadoop's difficult is exactly why InfluxDB exists at all.

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

#336

Post by jblow »

squar1sm wrote: post #314
matt_kantor wrote: post #266

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…

Because now your ability to install your mission-critical software is dependant upon https://whatever.io actually being up. Which it certainly won't be forever.

Or, you know, maybe someone updated the whatever.io installer to make it 'better'. But you are trying to debug some problem and you made one image last month and another one this month and you're pulling your hair out trying to figure out why they are different. Oh, it's because some text changed on some web site somewhere.

You've taken a mandatory step and put it outside your sphere of control.

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

#337

Post by exelius »

KaiserPro wrote: post #294
exelius wrote: post #173

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…

Bad DevOps is bad. But bad DevOps is basically no worse than what people were doing before: you'd just have a bunch of VMs running fedora20 with no way of easily patching all of them at once. Except some of the VMs may be running fedora23 because they were part of an expansion that happened 2 years after the original set and the guy who deployed them couldn't find a fedora20 image. And at least with a container, you can more easily use AWS for spare capacity/redundancy while you migrate servers. DevOps doesn't fix every sysadmin problem, but it gives you a lot more options that can be developed/deployed in a small amount of time.

DevOps is bad when you take your worst developer and say "do sysadmin tasks and still write application code". It works much better when you take an experienced sysadmin and embed them into a dev team. Make them do code reviews on deployment scripts with a developer, assign tasks within sprints, etc. Code reviews aren't because you don't know how to code -- IMO the primary benefit of code reviews is the education of the reviewer. Likewise, the sysadmin's struggles become the developers' struggles, and the developers are more likely to write applications that are easy to support if they have some role in supporting them.

Every company over a certain size has politics. It's unavoidable. Maybe Google doesn't -- I don't know. But not every company can be Google. You can't use technology to overcome process problems, but you can and should use technology as a part of a redesigned, better process. DevOps gives you more options, and has a positive effect on the culture of a development org. It asks them to think of portability and supportability as a concern.

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

#338

Post by reitanqild »

kylegordon wrote: post #325
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…

I posted a slightly provocative tweet about this, and the CEO of NodeSource took exception... sad days. https://twitter.com/kylegordon/status/590860756075294721

He seems to be way nicer and more professional than you..?

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

#339

Post by tracker1 »

odonnellryan wrote: post #320
EC1 wrote: post #312

Earlier quoted context omitted.

Well fuck me. I just spent two weeks fiddling with Vagrant and Docker and finally got everything up and humming only to come into this thread. Going to refrain from slapping the SysAdmin title on myself for now.

Docker is awesome, but you shouldn't be using blind base images. Use Dockerfiles, they're self-documenting.

Unless you build your own base images... odds are you will be using something someone else built. Even the host OS probably wasn't compiled by you.

In general, my base images are often debian:wheezy, ubuntu:trusty or alpine:latest ... From here, a number of times I've tracked down the dockerfiles (usually in github) for a given image... for the most part, if the image is a default image, I've got a fair amount of trust in that (the build system is pretty sane in that regard)... though some bits aren't always as straight forward.

I learned a lot just from reading/tracing through the dockerfiles for iojs and mono ... What is interesting is often the dockerfile simply adds a repository, and installs package X using the base os's package manager. I'm not certain it's nearly as big of a problem as people make it out to be (with exception to hadoop/java projects, which tend to be far more complicated than they should be).

golang's onbuild containers are really interesting. I've also been playing with building in one node container with build tools, then deploying the resulting node_modules + app into another more barebones container base.

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

#340

Post by chousuke »

squar1sm wrote: post #314
matt_kantor wrote: post #266

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…

Outside of a development environment, you'd run that ./configure && make install step on a build slave that creates a nice RPM or Debian package of it for you which you can install without fear that the build scripts install backdoors, download obsolete software or wipe the filesystem.

With a good build system (eg. autotools) writing an RPM spec takes almost no time at all and if you have the proper infrastructure in place for building packages, you can have something workable in a very short time.

Self-packaged RPMs also don't need to be quite as high-quality as ones you might want to include in a distribution, so if it makes sense for your use case, it's perfectly okay have "bloat" (eg. an entire python virtualenv) in your package.

Post reply on HN