rightscale/rightlink_scriptsmore_vert Shell Last Updated: 2017-11-27T12:01:08Z
rightscale/rightlink_scriptsclose

RightLink Scripts

RightScripts for RightScale's RightLink10 agent used in the Base ServerTemplates and beyond.

This repository contains the collection of RightScripts used in ServerTemplates that go with the new RightLink10 agent. The scripts for the base Linux ServerTemplate are in the rll subdirectory, and the scripts for the base Windows ServerTemplate are in the rlw subdirectory. Additional RightScripts are also in rll-examples and rlw-examples. Each RightScript has a comment header providing metadata info in YAML format with the following fields: RightScript Name, Description, and Inputs. These headers will be used to populate these fields when uploaded to the RightScale platform as RightScripts.

How it Works

The directory structure is kept simple, having Linux RightScripts in the rll and rll-examples directories and Windows RightScripts in the rlw and rlw-examples directories. The naming of the scripts in this repository is also done for simplicity. The RightScript name that is to be shown in the RightScale dashboard should be under the RightScript Name field in the YAML formatted comment header, described earlier.

Developer Info

In order to modify a script in this repo and update the matching RightScript, a few steps will need to be done.

The following setup should only need to be done once to setup the development environment:

  1. In the RightScale dashboard, import the official RightLink 10.X.X Linux Base or RightLink 10.X.X Windows Base ServerTemplate into your account. This will also import the RightScripts.
  2. While still in the RightScale dashboard, clone the imported ServerTemplate, allowing changes to be made to the HEAD revision.
  3. Fork this repo on github and clone the fork to your workstation.
  4. Create a branch (or use master, your choice).
  5. Install and configure right_st for your platform somewhere that is in your PATH.

These next steps are the suggested workflow:

  1. Make a change and git commit the change
  2. Run right_st rightscript upload path/to/script to update the HEAD revision of the RightScript. Remember, the name of the RightScript to update should be provided under RightScript Name in the YAML formatted header.
    • example: right_st rightscript upload rll/enable-monitoring.sh
  3. Verify the HEAD revision of the RightScript has been synced with your git commit and is identical.

RightScale Release Process

The release steps for the Linux and Windows Base ServerTemplate at RightScale are as follows:

  1. Check out the rightlink_scripts repo
  2. Create release branch: git checkout -b 10.2.0 (use appropriate branch name to match release)
  3. Run right_st rightscript upload path/to/script for each script to be released with the ServerTemplate and commit any of these updated RightScripts.
  4. In the RightScale Dashboard, update the ServerTemplates with the new RightScript revisions created from the previous step.
  5. Check the MCIs on the HEAD revision of the ServerTemplates for the correct tags of the current RightLink release.
  6. Rename the ServerTemplate and edit the description to match the name of the RightLink release.
  7. Commit and publish ST

License

See MIT License

bryankaraffa/rightlink_scriptsmore_vert Shell Last Updated: 2017-11-22T19:15:01Z
bryankaraffa/rightlink_scriptsclose

RightLink Scripts

RightScripts for RightScale's RightLink10 agent used in the Base ServerTemplates and beyond.

This repository contains the collection of RightScripts used in ServerTemplates that go with the new RightLink10 agent. The scripts for the base Linux ServerTemplate are in the rll subdirectory, and the scripts for the base Windows ServerTemplate are in the rlw subdirectory. Additional RightScripts are also in rll-examples and rlw-examples. Each RightScript has a comment header providing metadata info in YAML format with the following fields: RightScript Name, Description, and Inputs. These headers will be used to populate these fields when uploaded to the RightScale platform as RightScripts.

How it Works

The directory structure is kept simple, having Linux RightScripts in the rll and rll-examples directories and Windows RightScripts in the rlw and rlw-examples directories. The naming of the scripts in this repository is also done for simplicity. The RightScript name that is to be shown in the RightScale dashboard should be under the RightScript Name field in the YAML formatted comment header, described earlier.

Developer Info

In order to modify a script in this repo and update the matching RightScript, a few steps will need to be done.

The following setup should only need to be done once to setup the development environment:

  1. In the RightScale dashboard, import the official RightLink 10.X.X Linux Base or RightLink 10.X.X Windows Base ServerTemplate into your account. This will also import the RightScripts.
  2. While still in the RightScale dashboard, clone the imported ServerTemplate, allowing changes to be made to the HEAD revision.
  3. Fork this repo on github and clone the fork to your workstation.
  4. Create a branch (or use master, your choice).
  5. Install and configure right_st for your platform somewhere that is in your PATH.

These next steps are the suggested workflow:

  1. Make a change and git commit the change
  2. Run right_st rightscript upload path/to/script to update the HEAD revision of the RightScript. Remember, the name of the RightScript to update should be provided under RightScript Name in the YAML formatted header.
    • example: right_st rightscript upload rll/enable-monitoring.sh
  3. Verify the HEAD revision of the RightScript has been synced with your git commit and is identical.

RightScale Release Process

The release steps for the Linux and Windows Base ServerTemplate at RightScale are as follows:

  1. Check out the rightlink_scripts repo
  2. Create release branch: git checkout -b 10.2.0 (use appropriate branch name to match release)
  3. Run right_st rightscript upload path/to/script for each script to be released with the ServerTemplate and commit any of these updated RightScripts.
  4. In the RightScale Dashboard, update the ServerTemplates with the new RightScript revisions created from the previous step.
  5. Check the MCIs on the HEAD revision of the ServerTemplates for the correct tags of the current RightLink release.
  6. Rename the ServerTemplate and edit the description to match the name of the RightLink release.
  7. Commit and publish ST

License

See MIT License

