Answers: <p><a href="http://www.vagrantup.com" rel="noreferrer">http://www.vagrantup.com</a></p>
  
  <p>You could use vagrant to deploy VMs on the local laptop.</p>
  
  <p>You could also check whether it is possible to split the script in smaller parts so it will not take four hours to test it.</p>
  
Answers: CC BY-SA 3.0
Answers: 2017-12-05T15:13:05.703Z
Answers: 2017-12-05T15:13:05.703Z
Answers: 030
Answers: <p>If testing locally isn't an option, then the most straight forward approach would be to use disk volume snapshots/backups to your advantage. These will still cost $$$, but will save you time in the long run. You should then separate your bash script into different working segments/scripts that can be tested individually. Once your server is provisioned, run a script, then take a snapshot. If it was successful, run the next script, take a snapshot, then rinse and repeat. If your script fails, modify the script, revert to the last successful snapshot, then try again. </p>
  
  <p>NOTE: I'm not sure if you can take snapshots of virtual machine disks in IBM Cloud/Softlayer, but it looks like you can create a VM image pretty easily. </p>
  
  <blockquote>
    <p>Backing up virtual machine images</p>
    
    <p>You can back up a virtual machine
    image in your instance. This function creates a copy of the virtual
    machine image and cloud configuration that can be restored later.
    Additionally, you can manage these backup images. Details about the
    backup image are as follows: </p>
    
    <p>The backup image is an exact copy of the
    virtual machine image and the cloud configuration. No image cleanup is
    performed. </p>
    
    <ul>
    <li><p>The backup image cannot be deployed as a new instance. It
    can be used only to restore the associated virtual machine image and
    cloud configuration. </p></li>
    <li><p>Only the project owner (or an administrator) has
    access to restore the backup virtual machine images and backup virtual
    machine. </p></li>
    <li><p>If you are using an OpenStack cloud, only one instance backup
    operation is allowed at the same time. If another user is running a
    backup and you start one on the same instance, you receive an error
    that states there is a conflicting request. To perform a backup, you
    must wait until the other backup is finished. </p></li>
    <li><p>OpenStack PowerVM® and
    z/VM® instances do not support this action. </p></li>
    <li><p>If the instance is deleted
    by using IBM® Cloud Manager with OpenStack, the associated backups are
    also deleted.</p></li>
    </ul>
  </blockquote>
  
  <p><a href="https://www.ibm.com/support/knowledgecenter/en/SST55W_4.1.0/liacb/liacbsaverestorevsvmw.html" rel="nofollow noreferrer">https://www.ibm.com/support/knowledgecenter/en/SST55W_4.1.0/liacb/liacbsaverestorevsvmw.html</a></p>
  
