Difference between revisions of "CILogon Pre-Pilot Work - Jenkins"
| Line 3: | Line 3: | ||
We used [[Jenkins Setup | Jenkins]] together with [[OpenStack Cluster | OpenStack]] to build an automatically deploying CILogon instance. Jenkins VM Image templates are used to boot VMs with relevant software installed on it, while separate Jenkins jobs are used to carry out different stages of the service deployment. The following sections contain a brief overview of the structure of these Jenkins jobs together with a short description of their function. You can find these jenkins jobs together with machine templates and some instructions on how to set up a Jenkins environment at [https://github.com/ttomttom/aarc-cilogon-pilot]. For more information consult the local [https://jenkins.nikhef.nl:8008/ jenkins instance](internal only). | We used [[Jenkins Setup | Jenkins]] together with [[OpenStack Cluster | OpenStack]] to build an automatically deploying CILogon instance. Jenkins VM Image templates are used to boot VMs with relevant software installed on it, while separate Jenkins jobs are used to carry out different stages of the service deployment. The following sections contain a brief overview of the structure of these Jenkins jobs together with a short description of their function. You can find these jenkins jobs together with machine templates and some instructions on how to set up a Jenkins environment at [https://github.com/ttomttom/aarc-cilogon-pilot]. For more information consult the local [https://jenkins.nikhef.nl:8008/ jenkins instance](internal only). | ||
| − | == | + | == Outcome == |
After experimenting with 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. | After experimenting with 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. | ||
| Line 16: | Line 16: | ||
See further [[RCauth_Delegation_Server_%26_MasterPortal_Ansible_scripts#General_Structure | RCauth Delegation Server & MasterPortal Ansible scripts]]. | See further [[RCauth_Delegation_Server_%26_MasterPortal_Ansible_scripts#General_Structure | RCauth Delegation Server & MasterPortal Ansible scripts]]. | ||
| + | |||
| + | The remainder of this page describes the Jenkins setup. | ||
= Demonstration Portal = | = Demonstration Portal = | ||
Revision as of 10:05, 3 September 2019
Introduction
We used Jenkins together with OpenStack to build an automatically deploying CILogon instance. Jenkins VM Image templates are used to boot VMs with relevant software installed on it, while separate Jenkins jobs are used to carry out different stages of the service deployment. The following sections contain a brief overview of the structure of these Jenkins jobs together with a short description of their function. You can find these jenkins jobs together with machine templates and some instructions on how to set up a Jenkins environment at [1]. For more information consult the local jenkins instance(internal only).
Outcome
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.
Our pick fell on Ansible mainly because of the following points:
- support for configuration templating
- easy to use modules to interact with systems
- no software required on target machine (runs through ssh)
- good documentation
- widely used
See further RCauth Delegation Server & MasterPortal Ansible scripts.
The remainder of this page describes the Jenkins setup.
Demonstration Portal
The Demonstration Portal is a simple oa4mp client running in a web container.
Note! The Demonstration Portal has to be registered at the Delegation Service before it can be used to retrieve certificates. To do so go to <delegation-service>/oauth2/register and fill in the client registration form. After clicking register you will be presented with a client id and secret which have to be entered into the Demonstration Portal configuration at /var/www/client/conf/cfg.xml.
.------
demonstration-portal ---| certificate-master.inject-hostcert
|
| Insert a host certificate/key pair into /etc/grid-security
|
| .------ .------
| oa4mp.client -----| prerequisites ---------------------------------------------------------| tomcat-ssl
| | |
| | Set up environment for OA4MP client. This job simply calls either | Sets up tomcat as a standalone container
| | tomcat-ssl or tomcat-httpd | serving SSL requests through port 8443
| | |
| | |
| | | tomcat-httpd
| | deploy |
| | | Sets up tomcat behind a httpd reverse proxy.
| | Dowloads the latest tagged version of oa4mp-client and copies the | In this case the httpd will take care of SSL.
| | client2.war into the tomcat webapps container | This setup is needed in case Shibboleth SP
| | | is to be used.
| | '------
| | configure
| |
| | Configure oa4mp client with a simple setup using file storage as backend.
| | Every relevant server information is kept under /usr/www/client. Since
| | this client has to be registered at the oa4mp-server some of the required
| | fields are left unconfigured: id and secret. These two fields are provided
| | upon registration and have to be filled in at /usr/www/client/conf/cfg.xml
| |
| |
| | restart
| '------
'------
Delegation Service
The Delegation Service is made up of a couple of major components: a myproxy-server, oa4mp server offering an oauth2 frontend to MyProxy, and a Shibboleth SP. Together these components can issue certificates to authenticated users.
The following figure describes the Jenkins jobs used to deploy the Delegation Service:
.------
delegation-service ----| certificate-master.inject-hostcert
|
| Insert a host certificate/key pair into /etc/grid-security
|
| .------
| myproxy-server -----| simple-ca
| |
| | This task sets up the myproxy-server as a Certificate Authority using
| | SimpleCA. The new CA is created using 'grid-ca-create'. MyProxy uses
| | the myproxy-certificate-mapapp script to create user DNs by inserting
| | their username into the certificate subject
| |
| |
| | restart
| '------
|
| .------ .------
| oa4mp.server -----| prerequisites ---------------------------------------------------------| tomcat-ssl
| | |
| | Set up environment for OA4MP server. This includes setting up the | Sets up tomcat as a standalone container
| | tomcat container (by calling either tomcat-ssl or tomacat-httpd), | serving SSL requests through port 8443
| | and installing dependencies (java mail, jglobus) |
| | |
| | | tomcat-httpd
| | deploy |
| | | Sets up tomcat behind a httpd reverse proxy.
| | Dowloads the latest tagged version of oa4mp-server and copies the | In this case the httpd will take care of SSL.
| | oauth2.war into the tomcat webapps container | This setup is needed in case Shibboleth SP
| | | is to be used.
| | '------
| | configure
| |
| | Configure oa4mp server with a simple setup using file storage as backend.
| | Every relevant server information is kept under /usr/www/server
| |
| |
| | restart
| '------
|
| .------
| shibboleth.sp -----| setup
| |
| | Sets up the Shibboleth SP to forward unauthenticated requests to the
| | /oauth2/authorize endpoint to the Shibboleth IdP. Downloads and configures
| | the Shibboleth IdP metadata, and adds a set of expected attributes
| | (uid,cn,mail)
| |
| |
| | restart
| '------
|
|
| shibboleth.idp.register-metadata
|
| Dowloads the SP Metadata into the Shibboleth IdP and registeres it.
'------
oa4mp.server.approve-clients
Automatically approves every pending client registration request.
Shibboleth IdP
We used a machine template configured with Shibboleth IdP v3 and Tomcat 7. The machine template installs both shibboleth IdP and tomcat in their default location and takes care of having the right environmental variables set. The jobs used below are meant to be used with this template to further configure the IdP.
.------
shibboleth.idp ---| shibboleth.idp.setup
|
| This task is meant to install and configure an unpacked shibboleth IdP:
|
| Runs the shibboleth installation script and configures the right tomcat environment.
|
| It creates a hostcert/hostkey pair and configures tomcat to use this for enabling
| SSL on port 443.
|
| Configure shibboleth attribute release (attribute-release.xml) with a set of attributes
| definitions (eduPersonPrincipalName,uid,cn,mail)
|
| Configure shibboleth attribute filter (attribute-filter.xml) to release the attributes
| defined above to any SP.
|
|
|
| ldap.setup
|
| Configures LDAP to be used as backend for the IdP by filling in the shibboleth LDAP
| configuration file (ldap.properties)
|
| Loads relevant LDAP schemas (including eduPerson 201310)
|
|
|
| ldap.add-user
|
| Adds a dummy user account for testing into LDAP. Makes sure that the dummy account has every
| relevant field which is required later on by the shibboleth attribute-releas.xml (uid,cn,mail)
|
|
|
| shibboleth.idp.restart
|
| Restarts the shibboleth IdP service container (tomcat)
'------
shibboleth.idp.register-metadata
Automatically discover the Shibboleth SP running insinde Jenkins and registers its metadata
