4 ms·

I'm a mechanical/software engineer, but I set up our company's web and continuous integration servers using Ansible. The experience overall was excellent, and e

I'm a mechanical/software engineer, but I set up our company's web and continuous integration servers using Ansible. The experience overall was excellent, and everything worked mostly as advertised. A couple pain points I had were: * If I removed something from the Ansible configuration, it stayed on the server unless I explicitly removed it manually. This created hidden dependencies. I solved this problem by creating a brand new server and running Ansible on it from scratch every so often. I have considered setting up CI for our Ansible configs by using Vagrant to recreate our server architecture, running Ansible on the virtual machines, and ensuring everything works. * Our continuous integration setup requires Ansible to be installed on the CI server, so it can automatically deploy to staging using the same playbook (Ansible configuration) we use for deployment. Our staging server is the same as our CI server, and it was actually a pain to set up deploying locally as root. Also, I feel like allowing the CI software to use root is a security hole. I also spent some time with NixOS a year ago, and I was very impressed with how it manages packages. The first problem I mentioned with Ansible seems like it wouldn't happen with NixOS, since not including a package in an environment means it won't be present. Second, it also seems that you could use Nix's declarative configuration language in restricted environments, which wouldn't necessarily require root, instead of having to install system-wide packages for a particular deployment. I am not sure how easy this is in practice. Currently, I am using Arch Linux, and I installed the nix package manager to play with some more. In the future, we might be provisioning AWS servers in real-time to run simulations given to us by customers (we make simulation software), and in that case I am going to investigate NixOS more.

falcolas 12y ago
Most orchestration tools are stateless from run to run, and as such can't identify if a package has been removed. The solution in my experience is to change the state to absent instead of removing it from the playbook, and then refactor it out at some point in the future.
- mercurial 12y ago
  > Most orchestration tools are stateless from run to run, and as such can't identify if a package has been removed. But NixOS is stateless from update to update as well. The key difference lies in the difference of scope between what is described in a playbook and what is described in a NixOS configuration file.
  - falcolas 12y ago
    I'm not talking about nix here, I'm talking about how to mitigate the problem he encountered using Ansible.
- Ixiaus 12y ago
  Yes, the general rule of thumb is to always place the state argument in commands so you are explicitly defining what the state should be. That's how I remove / add users or packages or configuration files. It also gives you a record of what you had on there before too, which has been nice in some cases.
- mahmoudimus 12y ago
  Yes, like others have said, the general rule of thumb is to ensure state argument is set in the commands. Another thing that is very useful to do is to every 2-months or so, reprovision your systems again (which is something of an architecture refactor).
- mpdehaan2 12y ago
  Yep, this exactly. If you want to make sure something is removed, like from a customer upgrade, leaving it in the configuration for a while is reasonable. Really I wouldn't want untracked resources to be automatically removed - because someone might have had a reason for installing them. Though, yes, the question of removal of cruft does come up. However, if you are doing immutable systems, it's likely you are doing Ansible builds from something like Packer or aminator, and are doing red/green deployments that completely replace the OS. I think immutable systems are likely the future for applications, they just take some extra work to get your brain around them, that may make them be viewed as "not worth it" in some capacities - those dealing with a lot of data, needing to "stay around", legacy applications, etc. However, this is also why Docker is popular - because it's providing people a quicker way to get into the immutable system workflow. People have tried to make a better RPM in the past - I worked at a startup that did this at one point (rPath, now defunct). Though, ultimately, I think people want to work in higher level primatives than package managers, and the use cases involved in migrating a system from version A to version B are often not entirely clearcut. Configuration is also manageable by things like etcd - I think a new package manager is ... I guess conceptually interesting. But it's kind of the last thing I'd want. To control what versions you install, it can often be easier to just maintain good software repos, rather than enforcing it on each individual system. (Think databases). disclaimer: wrote Ansible

falcolas 12y ago

Most orchestration tools are stateless from run to run, and as such can't identify if a package has been removed. The solution in my experience is to change the state to absent instead of removing it from the playbook, and then refactor it out at some point in the future.

mercurial 12y ago
> Most orchestration tools are stateless from run to run, and as such can't identify if a package has been removed. But NixOS is stateless from update to update as well. The key difference lies in the difference of scope between what is described in a playbook and what is described in a NixOS configuration file.
- falcolas 12y ago
  I'm not talking about nix here, I'm talking about how to mitigate the problem he encountered using Ansible.
Ixiaus 12y ago
Yes, the general rule of thumb is to always place the state argument in commands so you are explicitly defining what the state should be. That's how I remove / add users or packages or configuration files. It also gives you a record of what you had on there before too, which has been nice in some cases.
mahmoudimus 12y ago
Yes, like others have said, the general rule of thumb is to ensure state argument is set in the commands. Another thing that is very useful to do is to every 2-months or so, reprovision your systems again (which is something of an architecture refactor).
mpdehaan2 12y ago
Yep, this exactly. If you want to make sure something is removed, like from a customer upgrade, leaving it in the configuration for a while is reasonable. Really I wouldn't want untracked resources to be automatically removed - because someone might have had a reason for installing them. Though, yes, the question of removal of cruft does come up. However, if you are doing immutable systems, it's likely you are doing Ansible builds from something like Packer or aminator, and are doing red/green deployments that completely replace the OS. I think immutable systems are likely the future for applications, they just take some extra work to get your brain around them, that may make them be viewed as "not worth it" in some capacities - those dealing with a lot of data, needing to "stay around", legacy applications, etc. However, this is also why Docker is popular - because it's providing people a quicker way to get into the immutable system workflow. People have tried to make a better RPM in the past - I worked at a startup that did this at one point (rPath, now defunct). Though, ultimately, I think people want to work in higher level primatives than package managers, and the use cases involved in migrating a system from version A to version B are often not entirely clearcut. Configuration is also manageable by things like etcd - I think a new package manager is ... I guess conceptually interesting. But it's kind of the last thing I'd want. To control what versions you install, it can often be easier to just maintain good software repos, rather than enforcing it on each individual system. (Think databases). disclaimer: wrote Ansible