Scalr/Account/Environment Level Orchestration¶
Orchestration Rules can be defined to run scripts across all applicable servers within the scope at which the rule is defined.
- At the Scalr scope, scripts will run on all applicable servers in all Environments managed by this Scalr installation.
- At the Account scope, scripts will run on all applicable servers in all Environments with the Account.
- At the Environment scope, scripts will run on all applicable servers within the Environment.
This type of Orchestration is typically used to enforce policies, for example:
- Security toolsets that must be applied to all servers.
- Lifecycle events that must be applied to all servers, i.e. join a domain.
If an Orchestration rule is created at one of these scopes, it cannot be removed at the lower scope and ALL servers at the lower scope will have the rule applied to it.
Creating Orchestration Rules¶
Orchestration rules can be defined in many places in Scalr. What follows covers all aspects of rule configuration regardless of where they are configured.
Orchestration Rules are made up of three main elements.
|Trigger Event||The lifecycle event of the a server that will cause the Orchestration Rule Script to execute such as OnHostUp or BeforeHostTerminate|
|Target||Criteria for identifying the server on which to run the Script which need not be the triggering server and can be multiple servers|
|Action||The script, Chef Cookbook or Ansible Tower job to be run.|
First select the Trigger Event for this rule. The following table describes each event and the state of the Server when the event fires.
|BeforeInstanceLaunch||Scalr fires the BeforeInstanceLaunch Event after making an API Call to your Cloud Platform.|
|HostInit||The Instance finished booting and Scalr is now configuring the Environment and initializing Services.|
|IPAddressChanged||Public IP address of the instance was changed upon by reboot or within Elastic IP assignments.|
|EBSVolumeAttached||EBS volume was attached to the instance.|
|EBSVolumeMounted||An EBS Volume has been attached and mounted to the Instance.|
|BeforeHostUp||Time for user-defined actions before the instance will be added to DNS, Loadbalancers etc|
|HostUp||The Instance has booted and Environment and Services are running. Instance will now be added to Load Balancer, DNS Zone etc.|
|BeforeHostTerminate||The Instance is flagged for termination and will be terminated after 180 seconds.|
|HostDown||The instance will be terminated.|
|RebootComplete||The Instance has finished rebooting.|
|ResumeComplete||The instance was successfully resumed after a suspension.|
|HostInitFailed||Instance booted up but Scalr environment is not configured and the services are not initialized yet.|
|Custom Events||Any Custom Events defined at this scope or higher.|
|All Events||Rule will fire for any event including Custom Events.|
After an Instance finishes booting the OS, the Scalr Agent starts configuring your Environment in a certain order as follows.
- All EBS / Disk Routines are executed.
- Deployment Routines are executed.
- Server Configuration (including vhosts) Routines are executed. If you wish to work with Virtual Hosts, you can assign a Script to the BeforeHostUp Event.
You must define the target for executing the script. The default is to execute only on the instance that triggered the event. The other options are as follows. Note that availability of targets depends on the scope at which the rule is being defined.
There are three choices for the Action for a rule.
The advanced configuration section allows you to control various aspects of how the Action is executed.
|Execution Mode||Blocking: Scalarizr will wait for your Script to finish executing before firing and processing further events|
|Non-Blocking: Scalarizr will not wait for your Script to finish executing before firing and processing further events|
|Timeout||Length in seconds before the script should timeout. This should be increased for complex actions, especially those that download from the internet.|
|Order||Sequence in which rules must be executed. This defaults to the order in which the rules are created.|
|Run As||For Scripts and Chef only defines the user to execute the script as on the server.|