To allow you to build reusable applications and provide you with a self-service experience, CloudShell Colony includes some important features:

Sandbox Local DNS Service

CloudShell Colony configures a local DNS service in every sandbox. All applications and their address are registered in the sandbox DNS. This makes it easy to reach any application from every instance inside the sandbox using the sandbox DNS convention.

For example, In our WordPress application, we use MySQL as the backend server, which is deployed in the sandbox and may get different connectivity details in different sandboxes.

The WordPress Initialization script needs to configure the website's access to the database so instead of hard-coding it in the script or locating the correct IP address of the database, our Initialization script is using the Sandbox Discovery service:

sed -i "s/localhost/mysql.$DOMAIN_NAME/g" wp-config.php

The address /localhost/mysql.$DOMAIN_NAME translates, by the Sandbox Discovery service, to the correct address of the MySQL Server.

User Input Parameters and Environment Variables

In CloudShell Colony, applications can declare input parameters. These parameters can either be provided during runtime by the user/CI build or be defined inside the blueprint's YAML. Using parameters is very handy for creating a self-service experience as it allows the application to declare a clear interface for all its consumers:

mysql.yaml 
inputs: 
- DB_USER: '' 
- DB_PASS: ''

CloudShell Colony creates environment variables for all the parameters, which makes it easy to use parameters in scripts.

echo "mysql-server mysql-server/root_password password $DB_PASS" | debconf-set-selections echo "mysql-server mysql-server/root_password_again password $DB_PASS" | debconf-set-selections
 

In this example, the Initialization script uses the input parameters as Environment Variables (using the dollar sign $DB_PASS).

Referencing environment variables in scripts depends on the operating system script syntax.