3 ms·

Far be it from me to tell you where or how something should be implemented. If you're happy using packages then that's great! But the other two tools you mentio

Far be it from me to tell you where or how something should be implemented. If you're happy using packages then that's great! But the other two tools you mentioned using – "services, scripts" – are exactly what a lot of people find to be harder to manage than a configuration management tool. Maybe your "services" and "scripts" are really sophisticated. If true, then perhaps you've implemented your own configuration management tool. If so, maybe you could share it and other people would find it useful too.

lisivka 11y ago
You are asking wrong questions. The reason, why I don't use configuration tools is because I do no configuration in production. One of main rules for me is to perform all installation and configuration steps in controlled development environment, then test them in staging and only then deploy verified result to production. Imagine that you are fully installed and configured everything at your new production host but in your development environment, then it powered off, deployed to production environment and powered on again and it works. It is result I want to achieve: deploy only ready to use software to production, in sealed form, so no installation, no tweaking, no anything. Like smartphone on contract. It can be achieved with docker, but docker is relatively new invention and my solution plays well with docker too. So, no, my scripts and services are not a configuration management tool.