When a new sandbox is launched (through the UI, CI plugin or API) CloudShell Colony starts a complex orchestration process in order to deploy your sandbox. During orchestration CloudShell Colony pulls all the following components to deploy your sandbox:
- A blueprint. In general, the blueprint (and the referenced applications) defines where and how the sandbox will be launched, using which cloud account, what the required cloud infrastructure is, what applications to deploy and in what order, etc.
CloudShell Colony pulls the blueprint from your source control repository, then converts it to a cloud template file )e.g. AWS CloudFormation or Azure ARM template), and sends it to the cloud provider which uses the template to create the infrastructure.
- Artifacts (if requested in the blueprint). These are build artifacts that the applications config scripts may require. The artifacts define what will be deployed (in most cases the artifacts are binaries that the application's Initialization script uses).
- Additional Inputs (if declared by the blueprint). This is specific blueprint information that the end user may be required to provide; e.g., database user to create, desired application port, etc.
The infrastructure of each sandbox includes two additional CloudShell Colony components: (1) a remote gateway component, (2) a deployment management component called Sidecar. The remote gateway component allows you to connect to your infrastructure instances directly from CloudShell Colony’s sandbox. Sidecar is responsible for checking the infrastructure’s readiness and managing the application requirements and dependencies.
The Sandbox Deployment Steps
- Creating infrastructure- according to the blueprint, on which your sandbox is based, your cloud provider creates your infrastructure, including networking elements, compute instances, security definitions etc.
- For each application on the same compute instance:
- Preparing artifacts- CloudShell Colony pulls the artifacts making them available for your application’s scripts.
- Deploying applications- Every application, on each compute instance that is ready, is deployed separately and in parallel to the other applications. For detailed information on the steps to the applications deployment, see Steps to Deploying Applications.
- Verifying sandbox- CloudShell Colony runs health checks, in parallel to starting all applications. The health checks wait for the infrastructure to stabilize and the application deployment to be verified.
Parts of the deployment steps can take place in parallel and are not necessarily dependent on each other. Your sandbox is ready when the health check of all the applications successfully completes and the networking infrastructure is ready (IPs, DNS and others). The sandbox remains active until its end time is reached or until you manually end it. As long as the sandbox is active your environment is available for you to perform any development or testing activity.
Steps to Deploying Applications
Application deployment in CloudShell Colony is an efficient process during which all application instances are deployed separately and in parallel to each other. The deployment of an application takes dependencies between applications and the availability of the cloud infrastructure into account. Once the infrastructure of a specific application instance (an application on a specific compute instance) is ready, the application deployment starts and goes through all or some of the following steps:
- Pulling artifacts (optional)- In case there are artifacts, the artifacts are pulled into the artifacts folder of the specific compute instance.
- Waiting for dependencies (optional)- In case there are dependencies between applications, the deployment waits until it is allowed to continue. For more information about application dependencies, see The Blueprint YAML File.
- Running Initialization (optional)- In case there is an Initialization script, the script starts to run and deploys the application.
- Running ‘Start’ script (optional)- In case the application needs to be started, the start script runs.
- Running health check- In parallel to starting the application, the health check starts and waits for both the deployment to be verified and the infrastructure to stabilize.
In most cases, your application will go through all above mentioned steps. When a step is not needed, it is skipped.
NOTE: In simple scenarios, when the Image already includes the deployed application, most of the steps will be skipped and the only steps that remain are ‘waiting for dependencies’ and ‘Running health check’. This ensures that you can control the order of deployments and verify that the application is working as expected.
When all the instances of an application are deployed and verified, the application is considered ready and the sandbox will continue its deployment until the deployments of all the applications are done.