Automating CloudEndure Disaster Recovery blueprint changes for testing and recovery

Non-disruptive testing of a disaster recovery (DR) solution is critical to ensuring frequent and effective validation of that solution. This can be difficult with traditional DR solutions, which can lead to a lack of testing and even a failed recovery during a disaster. To perform non-disruptive testing of DR solutions, companies need a scalable way to change configuration between production DR and test configurations. They also need the ability to remediate any configuration issues quickly and effectively.

CloudEndure Disaster Recovery provides a disaster recovery (DR) solution that has RPOs of seconds and RTOs of minutes, in an easy-to-use package. CloudEndure also allows for unlimited, non-disruptive testing, using CloudEndure blueprints. These tell the CloudEndure Disaster Recovery tool how a specific machine should be configured upon launch, including which VPC to launch into. These configurations are made within the CloudEndure console on a per-machine basis, which can be cumbersome in larger environments.

In this blog, we introduce a scripted process that allows for simple, at-scale changes of CloudEndure blueprints, leading to easier and more frequent testing. We cover two files, a Python script and a YAML file. The YAML file will be used to configure the blueprints of the machines included in the CloudEndure Disaster Recovery Project, and the Python script will tell the CloudEndure API to change the machine blueprints for  Prod or Test mode.

Solution overview

• The source code contains two files: CE-Update-Blueprints.py and ce-config.yml.
  • The file CE-Update-Blueprints.py is the Python Script that updates the CloudEndure blueprints.
  • The file ce-config.yml is a config import file where you add the Blueprint Configurations.

Walkthrough

1. Edit the ce-config.yml file.
2. Launch the file with the python script.
3. Confirm that the blueprints have been changed.

Prerequisites

For this walkthrough, you should have the following prerequisites:

• Source code
• Python3+ installed onto the computer you are running the script from
• CloudEndure DR Project configured
• CloudEndure Agents deployed
• CloudEndure API Token

The following sections break down each step, show options available, and provide sample scripts.

Prepare the config file

Here you will configure the YAML file the script will use for updating the CloudEndure blueprints. This can be edited as many times as needed to ensure the testing environment is configured properly.

1. Locate and open the ce-config.yml file.
   • The following are available blueprint options:
     • machineName: Name of the machine in CloudEndure (must match case displayed)
     • prodsubnetIDs: AWS Subnet ID for Production Subnet
     • testsubnetIDs: AWS Subnet ID for Test Subnet
     • prodsecuritygroupIDs: AWS Security Group ID for Production Security Group
     • testsecuritygroupIDs: AWS Security Group ID for Test Security Group
     • prodprivateIPAction: Production Private IP Address or choose default “CREATE_NEW”
     • testprivateIPAction: Test Private IP Address or choose default “CREATE_NEW”
     • publicIPAction: EIP Setting or choose default “DON’T_ALLOCATE”
     • InstanceType: Instance type or choose default “COPY_ORIG43N”
     • iamRole: IAM Role to attach to instance or choose default “None”
     • tenancy: Amazon Elastic Compute Cloud (EC2) Instance Tenancy or choose default “SHARED”
     • runAfterLaunch: Start (true) or Stop (false) instance after failover.
     • tags: Add tags to instances, update count with the number of tags

2. Update the machinecount under Project to the total machines in the CloudEndure project you want to change.
3. Then add new machine sections, increasing the number to the total number of machines in the CloudEndure console.
4. Now, change the inputs for the various blueprint options shown in the file.
   • Note: You will see in the ce-config.yml that there are two options for each section, Prod and Test.
   • Prod is where CloudEndure should launch the EC2 instances for Production DR failover.
   • Test is where CloudEndure should launch the EC2 instances for testing.
   • The Prod and Test options should be different to ensure the EC2 instances will be launched in the proper AWS architecture.
5. Once you have entered in all of the Blueprint info into the cd-config.yml config file, you are ready to run the Blueprint script.

Running the blueprint script

Now that the YAML files is configured properly, you can use the following steps to launch the servers in their specific configurations.

1. Open a terminal or command prompt onto the computer you are running the script from. Change to the directory where you saved the Python Script and ce-config.yml config file.
2. To run the command to update blueprints for a production failover, enter in Prod for the –mode. To update Blueprints for a Test failover,  enter in Test for the –mode.

The command to run the script is:

Python CE-Update-Blueprints.py –userapItoken <CLOUDENDURE API TOKEN> --projectname <CLOUDENDURE PROJECT NAME> --mode <Prod or Test> --configfile ce-config.yml

Command example:

Python CE-Update-Blueprints.py –userapitoken XXXX-XXXX-XXXX- XXXX-XXXX-XXXX- XXXX-XXXX-XXXX- XXXX-XXXX-XXXX-XXXX- XXXX-XXXX-XXXX –projectname "Default Project" –mode Prod –configfile ce-config.yml

Once the command runs, you will see the following output:

Cleaning up

If this blog is being used as an exercise and not deployment, you will want to remove the resources from your environment. Doing so will ensure you are not being charged for unused resources.

• CloudEndure resources
  1. Navigate to the project in console.cloudendure.com.
  2. Select the checkbox above the machine names.
  3. Choose Machine Actions…
  4. Select the option Delete x Target Machine(s).
     • This will remove all launched test/failover machines

 Conclusion

In this blog, we created multiple YAML files, based on the testing/failover use cases, and launched these projects at scale. Using this method, you can now define your test and production failover blueprints. You also have the ability to be agile and change these values as often as you may need, to ensure DR readiness. The ability to test your DR solution without affecting production workloads has a critical role in helping you recover during a disaster.