bryankaraffa/rightscale_scriptsmore_vert Ruby Last Updated: 2016-02-11T21:20:16Z
bryankaraffa/rightscale_scriptsclose

rightscale_scripts

Sandbox for script development and tools for interacting with the RightScale API

rightscale-cookbooks/rs-haproxymore_vert Ruby Last Updated: 2016-01-25T22:08:50Z
rightscale-cookbooks/rs-haproxyclose

rs-haproxy cookbook

Release Build Status

Sets up HAProxy load balancer on a server. This cookbook also provides attributes and recipes to configure SSL on HAProxy and set up HAProxy as the front-end by attaching application servers to its back-end in a 3-tier deployment setup.

The HAProxy server identifies application servers in the same deployment by using machine tags. Refer to the rightscale_tag cookbook for more information on the machine tags set up on the servers in a RightScale environment.

Github Repository: https://github.com/rightscale-cookbooks/rs-haproxy

Requirements

Usage

To install and configure HAProxy with SSL support

  • Add the rs-haproxy::default recipe to your run list.
  • To enable SSL in HAProxy set the node['rs-haproxy']['ssl_cert'] attribute to a PEM formatted string containing the SSL certificate and the credentials. If the node['rs-haproxy']['ssl_cert'] attribute is not set HAPRoxy will be configured without SSL support.

To configure HAProxy as the front-end

  • Add the rs-haproxy::frontend recipe to your run list.
  • Set the node['rs-haproxy']['pools'] attribute to a list of pool names that the HAProxy should serve.
  • Ensure that the application servers to be attached to HAProxy's back-end have application names same as one of the pool names served by HAProxy and the servers have the required machine tags set up. Refer to Application Servers section in the rightscale_tag cookbook for the machine tags set on the application servers.

Attributes

  • node['rs-haproxy']['pools'] - The list of pools that the HAProxy answers. The order of the items in the list will be preserved when answering to requests. The last entry will be the default backend and will answer for all pools not listed here. The pool names can only have alphanumeric characters and underscores. Default: ['default']
  • node['rs-haproxy']['ssl_cert'] - PEM formatted string containing SSL certificates and keys for SSL encryption. If this attribute is set to nil, then HAProxy will be set up without support for SSL. Default: nil
  • node['rs-haproxy']['incoming_port'] - The port on which HAProxy listens for HTTP requests. Default is 80.
  • node['rs-haproxy']['ssl_incoming_port'] - The port on which HAProxy listens for HTTPS requests. Default is 443.
  • node['rs-haproxy']['stats_uri'] - The URI for the load balancer statistics report page. Default: /haproxy-status
  • node['rs-haproxy']['stats_user'] - Username for the load balancer statistics report page. Default: nil
  • node['rs-haproxy']['stats_password'] - Password for the load balancer statistics report page. Default: nil
  • node['rs-haproxy']['session_stickiness'] - Determines session stickiness. Setting to true, the load balancer will reconnect a session to the last server it was connected to (via a cookie). Default: true.
  • node['rs-haproxy']['health_check_uri'] - The URI that the load balancer will use to check the health of a server. Default: /
  • node['rs-haproxy']['balance_algorithm'] - The algorithm that the load balancer will use to direct traffic. Default: roundrobin
  • node['rs-haproxy']['backend']['inter'] - The "inter" parameter sets the interval between two consecutive health checks to milliseconds. Default: 300
  • node['rs-haproxy']['backend']['rise'] - The "rise" parameter states that a server will be considered as operational after consecutive successful health checks. Default: 3
  • node['rs-haproxy']['backend']['fall'] - 'The "fall" parameter states that a server will be considered as dead after consecutive unsuccessful health checks. Default: 2
  • node['rs-haproxy']['maxconn'] - 'Fix the maximum number of concurrent connections on a frontend'. Default: 4096

Recipes

rs-haproxy::default

Installs HAProxy 1.5 by downloading the source package and compiling it. This recipe simply sets up the HAProxy configuration file using the haproxy LWRP, enables, and starts the HAProxy service. If the node['rs-haproxy']['ssl_cert'] attribute is set then this recipe will configure HTTPS support on the HAProxy server. All HTTP requests will be redirected to HTTPS in this scenario.

rs-haproxy::tags

Tags the HAProxy server with the load balancer related machine tags. Refer to rightscale_tag cookbook for the list of tags set on a load balancer server. This recipe must be run to make the HAProxy server discoverable to the application servers in the deployment. The application servers can then attach to the HAProxy server by running the rs-haproxy::backend recipe.

rs-haproxy::collectd

Sets up monitoring for the HAProxy service. This recipe installs the HAProxy collectd plugin to monitor the HAProxy process.

rs-haproxy::frontend

This recipe can be used in two different contexts.

  • To attach all existing application servers in the deployment to the corresponding pools served by the HAProxy server. This recipe finds application servers in the deployment by querying for the application tags on the application server. Only the application servers whose application name matches one of the pool names in HAProxy are identified and attached to the HAProxy server.
  • To be run as a remote recipe for attaching/detaching a single application server to/from the HAProxy servers. To attach a single application server, the server invoking the remote recipe call should set node['remote_recipe']['application_action'] attribute to attach and pass its application name, bind IP address and port, server UUID, and the virtual host name to the HAProxy server. To detach a single application server, this attribute should be set to detach and the invoking server should pass its application name and the server UUID to the HAProxy server. Refer to rsrunrecipe utility for making remote recipe calls and passing information to the remote recipe.

rs-haproxy::schedule

Configure cron to periodically run rs-haproxy::frontend confirming that all application servers in the deployment are registered with HAProxy.

rs-haproxy::hatop

Downloads and installs hatop on the haproxy server, will install python also as it is a requirement

Author

Author:: RightScale, Inc. (cookbooks@rightscale.com)