Sooner or later, every developer faces the necessity to branch the application he is working on, e.g. to try out new functionality before actually implementing it to the production. For such cases, the CirrusGrid PaaS provides a special option – environment cloning, which allows creating a complete copy of an already existing project in just a couple of clicks.
Also, if talking about more complex and sophisticated projects (which implies the involvement of the whole development team), multiple copies of your application (dedicated to a specific task) are recommended. The most common application lifecycle implementation involves the following stages:
- development – for developers to create and modify features
- testing – for quality assurance to discover and analyze possible issues
- production – the latest actual application version, provisioned for end-customers’ use
Below, we’ll provide information on how to make an environment copy and some common use cases.
Note: Take into consideration the following specific points of environment cloning at CirrusGrid:
- based on the layer scaling mode, containers in the clone will be either created from the appropriate base image (stateless) or copied from the master container (stateful)
- you may experience a short-term freeze on source containers due to memory state migration to the cloned nodes (the implementation specifics is similar to live migration)
- while cloning Windows-based environment, containers will be temporarily stopped, so be ready for a short downtime
How to Clone Environment #
In order to create an environment copy, follow the next steps:
1. Click the appropriate Clone Environment button next to your environment, as it’s shown in the image below:
2. Within the appeared pop-up, specify a name for the environment clone or leave the default one and click Clone.
3. In a few minutes, the environment will be duplicated and ready for use.
Tip: For some specific cases, additional adjustments are required to make your environment copy operable:
- nodes' IP addresses and hostnames will differ from the initial ones and, in case of being “hardcoded” within config files, should be re-adjusted manually
- if you’ve faced a problem when cloning a massive environment (i.e. with more than 1TB of data being stored in containers), please contact your hosting provider for assistance
- an environment in collaboration can be cloned only by its owner; herewith, the created copy won’t be available to collaborators by default
Common Use Cases #
Consequently, you can use your environments in the following ways:
- rename (change internal domain) of your environment
- swap domains to redirect your clients to the upgraded project
- implement blue-green deployment to allow so-called “invisible” updates, which will not cause any downtime for your application
- perform applications A/B testing (i.e. compare different versions) to designate which one provides better user appeal
- achieve advanced failover protection of your application
- configure data storing from several environments in a single Dedicated Storage Container to utilize disk space more efficiently
- clone environment to create a “snapshot” of the whole setup
- you can configure replication or synchronization of data from the production to clone, ensuring that data on your testing/staging environment remains actual
These use cases can help you to get the most from your original environment and its copy.
