...
...
...
...
...
...
...
...
...
...
...
...
...
...
| Excerpt |
|---|
This page describes the rules all containers deployed on the infrastructure must apply to. |
If the delivered component violates 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 incidents must be found in the application log
...
Every release must follow a strict release plan where all four eHealth Environments (see Environments ) 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.