| 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
...
- Headers used for authentication and authorization must be set
- B3 header propagation
- Tracing headers must be propagated as described in https://istio.io/docs/tasks/telemetry/distributed-tracing/.
- This can be handled by libraries like https://github.com/jaegertracing/jaeger-client-java
- 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
- Follow the specification for the application log (Logging model)
- Errors and essential incident must be found in the application log
...
- Every release must follow a strict release plan where all four FUT environment are visited in the show order.
- Internal test → external test → pre-production → production
- New releases must be able to coexist with the previous version.
- Rollback must always be possible. A new release must never have contradictory demands with the previous version.
- The system runs 24/7 meaning that service windows with down time is not an option.