Versions Compared

Old Version 2

changes.mady.by.user John Schneider

Saved on

compared with

New Version 3

changes.mady.by.user John Schneider

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.


Excerpt

This page describes the rules all containers deployed on the infrastructure must apply to.


If the delivered component violate any of the demands below the component will be rejected.

Table of Contents

1. Docker Image

  1. Must build upon one of the predefined predefined eHealth docker base images (Docker Base Images)
  2. The applications in the container must run as non-root  (Docker Base Images Security)
  3. The docker image that is pushed to the central docker image repository must be signed with an approved private key. (Image Signing)

...

  1. Headers used for authentication and authorization must be set
  2. B3 header propagation
    1. Tracing headers must be propagated as described in https://istio.io/docs/tasks/telemetry/distributed-tracing/.
    2. This can be handled by libraries like https://github.com/jaegertracing/jaeger-client-java
  3. Applications accessing the infrastructure are encouraged to expose their application identity by using the HTTP Header User Agent, eg: User agent : HAPI-FHIR/4.1.0 (FHIR Client; FHIR 3.0.2/DSTU3; apache) or User agent : CGI-CC360-COPD/1.0.3. This information can then in the future be used to provide proper redirects.

5. Logging requirements

  1. Follow the specification for the application log (Logging model)
  2. Errors and essential incident must be found in the application log

...

  1. Application must be deployed using one of the official ehealth eHealth helm charts available here: https://registry.admin.ehealth.sundhed.dk/harbor/projects/5/helm-charts
    1. See Helm Charts
  2. Application must be deployed using the most recent version of the helm chart.

...

  1. Documentation of the components purpose, service requirements and resource usage

9. Rollout plan

  1. Every release must follow a strict release plan where all four FUT environment are visited in the show order.

      ...

        1. Internal test  →

      ...

        1. external test → pre-production → production
      2. New releases must be able to coexist with the previous version.
      3. Rollback must always be possible. A new release must never have contradictory demands with the previous version.
      4. The system runs 24/7 meaning that service windows with down time is not an option.