Difference between revisions of "RCauth Delegation Server & MasterPortal - Ansible scripts"

From PDP/Grid Wiki
Jump to navigationJump to search
(master portal ansible intro)
(general structure)
Line 1: Line 1:
 
= Introduction =
 
= Introduction =
  
After experimenting with the [[CILogon Pre-Pilot Work - Jenkins | Jenkins]] as a method of deployment for the [[CILogon Pre-Pilot Work | CILogon Pilot]] we quickly had to come to the conclusion that Jenkins was not meant to be used for such deployments. Although it can spin up machines and run any kind of configuration scripts on them, it was still lacking the kind of configuration control and templating capabilities that we were looking for. We decided to move away from it an use one of the more widespread tools for deployments and configuration.
+
After experimenting with [[CILogon Pre-Pilot Work - Jenkins | Jenkins]] as a method of deployment for the [[CILogon Pre-Pilot Work | CILogon Pilot]] we quickly had to come to the conclusion that Jenkins was not meant to be used for such deployments. Although it can spin up machines and run any kind of configuration scripts on them, it was still lacking the kind of configuration control and templating capabilities that we were looking for. We decided to move away from it and use one of the more widespread tools for deployments and configuration.
  
Out pick fell on [http://docs.ansible.com/ Ansible] mainly because of the following point:
+
Out pick fell on [http://docs.ansible.com/ Ansible] mainly because of the following points:
  
 
* support for configuration templating  
 
* support for configuration templating  
Line 9: Line 9:
 
* no client software required (runs through ssh)
 
* no client software required (runs through ssh)
 
* good documentation
 
* good documentation
 +
 +
== General Structure ==
 +
 +
The ansible deployment scripts are structured into, what ansible calls [http://docs.ansible.com/ansible/playbooks.html plays]. In our deployment scripts we used a single play to configure a single host of a specific kind. Ansible plays are made up of [http://docs.ansible.com/ansible/playbooks_roles.html#roles roles]. We are using roles as a means of grouping tasks that logically belong together.
 +
 +
Giving input to the deployment scripts is done through overwriting existing variables. Each ansible role contains two sets of variables:
 +
 +
* '''roles/x/vars/main.yml''' holds OS specific variables (like package names, repositories, service name, etc...). These are only used within a role (x), and they '''cannot''' be overwritten by variables defined inside a play (see [http://docs.ansible.com/ansible/playbooks_variables.html#variable-precedence-where-should-i-put-a-variable variable precedence]). However, in order to support different OS versions, we have separate OS specific variable files under roles/x/vars/, like rh7.yml or rh6.yml. Depending on the OS version that you are using for your deployment, you should define the roles/x/vars/main.yml as a symlink to one of the existing OS specific variable files.
 +
 +
* '''roles/x/defaults/main.yml''' holds application specific variables (like configuration options, paths, etc...). These are only used within a role (x), and they '''can''' be overwritten by variables defined inside a play. For each defined role 'x' you will find a corresponding variables file name 'x_env.yml' in the top level directory. This variables file is used together with the 'x' role inside a play. Use this variables file to overwrite defaults! Note that not ALL variables from the defaults are meant to be overwritten (for examples paths can stay the same). You will find a 'x_env.yml' template for each role that will tell you which variables you SHOULD overwrite (like passwords).
  
 
= Master Portal =
 
= Master Portal =

Revision as of 11:50, 13 July 2016

Introduction

After experimenting with Jenkins as a method of deployment for the CILogon Pilot we quickly had to come to the conclusion that Jenkins was not meant to be used for such deployments. Although it can spin up machines and run any kind of configuration scripts on them, it was still lacking the kind of configuration control and templating capabilities that we were looking for. We decided to move away from it and use one of the more widespread tools for deployments and configuration.

Out pick fell on Ansible mainly because of the following points:

  • support for configuration templating
  • easy to use modules to interact with systems
  • no client software required (runs through ssh)
  • good documentation

General Structure

The ansible deployment scripts are structured into, what ansible calls plays. In our deployment scripts we used a single play to configure a single host of a specific kind. Ansible plays are made up of roles. We are using roles as a means of grouping tasks that logically belong together.

Giving input to the deployment scripts is done through overwriting existing variables. Each ansible role contains two sets of variables:

  • roles/x/vars/main.yml holds OS specific variables (like package names, repositories, service name, etc...). These are only used within a role (x), and they cannot be overwritten by variables defined inside a play (see variable precedence). However, in order to support different OS versions, we have separate OS specific variable files under roles/x/vars/, like rh7.yml or rh6.yml. Depending on the OS version that you are using for your deployment, you should define the roles/x/vars/main.yml as a symlink to one of the existing OS specific variable files.
  • roles/x/defaults/main.yml holds application specific variables (like configuration options, paths, etc...). These are only used within a role (x), and they can be overwritten by variables defined inside a play. For each defined role 'x' you will find a corresponding variables file name 'x_env.yml' in the top level directory. This variables file is used together with the 'x' role inside a play. Use this variables file to overwrite defaults! Note that not ALL variables from the defaults are meant to be overwritten (for examples paths can stay the same). You will find a 'x_env.yml' template for each role that will tell you which variables you SHOULD overwrite (like passwords).

Master Portal

The ansible scripts for deploying a Master Portal can be found under the Nikhef subversion, here. You can use these scripts to deploy a Master Portal and Credential Store on two separate hosts, or into one single host. Before you begin executing plays make sure to decide whether you're deployment will use two separate hosts for Master Portal and Credential Store, or a single host. Fill in you machine hostname[s] into the hosts.inventory file accordingly. The hostname[s] set in the invertory files will be set on the target machine[s].

These scripts expect you to have a basic CentOS 6 or 7 installation ready. Since the two OS installations have slight differences between them (like repository addresses) we created two sets of default variables for each OS version. Once you decided which OS version you want to use, make sure to check the symlinks called roles/*/defaults/main.yml. These symlinks can either point to rh6.yml or to rh7.yml under the same directory in which they are. Set these according to the OS of your choice.

Roles

basic

The basic role tries to cover the general environment setup that is needed for both Master Portal and Credential Store.

credstore

masterportal

Plays

These ansible scripts include two play:

  • credstore.yml to deploy a Credential Store. This will apply the basic and the credstore roles.
  • masterportal.yml to deploy a Master Portal. This will apply the basic and the masterportal roles.

Delegation Server