Specify the following parameters to create a new ServerTemplate:
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.
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).
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.Design > ServerTemplates > Show > Revisions 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.
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:
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.Design > ServerTemplates > Show > Scripts 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:
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.Design > ServerTemplates > Show > Alerts 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.
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.
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.
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.Design > ServerTemplates > Show > Xref 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.Design > ServerTemplates > Show > Support 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.
© 2006-2014 RightScale, Inc. All rights reserved.
RightScale is a registered trademark of RightScale, Inc. All other products and services may be trademarks or servicemarks of their respective owners.