Server_templates

New

Specify the following parameters to create a new ServerTemplate:

• Nickname - A short nickname that lets you recognize the template. (The instances created from this template will inherit this nickname.)
• Description - Describe the purpose of the template and the inputs that need to be provided. This information is for documentation purposes and does not affect behavior.
• MultiCloud Image - In order to create a ServerTemplate you must specify which MultiCloud image should be used. You can either select an existing MultiCloud Image or create a new MultiCloud object at this time. In order to promote best practices, you must initially select a committed revision of a MultiCloud Image. However, once you've created the ServerTemplate, you can manually edit this setting and select the HEAD version of a MultiCloud Image.

Index

What is a ServerTemplate?
ServerTemplates allow you to pre-configure servers by starting from a base image and adding scripts that run during the boot, operational, and shutdown phases. A ServerTemplate is a description of how a new instance will be configured when it is provisioned by your cloud provider. [test]

View MultiCloud Marketplace
Go to the (Design -> MultiCloud Marketplace) to find a variety of different ServerTemplates that have already been published by RightScale, ISV Partners, and others. For example, you'll find ServerTemplates for building servers that satisfy common server roles such as a PHP FrontEnd, Rails AppServer, MySQL EBS server, etc. Simply find the ones that are relevant for your application and either import or subscribe to them to add copies of them to your 'Local' collection. Use them as-is or clone them to create editable copies that you can customize for your own purposes. Watch our ServerTemplates Video for a better understanding of how ServerTemplates can be used to launch servers in the cloud.

Getting Started with ServerTemplates
To see how easy it is to launch a server with ServerTemplates, check out the LAMP All-In-One Wordpress Trial tutorial which launches a Mephisto Blog on an EC2 instance in less than 10 minutes.

Action Buttons

• New - Create a new ServerTemplate from scratch. You will need to specify a cloud when you create a new ServerTemplate, but later you can add additional clouds under the Clouds tab.
• Diff - Perform a diff by comparing two existing ServerTemplates.
• Merge - Merge the differences between two ServerTemplates.

- -

Show

ServerTemplates allow you to pre-configure servers by starting from a base image and adding scripts that run during the boot, operational, and shutdown phases. A ServerTemplate is a description of how a new instance will be configured when it is provisioned by your cloud provider. The Revision bar allows you to see the most recently committed revisions and [HEAD] version of the ServerTemplate. Click the Revision button to view an exhaustive list of all committed revisions (Revisions tab).

Action Buttons

• Clone - Clone a ServerTemplate to make an editable copy that you can customize for your own needs. Cloned ServerTemplates will be added under the Private tab.
• Commit - You can only commit a [HEAD] version of a template. Commit a ServerTemplate to create a static revision of the current version of the template. As a best practice, you should only use committed revisions of a RightScripts in a production deployment in order to prevent against accidental changes to the script. When a template is committed, the revisions of all its RightScripts become static. Therefore, if you reference a [HEAD] version of a RightScript, it could still be modified an change a template's functionality even though the template has been frozen.
• Delete - Permanently delete the ServerTemplate. You cannot delete a ServerTemplate if the HEAD version or any previous committed revisions of that template are being referenced by a server in a deployment or server array. Use the ServerTemplate's Xref tab to see where it's currently being referenced. Also, you cannot delete a ServerTemplate if any committed revision or HEAD version of it was published to the MultiCloud Marketplace.
• Diff - Perform a diff between the currently viewed ServerTemplate version and either a different revision of the same template or of a completely different template. The resulting output window displays the two user specified templates in parallel, color coding all added (green), removed (red) and modified (blue) attributes.
• Merge - After performing a diff, you may want to merge the changes between the ServerTemplates together.
• Add to Deployment - Add the notion of a server (based on the ServerTemplate) to a deployment of your choice. The server will not be launched when you add it to the deployment.
• Publish to MultiCloud Marketplace - Publish the selected revision or HEAD version to the MultiCloud Marketplace. Once a component has been published to the MultiCloud Marketplace, it can be shared with other RightScale accounts via Account Groups.
• Search RightScripts - Search for scripts or terms within either the private or imported RightScripts of a ServerTemplate.

Revisions tab

The Revisions tab shows the history of all committed revisions of a ServerTemplate. Select a particular revision to view. A revision is snapshot of a ServerTemplate's configuration at a particular time whereas the HEAD version is the working copy and only editable version of the template. New revisions are created using the 'Commit' action button when viewing the HEAD version.

Note: A new revision of a RightScript can be created at the ServerTemplate level when committing a template, updating (diffing/merging) to latest RightScript revisions, or attempting to committing [HEAD] RightScripts.

Update Xref tab

The Update Xref tab cross-references and displays all cases where a server is using this revision of a ServerTemplate. You have the ability to view all the available revisions of this ServerTemplate and select which servers you would like to update to a new revision. Use the "All shown" to select all the servers shown on the page or "None" to deselect all of your selections.

Fields

