On the one hand it's nice that developers are using more libraries and writing less from scratch. On the other hand dependencies are out of control. The one thing that really bothers me is code that depends on a particular IDE. That shit drives me up the wall.
The sad state of sysadmin in the age of containers
261–270 of 466 posts
Re: The sad state of sysadmin in the age of containers
#262Earlier quoted context omitted.
It isn't, but so aren't dozens or hundreds of other commands you encounter when working with the command line. I managed to memorize a few invocations of tar (I listed them in another comment) but, for instance, I very rarely create a new archive so I'm never sure what flag I need to use. Part of the problem is that each command line utility has its own flag language, and equivalent functions often have different let…
You don't have to be a sysadmin to be comfortable with command line tools. If you want to fully utilize your *NIX system you have to learn how to use that shit, it really isn't that hard. (I'm a developer.)
I am comfortable with command line tools. I just don't remember every switch and flag I happen to use twice a year, and the fact that command line utilities are totally inconsistent in subtle but significant ways, coupled with the overall unreadability of man pages and lack of examples in them makes this process difficult.
Re: The sad state of sysadmin in the age of containers
#263Earlier quoted context omitted.
> You cannot reasonably expect developers to package and > maintain all their dependencies properly. What? With appropriate tooling, of course you can.
I don't know any tooling that turns (recursively) a Maven pom file into a Debian repository of Debian policy-abiding .debs, which are magically updated when the pom file changes.
If you mean Debian policy-abiding in the sense of "signed by a Debian developer in the Debian WoT" then no, but that's not something you could ever do automatically. But for the rest, I've done all the individual pieces before: it is trivial to generate a .deb from a maven pom and put it in a debian repository, it's trivial to do some operation on all the dependencies of a maven project, and it's trivial to hook something into a maven repository to happen whenever a new artifact is uploaded. You absolutely could do this if you wanted to, and it wouldn't be more than a few days' work.
(Of course it wouldn't provide any value, which is why no-one does it).
Re: The sad state of sysadmin in the age of containers
#264Earlier quoted context omitted.
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.
in reality a dev will pass a prebuilt and non updatable container to the sysadmin tho.
so the op is exactly right! it doesnt matter where its coming from if you cant verify,rebuild or update it.
Re: The sad state of sysadmin in the age of containers
#265This 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…
There's nothing wrong with curl | sudo bash style setups as long as it's over https and the certificate gets checked. The advantages are that it's easy and you can make it work on almost all unix-like systems out there. The only disadvantage is that you have one additional weak point: The server can get contaminated. Before you had to contaminate one of the many developer machines / build machines. The situation hasn…
No, it's just plain bad.
To pick one example why...
Just because it's easy to run doesn't mean it's easy to support or maintain. Chances are `curl | bash` scripts aren't designed for your particular OS, so it's yet another form of software that you have to learn how to update, as opposed to using the OS-level update mechanism, such as yum, apt, or even brew to some extent. Being a good sysadmin doesn't stop at installing the software. Most of the hard (boring) work is in maintaining systems and keeping them updated and secure. Blind install scripts make this job impossible.
There is a very big difference between installing something on your dev machine to just get it started and deploying something into production. `curl | bash` is okay for setting something up on a dev machine where the only one that needs to use it is you. For productions machines, it's completely inappropriate[1].
[1] This is somewhat mitigated by things like Docker, but I'd still argue that you don't want to have an ephemeral installation method for containers either. You should have fixed versions that are installed by either a package manager or at least a Makefile.
Re: The sad state of sysadmin in the age of containers
#266This 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 agree that the "just curl this into bash" instructions are nightmare - on any platform. I think a lot of this is a result of what I like to call the "Kumbaya approach to project/team management": This is where you have a team (either for a single project or a team at a consulting agency, etc) that is effectively all development-focused staff, possibly with some who dabble in Infrastructure/Ops. In this environment,…
There are many more depressing examples of this at http://curlpipesh.tumblr.com
Re: The sad state of sysadmin in the age of containers
#267This 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 agree that the "just curl this into bash" instructions are nightmare - on any platform. I think a lot of this is a result of what I like to call the "Kumbaya approach to project/team management": This is where you have a team (either for a single project or a team at a consulting agency, etc) that is effectively all development-focused staff, possibly with some who dabble in Infrastructure/Ops. In this environment,…
I think part of this is because there aren't any trusted, fully open source, artifact repositories that work with the various package indices out there.
Like, most of the way deployment should work is that you come up with some collection of packages that need to be installed and you iterate through and install them. Bob's your uncle.
Thing is, all the packages you need live out in the wild internet. Ideally, you'd just be able to take a package, vet it, and put it in your local artifact store and then when your production deployment system (using apt or yum or pip or gems or maven or whatever) needs a package, it looks at your local artifact store and grabs it and goes about its business. Never knowing or touching the outside world.
And your developers would all write their apps to deploy through the normal packaging methods that everyone and their mother is already familiar with and they could just put them into the existing package index as well.
But you've gotta lay out pretty serious moola (from when I last looked into available solutions to this) or set up a half dozen different artifact stores if you want to do things that way. And good luck managing your cached and private artifacts if you do. And on top of that developers don't necessarily know how to set up a PyPi or a RPM index or whatever so that the storage is reliable and you've got the right security settings or whatever else. (I know I sure don't and I'm not really interested in reading all of the ones I'd end up needing).
Re: The sad state of sysadmin in the age of containers
#268Earlier 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…
docker can totally be dragged into this. they keep selling the lie and encouraging most terrible practices and design.
talk about self inflicted...
Re: The sad state of sysadmin in the age of containers
#269I 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…
>> 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!
Re: The sad state of sysadmin in the age of containers
#270Earlier quoted context omitted.
Those case differences have meaning, -r is generally not dangerous while -R is; it's capitalized to make you stop and say hmmm, should I do this. All commands have the same flag language, command -options, and are all easily documented by man command; it quite literally couldn't get any simpler and unnecessary to memorize since you can look up any flag on any command with the same man command. Those who find it confu…
> Those case differences have meaning, -r is generally not dangerous while -R is; it's capitalized to make you stop and say hmmm, should I do this. All commands have the same flag language Except with cp , -R is the safe one and -r is the dangerous one. And there are tons of little inconsistencies like this.
As I said, generally. All human languages have inconsistencies, the command line is by far one of the most consistent ones any of us deal with.