undefined | Better HN

0 pointswruza11mo ago0 comments

I see, thanks for the explanation.

Although I think that it sounds so ansible, and that's exactly why I avoid using it. It is a new set of syntax, idioms, restrictions, gotchas, while all I need is a nodejs script that joins initialization template files together, controlled by json server specs. With first class ifs and fors, and without "code in config" nonsense. I mean, I know exactly what was meant to be done manually, I just need N-times parametrized automation, right? Also, my servers are non-homogeneous as well, and I don't think I ever had an issue with that.

0 comments

hnlmorg11mo ago

It’s not just Ansible. I’ve ran into this problem many times using many different configuration systems. Even in the old days of hand-rolling deployment scripts in Bash and Perl.

Managing files instead of one big monolithic config is just easier because there’s less chance of you foobarring something in a moment of absentmindedness.

But as I said, I’m not criticising your approach either. Templating your config is definitely a smart approach to the same problem too.

wruzaOP11mo ago

Not sure if I understand, because my templates are also multi-file and multi-js-module, where needed. It's only the result that is a single root-pasteable script (per server) which generates a single /etc/foo/foo_config file per service. So I think I'm lost again about changes.

You don't want instance-local changes. Do you? Afaiu, these changes are anti-pattern cause they do not persist in case of failure. You want to change the source templates and rebuild-repropagate the results. Having ./foo.d/nn-files is excessive and serves litte purpose in automated mode, unless you're dealing with clunky generators like ansible where you only have bash one-liners.

What am I missing?

hnlmorg11mo ago

You’re not missing anything. A lot of the problem is due to clunky generators.

But then those clunky generators do solve different problems too. Though I’m not going to debate that topic here right now, besides saying no solution is perfect and thus choose a tech stack is always a question of choosing which tradeoffs you want to make.

However on the topic of monolithic config files vs config directories, the latter does provide more options for how to manage your config. So even if you have a perfect system for yourself which lends itself better for monolithic files, that doesn’t mean that config directories don’t make life a lot easier for a considerable number of other systems configurations.

j / k navigate · click thread line to collapse

0 pointswruza11mo ago0 comments

I see, thanks for the explanation.

0 comments

hnlmorg11mo ago

It’s not just Ansible. I’ve ran into this problem many times using many different configuration systems. Even in the old days of hand-rolling deployment scripts in Bash and Perl.

Managing files instead of one big monolithic config is just easier because there’s less chance of you foobarring something in a moment of absentmindedness.

But as I said, I’m not criticising your approach either. Templating your config is definitely a smart approach to the same problem too.

wruzaOP11mo ago

What am I missing?

hnlmorg11mo ago

You’re not missing anything. A lot of the problem is due to clunky generators.

j / k navigate · click thread line to collapse