• Servers - All the servers using the same revision of this ServerTemplate.
• Deployment - The deployment where the server exists.
• Cloud - The cloud where the server exists.
• Instance(s) - View the current instance for a running server. You may also view the "next" instance for a non-running server or when a running server is re-launched.
• State - State of the server (e.g. pending, booting, operational etc.)
• Update - Select the servers you would like to update.

Action buttons

• Update Selected - Update the selected servers to the ServerTemplate revision of your choice.

Scripts tab

The Scripts tab shows all of the RightScripts (executable scripts of code) that makeup a ServerTemplate. RightScripts are grouped according to when they are executed. There are three types of scripts: boot scripts (executed in succession at boot time) operational scripts (additional scripts that can be manually executed during runtime), or decommission scripts (scripts that are executed in succession during the shutdown phase). The order of the boot scripts is important. For example, an Apache install script must be listed before another script that changes the its configuration to work with Rails. To rearrange the order of how scripts are executed (boot and decommission), simply drag and drop the scripts. Since operational scripts are executed on-demand and not automatically, the order is irrelevant. For decommission scripts, you should only list scripts that can ALL be executed in less than 120 seconds, otherwise subsequent scripts may not have enough time to complete execution. For example, you should never list the "DB EBS backup" RightScript as a decommission script because it will take longer than 120 seconds to complete. They run as part of the standard Unix shutdown sequence and are automatically invoked when a server is terminated either through the web interface or using the Unix shutdown command.

To learn how to create a RightScript and add it to a ServerTemplate, check out the Intermediate Example.

When a server is operational, you can manually run (execute) any of the scripts regardless of whether it is listed as a boot, operational, or decommission script. You can also use the "Any Script" dropdown menu to select and run a specific RightScript, which is useful for one time execution. Use the button to change the revision of a script or the to view the script's code. The icon next to a RightScript denotes when a more recent revision of that script is available. No action is required. It is simply a reminder notification that you may want to upgrade your script. For example, when RightScale publishes a revised version of that script, you can click the icon to display the differences between your current script and the most recent revision that's available. And if necessary, you can merge the changes together to upgrade your script to the most recent revision.

If you are viewing an editable (HEAD) version you can perform the following actions:

• commit [HEAD] RightScripts - This action will update all of the HEAD RightScripts. If a HEAD RightScript has uncommitted changes, a new revision will be created and selected. However, if the HEAD RightScript is identical to the latest committed revision, that revision will be selected and no commit will be made. Note: If you commit a ServerTemplate with HEAD RightScripts you will be prompted to also commit any HEAD RightScripts.
• update to latest RightScripts - Automatically update all of the flagged RightScripts (orange balls) to the latest published (committed) revisions that are available.
• Detect Changes in HEAD - Highlight scripts (with a blue ball) that have changes between the committed revision that's being used and its HEAD version (if available). For example, if a script has been modified and you want to use those changes, you might want to commit that script's HEAD version and then update the ServerTemplate to use the latest committed revision. Click the blue ball icon to view a diff between the current revision and HEAD.

As a best practice, any production-ready ServerTemplate should only reference committed (static) revisions of RightScripts. Otherwise, you could edit the HEAD revision of a script and change the functionality of multiple ServerTemplates without any warning. Therefore, when you commit a ServerTemplate, you are prompted to commit any [HEAD] RightScripts in your template (default). You can also be proactive and commit all of the [HEAD] RightScripts in a single action prior to committing the template.

Inputs tab

The Inputs tab shows the input variables of all the RightScripts that are used by the ServerTemplate. Remember, in order to be able to edit the inputs, you must either clone an existing ServerTemplate or create one from scratch. You can edit the [HEAD] revision of any Private ServerTemplate. Many templates already contain default values for common inputs. Inputs have several different levels of control. By default, a server will inherit its inputs from its ServerTemplate. However, if you can define an input's value at the deployment level, you can overwrite a value that's set at the ServerTemplate level. Similarly, if you define an input value at the Server level, it will overwrite an input's value that's set at either the deployment or template level. The same input can be used by more than one script. Use the links below the input value to view a RightScript that references the input in its code. There are several different types of inputs:

• Inherit - specify a value to inherit.
• Ignore - ignore this input when checking that all inputs have a value before launching a server and pass "$ignore" as the input's value into the RightScripts that use the input. This may only be applied to an optional input, and not a required one.
• Env (AWS) - use an EC2 environment variable as the input value, such as the EC2 host name, instance ID, etc.
• Text - a text string. If left blank (-unset-), input inheritance rules will take effect.
• Array - an array of comma-separated values.
• Cred - use a value from one of your stored credentials. As a best practice, you should use credentials for defining sensitive information such as usernames, passwords, or keys.
• Key - use an SSH key as the input value. The SSH key is passed as multi-line text value and thus must be carefully quoted when used in scripts.

Alerts tab

