Live data from Hacker News

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

vitavonni.de

21–30 of 324 posts

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

#21
post #6

Terrible article IMO. Hadoop is an awful mess, but it has nothing to do with Docker, which is simplistic in comparison. "Ever tried to security update a container?" Yes, I have! In fact you can maintain patch compliance in a container pretty much the same way you'd maintain a VM or bare metal Linux installation!

> Hadoop is an awful mess, but it has nothing to do with Docker, which is simplistic in comparison. The fact that they can get away with a build system like this is very much due to docker (and curl | sudo bash) allow people to not feel the pain this mess causes, at least not right away. > Yes, I have! In fact you can maintain patch compliance in a container pretty much the same way you'd maintain a VM or bare metal…

It's pretty hard to do truly declarative/immutable things with docker because the typical dockerfile starts with "apt-get update && apt-get install ...". For that use case I think nix is much better.

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

#22
The holy grail of sysadmin has always been deployment of immutable images, instead of host system pollution, source code mutation during deployment ...

It was doable with things like Packer, KVM or OpenStack, now it's become easier with containers. You can still orchestrate your stuff with ansible or bash scripts.

I most certainly remember how I was doing isolated deployments 10 years ago: https://github.com/jpic/bashworks/tree/master/vps HINT: it's much cleaner and much more automated with containers: with GitLab-CI it's trivial to host a private container bulding infrastructure with a registry and other automation ...

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

#23
post #19

I recently had a similar discussion with people using npm for building a CSS framework library. I tried to explain the concept of getting a pre-downloaded tarball and using "make" (or similar) to produce target artifacts from source files in a deterministic, repeatable and reliable manner, without relying on any third-party servers being available and without pulling in dependencies that might have changed. It seems…

It can be done using package managers too, for example using Nix. The problem here is not related to distribution method but rather dependency hell in javascriptland.

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

#24
We providing A Feature-Rich Enterprise Video Platform That's Also Affordable and Easy-to-Use services like

1] Enterprise Video Platform 2] Video Management Platform,

MEDIASHAREiQ E-mail : ems.marketing19@gmail.com Website : https://www.mediashareiq.com/ Mobile : +1-877-367-5050(USA)

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

#25
Looked at the Debian wiki the OP linked to:

>Debian currently does not include Hadoop packages. There are a number of reasons for this; in particular the Hadoop build process will load various dependencies via Maven instead of using distribution-supplied packages. Java projects like this are unfortunately not easy to package because of interdependencies; and unfortunately the Hadoop stack is full of odd dependencies (including Apache Forrest, which for a long time only worked with Java = 1.5).

>If you want to build Debian packages, the most complete efforts can be found at the Apache Bigtop project http://bigtop.apache.org/ . Unfortunately, the build process for these packages is currently of a disastrous quality, and should only be attempted within disposable virtual machines, as it requires root permissions and will install non-packaged software.

>These will allow building Hadoop packages on a recent Debian system. However, the resulting packages do not live up to Debian quality standards. In particular, they include copies of .jar files from other packages, and will thus not benefit from security updates done to these packages.

>If you are interested in getting Hadoop packages into Debian,

    Coordinate with the Java packaging team
    Coordinate with upstream Apache Bigtop 
>to avoid duplicate efforts. Thank you.

https://wiki.debian.org/Hadoop

Jesus Christ.

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

#26
post #6

Terrible article IMO. Hadoop is an awful mess, but it has nothing to do with Docker, which is simplistic in comparison. "Ever tried to security update a container?" Yes, I have! In fact you can maintain patch compliance in a container pretty much the same way you'd maintain a VM or bare metal Linux installation!

>Unfortunately, the build process for these packages is currently of a disastrous quality, and should only be attempted within disposable virtual machines, as it requires root permissions and will install non-packaged software.

https://wiki.debian.org/Hadoop

If Debian, a distro on the lower side of dramatic, calls it disastrous, it's pretty bad.

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

#27
post #19

I recently had a similar discussion with people using npm for building a CSS framework library. I tried to explain the concept of getting a pre-downloaded tarball and using "make" (or similar) to produce target artifacts from source files in a deterministic, repeatable and reliable manner, without relying on any third-party servers being available and without pulling in dependencies that might have changed. It seems…

Maybe it wasn’t explained well.

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

#28
post #19

I recently had a similar discussion with people using npm for building a CSS framework library. I tried to explain the concept of getting a pre-downloaded tarball and using "make" (or similar) to produce target artifacts from source files in a deterministic, repeatable and reliable manner, without relying on any third-party servers being available and without pulling in dependencies that might have changed. It seems…

To follow up: I ended up building my own Docker images which contained the build tools (also known as the npm burning dumpster tire fire with extras thrown in), source code and all dependencies. This allows me to get reproducible builds, the modern-day analog of "./configure; make".

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

#29
post #8
post #2

I don't know that much about the state of container systems these days, but to me it seems it's the "comfortable" way in the "security vs comfort" tradeoff. Use where applicable and hope for better days.

But there are some environments where security is (almost) the only relevant factor, e.g. banking IT-infrastructure. I don't want my bank to pull arbitrary images from Dockerhub because that increases their comfort. Conversely, if I were sysadmin at a bank I would most definitely be concerned what was running in my network.

>Conversely, if I were sysadmin at a bank I would most definitely be concerned what was running in my network.

I've worked at a bank. It's a docker file. Running Hadoop. On top of a Linux Container. Running in Rhel 5. On top of a vmware hypervisor.

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

#30
post #21

Earlier quoted context omitted.

> Hadoop is an awful mess, but it has nothing to do with Docker, which is simplistic in comparison. The fact that they can get away with a build system like this is very much due to docker (and curl | sudo bash) allow people to not feel the pain this mess causes, at least not right away. > Yes, I have! In fact you can maintain patch compliance in a container pretty much the same way you'd maintain a VM or bare metal…

It's pretty hard to do truly declarative/immutable things with docker because the typical dockerfile starts with "apt-get update && apt-get install ...". For that use case I think nix is much better.

Linters complain when you don't pin the version, though
Post reply on HN