Earlier quoted context omitted.
> I have indeed made Docker images containing exactly one file To anyone reading this, you need some magic compiler flags in both Rust and GoLang to make sure it's a statically compiled binary (doesn't dynamically link against GNU lib-c). But yes, this is super neat. I also like how it reads in the docker file: FROM scratch ...
Ah yeah, without CGO_ENABLED=0, you'll get a very cryptic error when the ELF binfmt can't find the linker binary... Never tried it with Rust, but I look to using Rust in the future, so I guess I better find out what the flags are for Rust. Sidenote: It's often useful to have ca certs and timezone info. At that point it's probably not a bad idea to just use Alpine and apk add those things.
The sad state of sysadmin in the age of containers (2015)
411–420 of 435 posts
Re: The sad state of sysadmin in the age of containers (2015)
#412Earlier quoted context omitted.
Moreover, who is going to write the next protocols we need? This isn't a field that is done inventing. Not even remotely close.
OP was talking about a future where developers become obsolete because machines take over the development sector. Do you think writing protocols will be something humans will do better than machines?
Re: The sad state of sysadmin in the age of containers (2015)
#413Earlier quoted context omitted.
Well, you're right, I'm not a sysadmin. I pervasively automate, which often sidelines sysadmins, when it doesn't make them redundant. I write code and I don't touch production machines except in extremity, neither of which apply to most (though by no means all) of the people I know who want to call themselves a sysadmin. Anyway, the core mission of anybody touching the stack is to enable the business to achieve its g…
It's not that sysadmins cannot do the work you are rightfully proud of. If there are two basic things that differentiates your statements from those of a traditional sysadmin it is these. 1. Design. 2. Discipline. Where these two values are dispensable long term devops and the new world shine through. I've worked in both worlds and the only mistake is assuming one size fits all.
There were guys like this that were there before and helped everyone along: https://www.computerhope.com/people/don_libes.htm
Re: The sad state of sysadmin in the age of containers (2015)
#414I do often think about how, by using large JS packages, it's very feasible that in the daisy chain of NPM dependencies, somebody's managed to slip in malware. I'm not sure what to do about it other than just not using NPM at all!
Re: The sad state of sysadmin in the age of containers (2015)
#415Earlier quoted context omitted.
> Well, teach your sysadmin to use the system configuration tester when they edit a system configuration file. Wrong. Teach your sysadmin not to overload a single service with different functions (debugging channel, user-facing shell service, running remote commands, file upload, and config distribution channel), especially not the one that should not be used in batch mode, without human supervision. When you write a…
Are you advocating running multiple sshd instances in this case?
For serving as a debugging channel and user-facing shell access, SSH is fine (though I've never seen it managed properly in the presence of nodes being installed and reinstalled all the time). But for everything else (unattended):
* you don't want commands execution, port forwarding, or VPN in your file server
* you don't want remote shell in your daemon that runs parametrized procedures -- but you do want it not to break on quoting the arguments and call results (try passing shell wildcards through SSH)
* you don't want port forwarding and remote shell in config distribution channel; in fact, you want config distribution channel itself to be reconfigured as little as possible, so it should be a totally separate thing that has no other purpose whatsoever
* you don't want to maintain a human-user-like account ($HOME, shell, etc.) for any of the above, since they likely will never see a proper account on the server side; you want each of the services to have a dedicated UID in /etc/passwd, own configuration in /etc/$service, own data directory, and that's it
Each of the tasks above has a daemon that is much better at them than SSH. The only redeeming quality of SSH is that it's there already, but it becomes irrelevant when the server's expected life time gets longer than a few days.
Re: The sad state of sysadmin in the age of containers (2015)
#416Earlier quoted context omitted.
> it's based on a kind of maths called "promise theory" Promise theory is not math, despite its name. It doesn't predict anything, it doesn't explain any phenomena. It's an architectural approach. Brilliant, led to a really great software (CFEngine), but it's not "maths".
Basic concepts of promise theory (10 minute video by Mark Burgess who came up with it): https://www.youtube.com/watch?v=2TPsB5WuZgk 2014 introductory article: https://www.linuxjournal.com/content/promise-theory—what-it Basic book on the subject: https://www.amazon.com/Thinking-Promises-Designing-Systems-C... It's not "maths" like arithmentic but it's "maths" like graph theory: Promise Theory, in the context of inform…
It's less like graph theory and more like inversion of control: an architecture, not a set of theorems and their proofs. Even Burgess' own book you mentioned is nothing like a mathematical handbook.
I'm a great fan of Mark Burgess and his promise theory, but calling it a mathematical theory or a mathematical domain is simply incorrect.
Re: The sad state of sysadmin in the age of containers (2015)
#417Earlier quoted context omitted.
Yes. The host will run 100% CPU to handle the hundreds of SSH connections. I've been re configuring 300 to 800 hosts many times a day, never had a problem. I think it would take a few thousands hosts for the performance to be noticeably slow and I am really not sure that other tools or systems could take it much better.
I know our SREs once screwed the config for sshd, and considered themselves very lucky that they had puppet on the machines and could push a fixed configuration (if they had used exclusively ansible, that'd be the end of it - no way to connect or to deploy new configuration) [edit] To clarify - ansible is great, and we use it. Just saying that, as everything, it still has (sometimes subtle) downsides in various scena…
But "have two ways in" is a basic principle of sys admin (typically via traditional network and some out of band console access).
Re: The sad state of sysadmin in the age of containers (2015)
#418I think the entire statosphere of DevOps is just about dead on the whole in 2018 .. in retro, after working with things like Docker .. and more specific industry variations beyond the Amazon tech, it makes no sense to dwell on the security / control of a dedicated systems admin professional since the tools are all outside the local domain anyway. The rest from VoIP to IoT to container services are managed whole-sale…
I'm not convinced there was ever a need for sysadmins, especially from the point of view of programmers. Programmers have always been able to do that work themselves. It's just that they don't want to. They think it's boring, or perhaps even beneath them. It's a bit like tax preparation. I don't think that's really changed all that much, even today, even if it's now programming against the AWS API, judging by the num…
> It's just that they don't want to. They think it's boring, or perhaps even beneath them. It's a bit like tax preparation.
I'll half agree here, and half not. I'm coming at this as a programmer who has historically done ops as well, currently doing more ops than dev.
There's parts of it that programmers don't want to manage, like Apache configuration, provisioning and sizing VMs appropriately, etc. That's the boring stuff, and I totally get it. I don't like managing most of that stuff either, and have got everything set up with service discovery to handle a good chunk of the configuration, and Terraform for managing resources instead of having to click through the Azure Portal, and Nomad for scheduling tasks in the clusters. Groovy.
There's also the parts that the developers seem to have no clue about. They're very happy with all of these abstractions, but there's a lot of layers underneath. They think in terms of making HTTP requests; when those don't work, it's up to me to figure out that their library is keeping a pool of HTTP connections open, and the Azure load balancer silently drops those connections out of the NAT table after 4 minutes of idle time (without sending FIN or RST packets to either side, natch). When the app gets terminated because it's exceeded its cgroup memory limit, I'm the one helping them adjust their JVM heap size. And when their requests take too long, I'm there helping them look through their query logs to figure out what's happening.
All of these cases have happened in recent memory, and it's never been a matter of "this is boring and/or beneath me", it's been a matter of "HALP! I HAVE NO IDEA WTF IS HAPPENING"
Edit: so yes, I agree with you in the sense that I'm a developer who generally speaking doesn't need a sysadmin. I installed Linux for the first time when I was 12 years old, 22 years ago :), and I didn't have a sysadmin then. In those 22 years, I've seen a lot of weird shit happen, and most of the people I've worked with don't seem to be well equipped to dive 3 abstraction layers deeper than they're used to to figure out what's wrong.
Re: The sad state of sysadmin in the age of containers (2015)
#419Earlier quoted context omitted.
It's not that sysadmins cannot do the work you are rightfully proud of. If there are two basic things that differentiates your statements from those of a traditional sysadmin it is these. 1. Design. 2. Discipline. Where these two values are dispensable long term devops and the new world shine through. I've worked in both worlds and the only mistake is assuming one size fits all.
In general you seem like an absurd sort of creature. Neither here nor there. Bragging about your facility and business velocity. Everything you claim to do sysadmins were doing in 98 and with equal velocity and adequate coverage. There were guys like this that were there before and helped everyone along: https://www.computerhope.com/people/don_libes.htm
I'm still not certain what point you were trying to make with "neithere here nor there", however.
Re: The sad state of sysadmin in the age of containers (2015)
#420Earlier quoted context omitted.
We have 47 half-built over-complicated build systems, because writing build systems is hard. Writing correct Makefiles is also really hard, and good luck debugging them. Make is simple and beautiful for small, self-contained projects without many dependencies, but it does not scale well (and even then it's tricky, see [0][1]). Having 47 different build tools with their own flaws is certainly bad, but they exist becau…
See these discussions, too: * https://news.ycombinator.com/item?id=15060146 * https://news.ycombinator.com/item?id=15060146