The Alerts tab shows a list of alerts that are attached to the ServerTemplate. Alerts can be defined at the server or ServerTemplate levels. You can either add a new alert or copy an alert from one of RightScale's predefined alerts, from a different server in one of your deployments, or from one of the Private/RightScale/Partner ServerTemplates. Once you copy an alert over, you can edit and customize the alert for your own purposes without affecting the original alert. Alerts are not global. WARNING: Changes to an alert's configuration will take effect immediately. If the server is running, you may want to disable the associated server array unless you want the changes to take effect immediately. You also have the ability to change the status of the alerts. For example, if you wanted to prevent a server from voting for specific alert conditions that would affect autoscaling, you can temporarily disable some or all of the alerts for one hour or 24 hours.

Info tab

The Info tab contains basic information about the ServerTemplate such as its description and ancestry (i.e. where it was cloned from). You can also share one of your private ServerTemplates by changing its sharing status and selecting a sharing group(s). It's recommended that you only share committed revisions so that the recipient of your shared ServerTemplate will have access to a static (not HEAD) revision. When you share a ServerTemplate, its RightScripts, MultiCloud Image, and RepoPaths are also shared.

• Clouds - A list of all clouds for which the ServerTemplate can be used to create a server. (e.g. AWS US-East, AWS US-West, Rackspace, etc.) The list of supported clouds is determined by the MultiCloud Image.
• MultiCloud Image - The MultiCloud Image that is being used by the ServerTemplate. You will only be able to create a server if the ServerTemplate's MultiCloud Image has a reference to a machine image for that cloud.
• Publishing - Lists the publisher of the ServerTemplate. If it's a private ServerTemplate, it shows the publishing status of the ServerTemplate (e.g. Unpublished). Publishing options will only be visible if your account is enabled for sharing and you have 'publisher' role privileges in this account.
• Tags - A list of private tags. Tags are preserved when you commit a ServerTemplate. For example, if you have an "alpha" tag on the HEAD version and then commit the ServerTemplate, the committed revision will inherit any tags.

Repos tab

The Repos tab shows all of the repositories that are being leveraged by the ServerTemplate. Generally speaking, there are two types of repositories: Chef Cookbooks and OS Distributions.

Public software repositories for installation packages can change over time. As an added convenience, RightScale maintains daily snapshots of a number of software repositories. Therefore, as another best practice, you can freeze your software repositories to a specific date to help ensure that a server will launch with the same software versions over time. If you are developing and customizing ServerTemplates, you may want to reference HEAD versions of RightScripts until the ServerTemplate can launch a properly configured server that meets your requirements. Once you can launch a server with the HEAD version of a ServerTemplate you should commit it and create a static revision that you know will always reproduce a solid server. By using a committed ServerTemplate that references committed RightScripts and has frozen software repositories, you can guarantee that the server will be launched the same time, everytime.

Cookbooks Repositories Path
If you are using a MultiCloud Image that's referencing Chef-enabled RightImages (v5 and above), then you can associate a RepoPaths object to the ServerTemplate.

• Cookbooks Repositories Path - The name of the RepoPaths object that's being used by the ServerTemplate. If you've recently made changes to the repo, you can use the refresh button so that you'll have access to the latest Chef cookbooks and recipes under the Scripts tab.
• Repositories - The Chef repositories that are defined by the RepoPath's object. (e.g. git://github.com/rightscale/rightscale_cookbooks). You will be able to use any of the recipes found.

OS Distribution Repositories
A list of all software repositories that are reference by the ServerTemplate. As a best practice for production environments, you should always freeze your software repositories to a specific date in order to ensure that the same software packages will be installed each time a server is created.

Xref tab

The Xref tab cross-references and displays all cases where the ServerTemplate is being used by active/inactive servers. Since ServerTemplates are also cloud agnostic, it will also denote the cloud infrastructures.

Note: For safety purposes, you will not be able to delete a ServerTemplate if either the HEAD version or any committed revisions of that template are being used by a server or server array.

Support tab

The Support tab shows information that's provided by the publisher of the ServerTemplate. You most likely imported this ServerTemplate from the Partner or Shared tab. When ServerTemplates are shared, the publisher is encouraged to provide helpful support information such as links to technical documentation, tutorials, forums, etc. It is the responsibility of the publisher to provide sufficient information about how to use their ServerTemplate. RightScale is not responsible for supporting non-RightScale ServerTemplates. Please contact the publisher directly for troubleshooting issues specifically related to the ServerTemplate.

Images tab

The Images tab lists all of the MultiCloud Images (MCI) that are supported by the ServerTemplate. If there is more than one MCI, you must specify which MCI should be used by default. When you add a Server to a Deployment from the ServerTemplate, the default MCI will be the one that is inherited by the server unless you make another selection. ServerTemplates that are published by RightScale will include a list of all MCIs that the templates were tested with prior to their release. You can safely use any of the supported MCIs, however if you choose to add and use a different MCI with the ServerTemplate, you are strongly encouraged to thoroughly test its compatibility before using it in a production environment.

Action Buttons

• Add MultiCloud Image - In order to promote best practices, only the most recently committed revision of an MCI will be listed in the selector menu. If no committed revision of an MCI exists, the HEAD version will be selectable. Once an MCI has been successfully added to your ServerTemplate's Images list, you can select a different revision or the HEAD version.