Deployment Prerequisites (Windows)
Objective
To complete the necessary prerequisite steps before building a deployment with RightScale's Windows ServerTemplates.
Table of Contents
Overview
The following steps should be performed before you attempt to build a multi-tier deployment.
Steps
Create a Deployment
It's recommended that you create a new deployment (Manage > Deployments) for each new project or reference architecture that you're going to build because you do not want to accidentally inherit any unknown configuration settings.
See Create a New Deployment. (Requires 'actor' user role privileges.)
Tip: It's recommended that you create a bookmark to the deployment's Servers tab for quick navigation back to the deployment at any time.
Create Cloud-specific Resources
Prerequisites: Requires 'actor' user role privileges in the RightScale account to create SSH Keys and Elastic IPs, and 'security_manager' privileges to create security groups.
Each cloud infrastructure is unique and requires different resources in order to launch a server in their cloud. Depending on the type of cloud infrastructure that you're going to use to launch servers, you will find it useful to create some of the required cloud-specific resources beforehand so that you can select them in the "Add Server Wizard" when you add servers into a deployment. Cloud resources are also cloud-specific. For example, you cannot launch an EC2 instance in the 'us-east' region with an 'us-west' security group.
SSH Key
If the cloud does not support the use of an SSH Key, you can ignore this step.
SSH Keys are used for authentication purposes to create SSH console sessions for root level access to the instance. Although you are required to associate an SSH Key to a server before you can launch it, the private key material is no longer required if managed SSH (Server Login Control) is enabled for the account (Settings > Account Settings > SSH). By default, Server Login Control is enabled at the account level, where a user's own unique RSA key pair (Settings > User Settings > SSH) is used for authentication purposes for establishing SSH console sessions on all RightLink-enabled instances.
You can either use an existing SSH Key or create a new one.
- Amazon EC2
Security Groups
If the cloud does not support Security Groups, you can ignore this step.
Security groups are firewall settings that apply to instances within a cloud at the infrastructure layer. Security groups are typically used to control ingress communication (i.e. inbound communication to an instance over a particular port and protocol) however, some clouds support the use of security groups to also control egress communication (i.e. outbound requests from the instance). Once you create a security group you can create different firewall rules that control the level of access to instances launched with that particular security group(s). Firewall rules are enforced at the cloud (infrastructure) level using IP-based or Group-based permissions.
If you are building this deployment for demonstration and testing purposes, you can simply create a single security group for all servers in your deployment.
The steps for creating a single security group are different depending on the type of account and cloud that you are using.
- For a Unified Cluster Platform (UCP) RightScale account (e.g. us-3.rightscale.com), follow the cloud-specific instructions below.
- For a Legacy Platform RightScale account (e.g. my.rightscale.com), follow the cloud-specific instructions below.
Once you are successful setting up your first multi-tier deployment you can set up more secure firewall permissions that would be more realistic for production environments. See Configuring multiple Security Groups for a multi-tiered Deployment.
Remappable Public IP Addresses
Some clouds support the use of public IP addresses that you can associate with a server at launch time or remap to another running server, as necessary for lifecycle management scenarios. It's recommended that you use this service, if available for front-end load balancer or web servers that are designed to be public facing. If you're using dedicated HAProxy load balancer servers, you should create/reserve one IP address for each load balancer server. Typically, you will have two HAProxy load balancer servers for high-availability and failover purposes. If you are using a cloud's load balancing service such as Amazon Elastic Load Balancers (ELB) or Rackspace Cloud Load Balancers (CLB) you cannot assign remappable IP addresses. In such cases, skip this step.
- Amazon EC2
- Rackspace Private, CloudStack, OpenStack, HP, Datapipe
Create DNS Records
In a typical 3-tier architecture setup, DNS A records are used to create fully qualified domain names (FQDNs) that map to a particular server or tier of servers. The digram below shows a typical example of a 3-tier website architecture.
For example, the application servers locate the standalone or principal SQL database server by using the database server's FQDN (e.g., db-principal.example.com), which points to the server's private IP address. Similarly, front-end web traffic can be routed to a FQDN (e.g. www.example.com) where each load balancer server has a DNS record for that FQDN so that incoming requests are routed to one of the load balancer servers. Since the IP address of an instance in the cloud is often dynamically assigned at launch time, you are required to use a DNS provider that supports dynamic DNS (i.e. the ability to dynamically update the IP address of an A record) for the standalone/principal server (at a minimum). You can also use the same DNS provider for creating FQDNs for the load balancer servers. However, since they do not require the use of dynamic DNS, any DNS provider can be used.
TTLs
When you create the DNS records, it's important to set appropriate TTLs to ensure that servers will not stay connected to an old IP address that is no longer assigned to a functional server. For example, the DNS record that points to the standalone/principal database server should have a low TTL to ensure that the application servers will connect to the correct server within a reasonable amount of time. It's strongly recommended that you use a TTL of 60 seconds for the DNS record that points to the standalone/principal database server. If you are also creating DNS records for the front-end load balancer servers, you can use a more conservative TTL than the database tier. (e.g. 1800 seconds)
Note: If you are using Rackspace's Cloud DNS service, you must use a TTL of 300 seconds for the database servers because it's the lowest allowable TTL. Be sure to change the 'DNS_TTL' input from 60 (default) to 300.
You will need to create DNS records for the following servers:
- Each Load Balancer Server or Load Balancing service (e.g. Amazon Elastic Load Balancer, Rackspace Cloud Load Balancer, etc.)
- Standalone/Principal Database Server
- Mirror Database Server (Optional)
RightScale's ServerTemplates contain scripts that support one of the following DNS providers. Create an account with one of the DNS providers below and set up the A records accordingly.
Important! The tutorials below assume that you are creating records for a Linux-based architecture. However, you can follow the general steps to create the DNS records that are required for Windows.
Create Credentials
Prerequisites: Requires 'designer' user role privileges in the RightScale account to create a new credential.
Important!
Only the user who created the credential and any 'admin' users will be able to view and modify an existing credential.
Credentials are a way of passing sensitive information to a script (as an input) in a discrete manner without making the actual value visible in the Dashboard. As a best practice, many of the ServerTemplates published by RightScale are preconfigured to use certain credentials. It's recommended that you create these common credentials in your own account. If they already exist and apply to a different deployment, you might want to create a new set of credentials to avoid any conflicts. In such cases, it's helpful to use a common prefix to group the credentials together. (e.g. ProjectX-SQL_APPLICATION_USER)
If you try to launch a server where one of the inputs references a credential that does not exist in the RightScale account, you will receive an error message and will not be able to launch the server. Therefore, it's best to create any required credentials before you configure and launch a server. Depending on your cloud provider and backup storage selections, you may want to create additional credentials.
At a minimum, create the following credentials. See Create a New Credential for more information.
Common Credentials for a 3-Tier Windows Architecture
If you are going through a 3-tier tutorial you should create the following credentials with your own values or you can use the example values, if desired.
Windows
By default, when you launch a Windows server in the cloud, an initial password is automatically generated for the Windows 'Administrator' user. However, each Windows-based ServerTemplate published by RightScale contains a boot script ('SYS Set admin account') that allows you to change the password for the 'Administrator' user with the ADMIN_PASSWORD input. If you do not want to use the 'Administrator' user (default), you can also create a new user with administrative privileges by using the ADMIN_ACCOUNT_NAME input. At a minimum, it's strongly recommended for security reasons that you create a credential for the ADMIN_PASSWORD input in order to use your own password instead of the randomly generated one, which will keep the password private. Only a user with 'admin' privileges or the user who created the credential will be able to view the actual value stored in the credential. Once a server is launched you will use the username and password to start a Remote Desktop Protocol (RDP) connection to the instance.
- WINDOWS_ADMIN_PASSWORD - Password for the Windows 'Administrator' user (default) or specified user with administrative privileges. You must specify a value that satisfies the minimum password requirements, otherwise the initial Windows password will be used instead. For example, a valid password should contain at least 7 characters and include at least one upper case letter, one lower case letter, and one digit. See Password Policy for details.
Microsoft IIS/SQL
If you are setting up a multi-tier deployment using ServerTemplates based on RightScale's IIS and SQL ServerTemplates, a SQL user with application privileges is required by the application to connect to the SQL database.
- SQL_APPLICATION_USER - SQL database user with login privileges to the specified user database.
- SQL_APPLICATION_PASSWORD - Password for the SQL database user with login privileges to the specified user database.
DNS
- DNS_USER* - Username that's used to log into your DNS provider and update DNS records. It's commonly used to update the A record with the private IP address of the "principal" database server.
- DNS_PASSWORD* - Password for DNS_USER.
* If you use Amazon Route 53 as your DNS provider, you do not need to set up separate DNS user name and password credentials because your AWS credentials are used for authentication purposes.
Remote Object Storage (ROS)
ServerTemplates published by RightScale have built-in support for several remote object storage (ROS) solutions. Valid cloud credentials are required to retrieve "private" files from an ROS container, create a new container, or store files in a container (such as a binary database backup files).
Set up your desired ROS service(s) and create the recommended user-defined credentials, which you will use when you define inputs for your deployments.
Software Repositories
Source Control Management (SVN, GitHub)
If you are using a source control management (SCM) system to host your application code, you will need to create the following credentials to retrieve your source code from the specified repository.
-
GIT_SSH_KEY - A valid SSH Key for accessing a private repository hosted on GitHub.com.
- SVN_USERNAME - The SVN username that has access to the specified repository.
- SVN_PASSWORD - Password for SVN_USERNAME.
Secure Sockets Layer (SSL)
Load Balancer
If you are using SSL to support HTTPS access, you should create credentials for any of the following values that apply. See How do I create an SSL certificate for my web server?
- LB_STATUS_USERNAME - Optional user name to require in order to log in to the HAProxy status report page.
- LB_STATUS_PASSWORD - Optional password corresponding to LB_STATUS_USERNAME.
- SSL_CERTIFICATE - Contents of the X.509/PEM-format SSL server certificate used for enabling HTTPS communications.
- SSL_CERTIFICATE_CHAIN - The certificate authority (CA) certificate chain associated with the server certificate used to set up HTTPS communications.
- SSL_CERTIFICATE_KEY - The SSL server certificate's private key, in PEM format.
- SSL_PASSPHRASE - If required by an SSL certificate, you must provide the passphrase so Apache can start.
See also
- © Copyright 2015 RightScale Technical Support