Step two of using Scalr to configure and deploy infrastructure is to create Roles. Roles are the building block that define the characteristics of servers that are deployed by Scalr. In their simplest form Roles provide an abstraction layer over the top of the Images. A Role is linked to one or more similar Images, located in different clouds and/or locations, thus providing the flexibility for infrastructure designers and end users to chose the cloud and location for the resulting servers at the time they launch an application.
“Similar” Images are Images that are configured to provide the same behaviour and deliver the same service. Thus all similar Images will have
- The same base operating system and Version
- The same patch levels
- The same pre-installed and configured software packages
Roles can also include options to further manage the behaviour and configuration of servers.
- Orchestration rules that define actions (executed through Scripts) that take place at various lifecycle events throughout the life of a server.
- Global Variables that can be used to pass dynamic values to alter the configuration of servers and execution of Orchestration rules.
- Integration with Configuration Management tools like Chef and Ansible to perform the bootstrap and configuration of servers.
Roles can be created at any scope in Scalr and made available to lower scopes. Account scope roles can be given permissions to restrict which Environments they are available to. By default they will be available to all Environments in the Account.
Role functionality is accessed via Roles in the Main menu or Bookmarks bar at any scope. Note that you can jump straight to New Role from the main menu or click on “Roles” and then “New Role” at the top of the list.
You will now be presented with the New Role screen where you configure all the Role options
|Name||Yes||A meaningful name that typically includes the OS and version and main package e.g. “ubuntu-1404-haproxy”|
|OS Family and Version||Yes||This must match the OS Family and Version of the Images you wish to link to this role|
|Category||Yes||Provides grouping of roles when being selected in the Farm Designer. You can add your own Categories from Roles -> Role Categories menu|
|Description||No||Describes the purpose of the Role and any special details that may be relevant|
|Tags||No||You can include previously defined Policy Tags to associate the Role with governance policies defined in the Policy Engine. You can also add your own tags to help with role grouping related Roles and for use in Cost Management for cost reporting.|
|Quick Start||No||Enable this to include this role in the Quick Start menu of the Farm Designer|
|Use Scalr-Agent||No||Enabled by default and required for Role Orchestration and Auto Scaling. If this is disabled the “Configure Built-In Automation wheel” will be disabled but the option to Use Cloud-Init will appear.|
|Configure Built-In Automation wheel||No||Click on the wheel and select “Chef” to enable the Chef options for this role. This will make the Chef tab visible on the left side. You can only enable Chef when creating a new Role as it cannot be done after the role has been saved. See Note below.|
|Use Cloud-Init||No||This option only appears if “Use Scalr-Agent” is disabled. Enable this option to have Scalr work with Cloud-Init to configure servers. Once enabled the Configure button will appear to enable you to set the Cloud-Int Config|
|Images||Yes||You must link the Role to at least one Image (see below). When you click on ADD IMAGES you will only see Images with the same OS Family/Version that have Scalarizr or CloudInit installed.|
Built in Automations other than Chef will be deprecated in future release of Scalr. They will continue to work for existing roles but should now be replaced by user configured Orchestration Rules.
When adding Images to Roles you need to be aware of the different ways Images are configured in each cloud.
|AWS EC2||Images are unique for every AWS location. You must add every similar Image in every location you want the Role to be enabled for.|
|Azure||Azure Image is common to all regions so only one Image needs be added to the Role|
|GCP||GCP Image is common to all regions so only one Image needs be added to the Role|
|Openstack||Images are unique for every Openstack. You must add every similar Image in every region you want the Role to be enable for.|
|VMware||Images are unique for every VMware location. You must add every similar Image in every location you want the Role to be enable for.|
Orchestration rules define actions to be performed at specific events during the lifecycle of servers. Orchestration rules associated with a Role are inherited by Farm Roles that are created in the Farm designer or Service Catalog.
To configure Orchestration Rules click on the Orchestration tab on the left side of the Role details screen.
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.|
Global Variables in Roles¶
When defining Roles you can define new Global Variables for use in scripts etc as described in the Global Variables section. You may also need to set the value of Global Variables that have been defined at the same or higher scopes. Global Variables defined at the same or higher scope as the role are automatically associated with the Role and will be visible when clicking on the Global Variables tab of the Role screen.
If the value for a variable is already set then the Role can use that value or overwrite it if the variable is configured to allow it.
Ansible Tower in Roles¶
Ansible Tower can be configured at Scalr or Account scope to be used as means to bootstrap servers. See Ansible Integration for more details.
If an Ansible tower server is configured at the or above the scope for the Role, the Ansible Tower tab will be available on the Role configuration screen. This option allows you to enable Ansible Tower Bootstrap for the Role and define bootstrap configuration to be used.
At a minimum, this will ensure the server is added to the correct Organization, Inventory and Group. If you want to run a Job Template during the provisioning of the server, click on the Orchestration tab, then New Rule, select the Event, and then click on AT Job:
Please note! You must click “Prompt on Launch” on all fields in the Ansible Tower Template for Scalr to import the Job Template.
Chef in Roles¶
Chef Servers can be configured at Scalr or Account scope to be used as means to bootstrap servers. See Chef Integration for more details.
If a Chef server is configured at the or above the scope for the Role, the tab will be available on the Role configuration screen. This option allows you to enable Chef Bootstrap for the Role and define either a Chef Server or Chef Solo Cookbook to be used. Within here you can add Chef Roles, Runlists, Cookbooks, and more. All Farm Roles that use this role will inherit the configuration. To add Chef to a role, you must click on the gear icon under Bootstrap Settings in the Roles page and enable Chef:
Then select Chef when the Configure Scalr Automation pop up appears:
Once that is enabled you will then be able to click on the Chef tab on the bottom left of the page which will bring up the pages below.
Account scope roles can optionally have permissions set to define which Environments within the Account can have access to the Role. By default all Environments will have access.