Tag Info

There are many tools that can do something like this, including configuration management tools like Chef, Ansible, or Puppet; and KVS tools like Consul and etcd. You could also integrate it as a build step in your CI server, or sidestep the issue using live configuration at runtime against an external configuration store (again, something like Consul or etcd,...

Ansible is one example of a tool that that allows you to define all your configuration as scripts stored in your SCM and can deal with configuration drift. Ansible has modules to work with Windows in multiple ways including DSC through run books. Full information is available at: https://docs.ansible.com/ansible/latest/user_guide/windows.html. For ...

Personally I don't think using CasC itself will have any negative scalability impact. Fundamentally CasC means the actual config files are not hand-maintaned, instead they're auto-generated following version-controlled rules - which can be a lot more reliable. But once the config files are generated - the service using them functions just as it dit with ...

This slide share gives an idea how to handle CasC in Bamboo. The presenter advocates to use yaml, but according to him there are also downsides.

There are tools around the web for saving desktops. Still best solution I found out to be running a set of virtual machines on your computer, having one setup in one vm. That takes some space, but you can save the state of vm upon vm shut down and come back to exactly same state when you come back. Maybe sessions have died but the windows certainly are as ...

Having a CasC setup means that you are in a better position to deal with any scalability issues that should arise later. It should take you a while to max out a nagios box. As long as you haven't starved it of memory or something you should be able to get thousands of nodes on a single nagios box. How many depends on how many checks you're doing and how ...

From my experience in managing a Nagios deployment with version controlled configuration files and CI/CD, it works really well. You can collaborate with other teams more easily since you can grant access to a git repository, and you gain all the benefits of CI/CD e.g. rollback and automatic testing. One thing that may be a bottleneck is how frequently you're ...

Possibly a different repo? One with branches for QA, UAT, Prod (of nor more). A repo that's different to your regular "Code as Code" and "Infrastructure as Code" repos. It is highly nuanced. How much config per env. Is it toggled between releases? Should those toggle states maintain state despite binary deploys. Which of client, customer, guest or user ...