You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

Statement

All Docker containers created or maintained by TIER are built to the specifications described in this document.  We have tried to limit the requirements to the 

Background

In order to facilitate support, TIER has made decisions throughout the course of the project to standardize on certain sub-components and more recently to ensure that TIER containers are compatible with our default orchestration strategy of using Docker Swarm mode via Compose.  

Specification

  1. Base Linux Image
    1. Centos 7
      1. Standard maintained Centos 7 image
      2. (Under Discussion) potential use of Centos 7 image from Dockerhub that includes what is needed to use systemd as init (instead of supervisord).  We may enable this option is optaining/implementing the logging changes we need to supervisord are hard - - https://hub.docker.com/r/centos/systemd/
  2. Servlet Engine
    1. Tomcat will be used whenever a servlet engine is needed.
  3. Java Distribution
    1. Oracle's Java distribution will be used whenever Java is needed.
  4. Database
    1. If a relational database is provided, MARIADB will be used.
  5. Multi-Process Container
    1. Supervisord will be used whenever a container needs more than one process.
  6. Container Configuration
    1. Standard Data
      1. Containers may receive configuration data via the environment as described below for Secret Data (6.b)
      2. Configuration data may be mounted into the container from external storage
      3. Configuration data may be "burned" into the container while it is being built.
      4. There are many trade-offs between ii and iii, some environments will choose to enable the end user to build their containers using either method.
    2. Secret Data
      1. The preferred mechanism to support data that must be protected (e.g., passwords, keys, etc.) is Swam-mode Docker Secrets.
      2. Secrets/Pointers-to-Secrets are passed in the environment using the syntax described below.  Either a single value may be supplied or, with the _FILE suffix, a file pointing to a docker swarm secret location 
        1. COMPONENT_DATABASE_PASSWORD=foobar
        2. COMPONENT_DATABASE_PASSWORD_FILE=/run/secrets/my_password_file
      3. Container startup scripts
        1. Start-up scripts process the environment and do whatever setup is needed to make secrets usable in the application.
        2. If the environment contains both a _FILE and name-only variables, the _FILE form is to be used.
  7. Container Orchestration
    1. Containers designed for compatibility/ease of use with Docker SWARM mode using Docker Stack Deploy and Compose files.
    2. Work to not preclude the use of other orchestration frameworks.
    3. Secrets are automatically mounted in /run/secrets by docker stack deploy using a compose file.
  8. Logging
    1. All logs from all elements within a container are written to stdout
    2. Goal: easily parsable records; future - potential json
    3. Lines (records) within each log file start with the following format

      1. Component Name (e.g., Shibboleth IdP, Grouper Loader, etc.)

      2. Native logfile name (e.g., Catalina.out, shibd.log, etc.)

      3. Environment (e.g., Prod, Dev, Test)

      4. A user supplied token via the environment

    4. Deployers will use the --log-opt tag
      1. https://docs.docker.com/config/containers/logging/log_tags/
      2. This element can manage (a), (c), and (d) above.
    5. Logfile Format Known Issues
      1. Supervisord - we are presently unable to change the supervisord logfile format, a requested change is in progress.
      2. Grouper and Shibboleth IdP - Tomcat log format issues
  9. Other Specifications
    1. ...
    2. ...
    3. ...


  • No labels