3 ms·

I use same tools (package manager, services, scripts) for about decade. Tried to use Puppet and Ansible, but result is much more complex and it feels like I rei

by lisivka 11y ago

I use same tools (package manager, services, scripts) for about decade. Tried to use Puppet and Ansible, but result is much more complex and it feels like I reinventing the wheel, because I need to implement things which I already have implemented in package manager, like validation, upgrade management, etc. Difference between Ansible and package manager feels like difference between procedural programming and OOP. Difference between Puppet and package manager feels like fight between two competing object oriented models.

aeorgnoieang 11y ago
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.

by lisivka 11y ago

aeorgnoieang 11y ago

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.