Answers: <p>This would be a good case for doing a blue-green deployment, it's twice the cost , but half the hassle of having to deploy into production.  Plus you get near instant backups.</p>
  <p>If you can't trust what you deploy in dev, it's usually your only bet.</p>
  <p>You should be able to effectively get blue-green deployments using parameters passed into ansible vault (or a custom inventory playbook).</p>
  <p>For ansible, when you add blue or green environments, you could encrypt the relevant data (ip addresses, passwords, keys) with a <a href="https://docs.ansible.com/ansible/latest/vault_guide/vault_encrypting_content.html" rel="nofollow noreferrer">vault ID</a> of blue or green</p>
  <p><code>ansible-vault encrypt --vault-id blue hostvars/monogo-1.yml</code></p>
  <p><code>ansible-vault encrypt --vault-id green hostvars/monogo-1.yml</code></p>
  <p>and pass that in to do your deployments,</p>
  <p><code>ansible-playbook --vault-id blue playbooks playbooks/monog-deploy.yml</code></p>
  <p>that way, the only thing you need to know is whether blue or green is currently live and deploy the opposite.  Of course, that could get a little messy - there may be a better way do to that than rely on the vault, but it's the simplest way I can think of where all you need to know is blue or green.</p>
  <hr />
  <p>I'm guessing I misinterpreted your question a bit, but testing <em>production</em> seems like a bad idea. Using ansible to test is similarly a bad idea (so saith my company's architects) and I use inspec to test after an ansible deployment.</p>
  <p>IMO, testing your blue-green deployment is still better than testing the production deployed environment.  Generally speaking though, I trust that ansible did what it said it was doing and I keep the templates generic enough to know that whatever it lacked, wasn't there to begin with.</p>
  
Answers: CC BY-SA 4.0
Answers: 2023-11-06T05:06:58.450Z
Answers: 2023-11-06T05:06:58.450Z
Answers: Peter Turner
Body: <p>We use ansible for our day to day operation and so far so good. We have been looking for a way to run local test etc just like chef guys and found molecule that we use with testinfra/vagrant. While I personally found it great for developing roles, I am looking for a way to actually test the playbook(which uses multiple roles , some with pre and post tasks) itself in <strong>PRODUCTION</strong> after it runs.</p>
  
  <p><strong>EDITS</strong> : Say the playbook configures 5 boxes; creates some mongodb replica set (3 boxes) and deploys some java applications (2 boxes). Basic check after this runs would be to find out if Mongodb members can reach each other, or whether the app boxes can connect and other more specific checks.</p>
  
  <p>Ideally I could use testinfra without the molecule part and I have not really found a way of doing that by also loading the ansible variable file etc.</p>
  
  <p>I have looked into ansible_spec which from my understanding is from serverspec. </p>
  
  <p>Probably my perception of these tools are wrong but, I am thinking of having the check to be say: the last task in the playbook or call it inside the post_tasks stage. 
  Not sure how all these will pan out but I would be grateful if you could share your wisdom with me.</p>
  
  <p>Thanks in advance</p>
  
Comments: CC BY-SA 4.0
Comments: 2020-03-30T06:13:35.013Z
Comments: Do you want to test what the effects of the playbook _will be_ (like a kind of pre-run sanity check), or what they _were_, ie now that I have applied the playbook, is the state of the system correct?
Comments: Bruce Becker
Tags: <ansible><testing><serverspec>
Title: How to test production Ansible execution without having to provision target
UserDisplayName: black sensei
ThreadText: # How to test production Ansible execution without having to provision target
  
  (Asked by: username_0 on 2020-01-08)
  
  We use ansible for our day to day operation and so far so good. We have been looking for a way to run local test etc just like chef guys and found molecule that we use with testinfra/vagrant. While I personally found it great for developing roles, I am looking for a way to actually test the playbook(which uses multiple roles , some with pre and post tasks) itself in **PRODUCTION** after it runs.
  
  **EDITS** : Say the playbook configures 5 boxes; creates some mongodb replica set (3 boxes) and deploys some java applications (2 boxes). Basic check after this runs would be to find out if Mongodb members can reach each other, or whether the app boxes can connect and other more specific checks.
  
  Ideally I could use testinfra without the molecule part and I have not really found a way of doing that by also loading the ansible variable file etc.
  
  I have looked into ansible\_spec which from my understanding is from serverspec.
  
  Probably my perception of these tools are wrong but, I am thinking of having the check to be say: the last task in the playbook or call it inside the post\_tasks stage.
  Not sure how all these will pan out but I would be grateful if you could share your wisdom with me.
  
  Thanks in advance
  
  **Tags:** ansible, testing, serverspec
  
  > **Comments:**
  > **username_1**: Do you want to test what the effects of the playbook _will be_ (like a kind of pre-run sanity check), or what they _were_, ie now that I have applied the playbook, is the state of the system correct?  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_2 on 2023-11-06. Score: 0
  
  This would be a good case for doing a blue-green deployment, it's twice the cost , but half the hassle of having to deploy into production. Plus you get near instant backups.
  
  If you can't trust what you deploy in dev, it's usually your only bet.
  
  You should be able to effectively get blue-green deployments using parameters passed into ansible vault (or a custom inventory playbook).
  
  For ansible, when you add blue or green environments, you could encrypt the relevant data (ip addresses, passwords, keys) with a [vault ID](https://docs.ansible.com/ansible/latest/vault_guide/vault_encrypting_content.html) of blue or green
  
  `ansible-vault encrypt --vault-id blue hostvars/monogo-1.yml`
  
  `ansible-vault encrypt --vault-id green hostvars/monogo-1.yml`
  
  and pass that in to do your deployments,
  
  `ansible-playbook --vault-id blue playbooks playbooks/monog-deploy.yml`
  
  that way, the only thing you need to know is whether blue or green is currently live and deploy the opposite. Of course, that could get a little messy - there may be a better way do to that than rely on the vault, but it's the simplest way I can think of where all you need to know is blue or green.
  
  ---
  
  I'm guessing I misinterpreted your question a bit, but testing *production* seems like a bad idea. Using ansible to test is similarly a bad idea (so saith my company's architects) and I use inspec to test after an ansible deployment.
  
  IMO, testing your blue-green deployment is still better than testing the production deployed environment. Generally speaking though, I trust that ansible did what it said it was doing and I keep the templates generic enough to know that whatever it lacked, wasn't there to begin with.
  
  
  ---
  
  