Answers: CC BY-SA 3.0
Answers: 2017-12-05T15:39:19.683Z
Answers: 2017-12-05T16:05:33.933Z
Answers: 2017-12-05T16:05:33.933Z
Answers: Preston Martin
Answers: <p>I can see some options:</p>
  
  <ul>
  <li>Use Vagrant to create your VMs; it separates the process of creating the VM (including the base OS) and the actual provisioning. It also has some options to run certain provisioning steps at certain circumstances only.</li>
  <li>Use Ansible, Puppet or something like that to switch to a provisioning mode where you do not do the same stuff everytime, but only what is needed. This means that you can start the job, and at the first failed part, stop. Fix that part, then continue.</li>
  <li>Use Docker. This is slightly different than the Vagrant/Ansible approach in that it creates containers (which you don't actually need, as far as I can tell). It has the benefit, beyond the Ansible approach, that it gives you a very fine grained step-by-step development process. I.e., if one step fails, you still have all the images leading up to that, so during development, with a bit of discipline, you become very, very fast indeed.</li>
  </ul>
  
  <p>All of these tools do much more than what you need, but all of them give you a way to do your job incrementally. Vagrant, Ansible and Docker are pretty easy to learn, as far as I'm concerned (as long as you are in Dev/Test mode, the "interesting" parts start when you go to production). Ansible is very minimalistic and needs nothing except a ssh connection. Vagrant and Docker might not be feasible in your infrastructure, you will quickly see.</p>
  
Answers: CC BY-SA 3.0
Answers: 2017-12-05T16:57:46.153Z
Answers: 2017-12-05T16:57:46.153Z
Answers: AnoE
Body: <p>Currently I'm on a state that testing costs me money and a lot of time...</p>
  
  <p>Background: I'm deploying VMs at softlayer and using a post-deployment script(bash) that will install every software that I need after the VM is ready.
  The problem is, I can only test this script by deploying one VM, and it's currently taking around 4h for the script to finish... So every change that I make I need to create a new VM(costs money) and wait for around 4 hours to see if the script is broken or not... This is becoming chaotic and I won't be able to move forward if I stay this way.</p>
  
  <p>I need a new way to approach this kind of situation and be able to test the provisioning script more quickly and without needing to deploy a new VM every time.</p>
  
  <p>Do you guys know some tool to help me on this scenario ?</p>
  
Comments: CC BY-SA 3.0
Comments: 2017-12-05T14:51:42.790Z
Comments: Is it not possible to test your provisioning (bash) script on a local dev VM by running it locally?
Comments: Rekovni
Comments: CC BY-SA 3.0
Comments: 2017-12-05T15:57:44.787Z
Comments: This is a place where a private cloud would shine.  Buying one and setting it up could cost you less than what you are currently doing.  Run the numbers.  See what makes sense for you.
Comments: chicks
Tags: <testing><provisioning><virtualization>
Title: How to test VM provisioning script without provisioning
UserDisplayName: Lucas Mattos
ThreadText: # How to test VM provisioning script without provisioning
  
  (Asked by: username_0 on 2017-12-05)
  
  Currently I'm on a state that testing costs me money and a lot of time...
  
  Background: I'm deploying VMs at softlayer and using a post-deployment script(bash) that will install every software that I need after the VM is ready.
  The problem is, I can only test this script by deploying one VM, and it's currently taking around 4h for the script to finish... So every change that I make I need to create a new VM(costs money) and wait for around 4 hours to see if the script is broken or not... This is becoming chaotic and I won't be able to move forward if I stay this way.
  
  I need a new way to approach this kind of situation and be able to test the provisioning script more quickly and without needing to deploy a new VM every time.
  
  Do you guys know some tool to help me on this scenario ?
  
  **Tags:** testing, provisioning, virtualization
  
  > **Comments:**
  > **username_1**: Is it not possible to test your provisioning (bash) script on a local dev VM by running it locally?  
  > **username_2**: This is a place where a private cloud would shine.  Buying one and setting it up could cost you less than what you are currently doing.  Run the numbers.  See what makes sense for you.  
  
  ---
  
  ## 3 answers
  
  ### Answer by username_5 on 2017-12-05. Score: 10
  
  I can see some options:
  
  * Use Vagrant to create your VMs; it separates the process of creating the VM (including the base OS) and the actual provisioning. It also has some options to run certain provisioning steps at certain circumstances only.
  * Use Ansible, Puppet or something like that to switch to a provisioning mode where you do not do the same stuff everytime, but only what is needed. This means that you can start the job, and at the first failed part, stop. Fix that part, then continue.
  * Use Docker. This is slightly different than the Vagrant/Ansible approach in that it creates containers (which you don't actually need, as far as I can tell). It has the benefit, beyond the Ansible approach, that it gives you a very fine grained step-by-step development process. I.e., if one step fails, you still have all the images leading up to that, so during development, with a bit of discipline, you become very, very fast indeed.
  
  All of these tools do much more than what you need, but all of them give you a way to do your job incrementally. Vagrant, Ansible and Docker are pretty easy to learn, as far as I'm concerned (as long as you are in Dev/Test mode, the "interesting" parts start when you go to production). Ansible is very minimalistic and needs nothing except a ssh connection. Vagrant and Docker might not be feasible in your infrastructure, you will quickly see.
  
  
  ---
  
  ### Answer by username_3 on 2017-12-05. Score: 6
  
  <http://www.vagrantup.com>
  
  You could use vagrant to deploy VMs on the local laptop.
  
  You could also check whether it is possible to split the script in smaller parts so it will not take four hours to test it.
  
  
  ---
  
  ### Answer by username_4 on 2017-12-05. Score: 5
  
  If testing locally isn't an option, then the most straight forward approach would be to use disk volume snapshots/backups to your advantage. These will still cost $$$, but will save you time in the long run. You should then separate your bash script into different working segments/scripts that can be tested individually. Once your server is provisioned, run a script, then take a snapshot. If it was successful, run the next script, take a snapshot, then rinse and repeat. If your script fails, modify the script, revert to the last successful snapshot, then try again.
  
  NOTE: I'm not sure if you can take snapshots of virtual machine disks in IBM Cloud/Softlayer, but it looks like you can create a VM image pretty easily.
  
  > Backing up virtual machine images
  >
  > You can back up a virtual machine
  > image in your instance. This function creates a copy of the virtual
  > machine image and cloud configuration that can be restored later.
  > Additionally, you can manage these backup images. Details about the
  > backup image are as follows:
  >
  > The backup image is an exact copy of the
  > virtual machine image and the cloud configuration. No image cleanup is
  > performed.
  >
  > * The backup image cannot be deployed as a new instance. It
  >   can be used only to restore the associated virtual machine image and
  >   cloud configuration.
  > * Only the project owner (or an administrator) has
  >   access to restore the backup virtual machine images and backup virtual
  >   machine.
  > * If you are using an OpenStack cloud, only one instance backup
  >   operation is allowed at the same time. If another user is running a
  >   backup and you start one on the same instance, you receive an error
  >   that states there is a conflicting request. To perform a backup, you
  >   must wait until the other backup is finished.
  > * OpenStack PowerVM® and
  >   z/VM® instances do not support this action.
  > * If the instance is deleted
  >   by using IBM® Cloud Manager with OpenStack, the associated backups are
  >   also deleted.
  
  <https://www.ibm.com/support/knowledgecenter/en/SST55W_4.1.0/liacb/liacbsaverestorevsvmw.html>
  
  
  ---
  
  