I see Ansible as necessary evil. Not requiring server-side installed tools to work is great. But choosing yaml of all things for playbooks is downright vile. So there’s nothing casual about administering that many servers and machines, especially with constant warnings about Python version incompatibility.
If we ever meet an advanced alien society, I really want to see what solutions they came up with for:
Configuration languages
GUI frameworks
Because those two areas seem like there will never be a “perfect” solution.
And to anyone that says “an alien society might be so different that they don’t have those things”, I think if you’ve invented computers then at some point you will want some way to configure them, and some way to interact with programs running on them.
If they navigate programs entirely by sound or some shit, that’d still be interesting to see.
Watch it turn out that most advanced alien societies just use the terminal.
Then it turns out the reason they are exploring the depths of space is to see if any other civilizations have figured out a better way to handle those things because their current solutions work but kinda suck (along with several other problems we can’t yet fathom). And worse, they get excited when you start describing our systems.
“Wait wait wait, please tell me more about this… stack… that allows you to reuse code with different initial values for variables. That sounds revolutionary!”
Excellent observation. I’m honestly surprised there’s no well-known “universal parser” for common languages that can handle JSON, YAML, TOML, maybe even some form of XML, etc.
I don’t particularly like yaml as a data storage language because of its use of significant whitespaces, but for the minimal complexity of my own playbooks, I don’t mind it.
What would you consider to be an ideal language for playbooks?
Am not sure to be honest. I always liked JSON even though it’s very rigid. Even so, most of software I write stores config in JSON simply because it’s easy to parse and it’s supported by literally everything. It’s also pretty minimalist.
Perhaps something more strict and defined would be better. I think I’d even prefer XML to YAML.
yq can take either JSON or Yaml (or maybe others, I haven’t checked) as input, then it converts it to JSON before passing it to jq. yq outputs JSON by default, or Yaml if you pass it the --yaml-output option.
Its syntax is plenty when it comes to “wrong”. I’ve been using it for a while now and I still run into some issue with its formatting, but that of course can only be discovered when you run deployment or provisioning scripts, giving it high chance of pissing me off because it will cause something to be half-configured when it shouldn’t be.
For us Ansible works and code that we have is getting dated now, but every now and then it does get a little bit of refresh to give it more life but in general you are right. Its bad sides mainly show up when you try to manage older systems or something more exotic. Then python incompatibilities, directories and server side libraries all start showing their ugly side.
And all of them are universally bad. Especially all the Kubernetes tools, Helm is so bad and at least half of it is due to the combination of YAML and templating.
Isn’t all of these tools dying with k8s? Like the entire concept of installing a playform for your service is moot at this point. Plus there’s like a million other benifits over bare metal configs.
Nope. Far from it, especially if you have to adapt to existing structure, like having sites hosted with Plesk or cPanel on some rented hosting service. I’ve been also using it for easy and fast configuration of embeded devices, like RaspberryPi and similar.
Sure, legacy exists but as a systems principal engineer I would always look to improve the platform. Puppet/chef/ansible all the problems those solved are kind of moot with a kubernetes ecosystem. The only thing they might be useful for would be installing the software to get those nodes added and maybe security updates in you’re running 1k+ of bare metal. And something that could all be solved with something light like dancers shell. At home I’ve even just moved to k3 since the containerize is just so much more consistent. Ansible not maintaining state is also a massive headache.
I see Ansible as necessary evil. Not requiring server-side installed tools to work is great. But choosing yaml of all things for playbooks is downright vile. So there’s nothing casual about administering that many servers and machines, especially with constant warnings about Python version incompatibility.
If we ever meet an advanced alien society, I really want to see what solutions they came up with for:
Because those two areas seem like there will never be a “perfect” solution.
And to anyone that says “an alien society might be so different that they don’t have those things”, I think if you’ve invented computers then at some point you will want some way to configure them, and some way to interact with programs running on them.
If they navigate programs entirely by sound or some shit, that’d still be interesting to see.
Watch it turn out that most advanced alien societies just use the terminal.
Then it turns out the reason they are exploring the depths of space is to see if any other civilizations have figured out a better way to handle those things because their current solutions work but kinda suck (along with several other problems we can’t yet fathom). And worse, they get excited when you start describing our systems.
“Wait wait wait, please tell me more about this… stack… that allows you to reuse code with different initial values for variables. That sounds revolutionary!”
Excellent observation. I’m honestly surprised there’s no well-known “universal parser” for common languages that can handle JSON, YAML, TOML, maybe even some form of XML, etc.
I don’t particularly like yaml as a data storage language because of its use of significant whitespaces, but for the minimal complexity of my own playbooks, I don’t mind it.
What would you consider to be an ideal language for playbooks?
Am not sure to be honest. I always liked JSON even though it’s very rigid. Even so, most of software I write stores config in JSON simply because it’s easy to parse and it’s supported by literally everything. It’s also pretty minimalist.
Perhaps something more strict and defined would be better. I think I’d even prefer XML to YAML.
You can use JSON to write the playbooks, then use a program like
yq(which is a Yaml wrapper forjq) to convert it to Yaml. Something likeI did not know that. That’s a useful one. Does it work the other way around?
Yes, both
yqandjqare fantastic programs.yqcan take either JSON or Yaml (or maybe others, I haven’t checked) as input, then it converts it to JSON before passing it tojq.yqoutputs JSON by default, or Yaml if you pass it the--yaml-outputoption.besides the annoying syntax, whats so wrong with yaml?
its a standard tool used across many different things, id expect it to be adopted.
Its syntax is plenty when it comes to “wrong”. I’ve been using it for a while now and I still run into some issue with its formatting, but that of course can only be discovered when you run deployment or provisioning scripts, giving it high chance of pissing me off because it will cause something to be half-configured when it shouldn’t be.
Removed by mod
For us Ansible works and code that we have is getting dated now, but every now and then it does get a little bit of refresh to give it more life but in general you are right. Its bad sides mainly show up when you try to manage older systems or something more exotic. Then python incompatibilities, directories and server side libraries all start showing their ugly side.
YAML is used across a lot of modern technologies. I would imagine using YAML makes it easier to learn for a lot of DevOps type people.
And all of them are universally bad. Especially all the Kubernetes tools, Helm is so bad and at least half of it is due to the combination of YAML and templating.
I love yaml so maybe its just a matter of personal choice.
you might like salt-ssh
Thanks, I’ll take a look.
Isn’t all of these tools dying with k8s? Like the entire concept of installing a playform for your service is moot at this point. Plus there’s like a million other benifits over bare metal configs.
Nope. Far from it, especially if you have to adapt to existing structure, like having sites hosted with Plesk or cPanel on some rented hosting service. I’ve been also using it for easy and fast configuration of embeded devices, like RaspberryPi and similar.
Sure, legacy exists but as a systems principal engineer I would always look to improve the platform. Puppet/chef/ansible all the problems those solved are kind of moot with a kubernetes ecosystem. The only thing they might be useful for would be installing the software to get those nodes added and maybe security updates in you’re running 1k+ of bare metal. And something that could all be solved with something light like dancers shell. At home I’ve even just moved to k3 since the containerize is just so much more consistent. Ansible not maintaining state is also a massive headache.