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

111–120 of 466 posts

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

#111

Post by TeMPOraL »

dschiptsov wrote: post #101

What is really ironic is that none of this "tools" solves any fundamental problem of so-called version hell and none of this containers are fundamentally different from ./configure --prefix=/xxxx && make && make -s install with or without following chroot /yyyy The big "innovation" of having so-called "virtual env" (they call it "reproducible [development] environment) for each "hello world" (a whole python/ruby/java…

> 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 themselves have dependencies, so suddenly you're supposed to "explicitly assert and maintain" hundreds of different library versions, none of which is in any way relevant to the application you're building.

I myself see Docker containers as the only reasonable way for giving a service application to people to deploy on their machines, because even the programming runtime I need is 5 years out of date on Debian/Ubuntu, and installing that stuff manually is a) pain, and b) different on every operating system.

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

#112

Post by oskarth »

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 goes wrong. Ansible is just a thin layer on top of shell scripts, and reasonably straightforward to understand and parameterize. Worked wonderful in most cases (possible exception of build server because of shared libraries and a complex workflow with git pull/trigger, but I don't think that was the fault of the overall architecture).

That said, I agree that sbt is an abomination and doesn't lend itself to a sane and secure workflow, unfortunately.

http://martinfowler.com/bliki/PhoenixServer.html

http://www.ansible.com/

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

#113

Post by Jare »

sltkr wrote: post #87
pjc50 wrote: post #41

Earlier quoted context omitted.

Maintaining autoconf/automake stuff is a pain. Using it is usually as simple as "configure;make;make install". It doesn't do dependency management though, which is an externalised cost. But that's what rpm/deb do. I see the attraction of containers and disk image based management. It's much less time consuming. But it's very much the opposite of ISO9001-style input traceability.

> Using it is usually as simple as "configure;make;make install". "Usually" indeed. Because if it breaks, you do need to know the implementation details to figure out what's wrong.

That's the same for "wget|sh", apt-get, npm or any other system. Now, if the argument is that configure tends to break more often and for more obscure reasons, I can tentatively agree with that.

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

#114

Post by prottmann »

kryptiskt wrote: post #76
prottmann wrote: post #47

Earlier quoted context omitted.

The obvious question is: what's the real problem with that? A container is a container, as long as docker itself has not bug, the container can only harm the containers content. Most problems exists in the custom created software in the container (e.g. web-services with bugs, backdoors, ....), this will be a problem for Docker, VMs, Real-Servers, whatever too. The real problem is the interoperability of different con…

> A container is a container, as long as docker itself has not bug, the container can only harm the containers content. So given that there are no bugs and as long as the Linux kernel is free from local privilege escalation exploits. That seems long odds to trust in.

The same trust i have in a VM or a RM.

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

#115

Post by prottmann »

Nursie wrote: post #56
prottmann wrote: post #47

Earlier quoted context omitted.

The obvious question is: what's the real problem with that? A container is a container, as long as docker itself has not bug, the container can only harm the containers content. Most problems exists in the custom created software in the container (e.g. web-services with bugs, backdoors, ....), this will be a problem for Docker, VMs, Real-Servers, whatever too. The real problem is the interoperability of different con…

>> A container is a container, as long as docker itself has not bug, the container can only harm the containers content. Presumably a container has network access of some sort? Malicious code could start probing and attacking anything exposed that way. >> this will be a problem for Docker, VMs, Real-Servers, whatever too. The implication is that you wouldn't get into this situation with a 'Real-Server' so easily, bec…

But you assume that a container HAS full network access. A firewall must be configured, but a firewall must be configured for a VM too. My point is, that their is not so a huge difference for production systems.

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

#116

Post by VLM »

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…

Many people have enormous amounts of experience with anti-patterns yet very little self reflection to identify them.

This is an obvious example:

http://en.wikipedia.org/wiki/Inner-platform_effect

Obviously a config / deployment system, like any other system, will start small and simple and "save a lot of time" but after an infinity of features are bolted on, it'll be infinitely worse than just using a bash script. Even worse, you probably figure out your deployment by hand on one system using bash, then need to translate what worked on a command line into crypto-wanna-be-bash config system (probably creating numerous bugs in the translation) then using wanna-be-bash to slowly poorly imitate what you'd get if you just used bash directly...

The last straw for me was trying to integrate some freebsd servers and /usr/ports had like six versions of cfengine none of which worked perfectly with the three versions on the legacy linux boxes. Screw all that, instead of translating bash command line operations into psuedo-bash I'll just use bash directly. IT is an eternally rotating wheel and the baroque inner platform deployment framework has had its day... and being an eternally rotating wheel it'll have its day again in a couple years. Just not now.

Not throwing the baby out with the bathwater, a strict directory structure, and modularity and library approach to error handling and reporting and logging which you can steal from the deploy systems is a perfectly good idea.

Unix philosophy of small perfect tools means I'm using git instead of my own versioning/branching system, and using ssh to shove files around rather than implementing and static linking in my own crypto and SSL system.

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

#117

Post by antientropic »

dschiptsov wrote: post #101

What is really ironic is that none of this "tools" solves any fundamental problem of so-called version hell and none of this containers are fundamentally different from ./configure --prefix=/xxxx && make && make -s install with or without following chroot /yyyy The big "innovation" of having so-called "virtual env" (they call it "reproducible [development] environment) for each "hello world" (a whole python/ruby/java…

I would be interested to know why you call purely functional package management "idiotic", given that one of its main goals is to solve the problem of version hell? I.e., to make it easy for a developer to specify that application X should use version V of library Y, without interfering with other applications on your system?

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

#118

Post by VLM »

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.

Its possible to use abstractions that aren't inversions or leaky. Practically no one does a good job of it, so you are correct in practice and experience, although in theory it is possible and sometimes people do pull it off successfully.

http://en.wikipedia.org/wiki/Abstraction_inversion

http://en.wikipedia.org/wiki/Leaky_abstraction

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

#119

Post by hultner »

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've seen people copy pasting stuff along the lines of `wget --no-check-certificate | sudo sh` into their terminals from some random internet source.

I'm pulling my hair saying are you even aware of what you're doing?

Post reply on HN