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

Compare with Current View Page History

Version 1 Next »

Statement

All containers created or maintained by TIER are built to the specifications described in this document.

Background

TIER has made decisions throughout the course of the project to standardize on certain sub-components and 

  1. Compatibility/ease of use with SWARM while not breaking other options.

  2. Base Image - Centos 7 - one of:

    1. Standard Centos 7 image we have been using with the addition of supervisord when needed

    2. Centos 7 image from Dockerhub that includes what is needed to use systemd as init (instead of supervisord)

      1. https://hub.docker.com/r/centos/systemd/

  3. Secret Processing

    1. Assume secrets are mounted in /run/secrets (to support compose in swarm)

    2. Secret Availability - in-container startup script behavior

      1. Accept the secret in the environment, e.g.,

COMPONENT_DATABASE_PASSWORD=foobar

    1. If the filename version of the name exists, prefer it:
      COMPONENT_DATABASE_PASSWORD_FILE=/var/run/secrets/some_file

    2. If both exist, prefer the FILE option a

  1. Logging

    1. All containers log to stdout

    2. Goal - easily parsable logs for:

      1. Component Name

      2. Native logfile name

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

      4. A user supplied token via the environment

    3. We will have deployers use the --log-opt tag

      1. https://docs.docker.com/config/containers/logging/log_tags/

      2. This solution solves items 3.iii.2.a, 3.iii.2.c, and 3.iii.2.d

    4. To solve 3.iii.2.b, we need an inventory of components where we are unable to change logfile format.  Components with a single logfile per container should be OK and not need remediation.

      1. Supervisord

        1. Issue: can not change format of logfile to prepend “supervisord.log”.

        2. Looked at potential for external process to transform log format before writing to stdout but prefer not to use this mechanism due to added complexity

        3. Scott did some digging

          1. No good news - a source code change is needed

          2. The code is python but they do not use python logging

          3. [AI] Scott will ask about possibility for a feature update

      2. Mariadb - should be OK, single logfile per container

      3. OpenLDAP - should be OK, single logfile per container

      4. COmanage (yet--this could become a requirement for upstream)

      5. Shibboleth idp

        1. Shibboleth itself OK via log4j

        2. Catalina.out tomcat issues

      6. Grouper

        1. Core grouper logging will be ok

        2. Same issues with Supervisord and tomcat

  • No labels