Core Component Packaging Strategy

 February 8, 2016 Proposal Discussion

 

One of the major goals of the TIER Packaging Working Group is to select a component packaging strategy that meets the needs of the TIER user community, supports the initial TIER components (Shibboleth, Grouper, and CoManage), and lays the foundation for packaging newer TIER components as they become part of the TIER portfolio.

We discussed a Docker container-centric approach on our January 25, 2016 call along with proposing the use of tooling ( Packer and Jenkins ) to enable us to create multiple package formats and potentially hedge our bet on Docker as the long-term solution.  This page briefly describes the rational for this solution and starts the discussion on precisely what is needed.

 

Comfort with Docker Containers - TIER Packaging Survey Data Our survey (see Figure at right) showed a low level of comfort with Docker containers now but also displayed a growing expectation that campus use of Docker would grow over the timeframe of TIER development. Using a Docker-centric approach now likely means that TIER will need to provide both the containers themselves and a preconfigured run environment so that campuses don’t need Docker expertise to deploy TIER components.  Campuses could then choose to treat the Docker containers much the way that many do now with the code for the components – as black boxes.  While the proposed tooling can produce multiple output formats, we propose to keep the number of types of packages to the absolute minimum possible, especially early in the TIER project.  The goal is to not build expectations and thus maintenance headaches for too many package types.

 

Proposed Solution

Overall System

  1. TIER components will be packaged into Docker containers based on CentOS Linux.

    1. Each component will be packaged into a separate container.
    2. The packaging process will run on a weekly basis with a person performing a QA function after automated testing and before new containers are released.
    3. The assumption is that the TIER component teams will continue their current test cycles before releases.
    4. An out of cycle update is possible for major security fixes.

  2. TIER will also provide preconfigured CoreOS virtual machine image(s)

    1. Images for some (small) set of set of hypervisors to run the TIER Docker containers.

    2. Enables users to treat the container infrastructure like a black box.
    3. CoreOS will be left configured for its default of auto-updating.
    4. New CoreOS VM image(s) will also be created as appropriate but no more than weekly
    5. With CoreOS auto-updating, sites do not need to install the new VM image on a weekly basis.  Sites simply need to update their component containers on a regular basis.
    6. An out of cycle update is possible for major security issues

  3. Tooling (Jenkins and Packer) will be used to:

    1. Automate builds
    2. Automate tests

Supported Execution Environments for CoreOS Machine Image

  1. VMWare
  2. AWS?
  3. Hyper-V?
  4. Virtual Box?

Build Support Reminders

  1. Load Balancing
  2. Separation of configuration data from containers & deployment methods
  3. Log management & access
  4. ...
  5. ...
  6. ...

Other

  1. ..
  2. ..
  3. ...

Proposed Workflow(s)

TIER components build their artifacts however they want; TIER takes those artifacts and packages them into packages (RPM, and DEB?), Docker container images (and Amazon Machine Images?), then bundles those into a single VM image (VMware, AMI, VirtualBox, Vagrant?, HyperV?).

 

 

  • No labels