More granularity in dockerisation

[tom-schier]

Is your feature request related to a problem? Please describe.
Yes. The only public ACCC container (ie on docker hub) with gateways is the mock-data-holder. If a custom data holder (eg NodeJS implementation) is developed the gateways need to be deployed independently of the mock-data-holder image. While the authorisation-server has the gateways as part of the solution, no public container image exists for authorisation server with gateways.

Describe the solution you'd like
A container image which deploys the gateways independently of mock-data-holder implementation.

Describe alternatives you've considered
You could create a public docker image bundling authorisation server and gateways, or create individual images for authorisation server and gateways.
The latter implementation is addressed in #9

Additional context
Currently gateways are part of the mock-data-holder as well as the authorisation-server. They seem to be almost identical, so maybe code duplication?

[CDR-AndrewG]

Hi @tom-schier,

Thank you for logging this request.

We have a dockerfile that will build the docker image including the gateways in the build and start up processes. If that dockerfile suits your needs, we can publish a copy to Docker Hub as part of our build and publish process.

Let us know if publishing the image will help.

The below commands can be used to build and start the image.

docker build -t authorisation-server .

docker run -d -e "ACCEPT_EULA=Y" -e "SA_PASSWORD=Pa{}w0rd2019" -p 1433:1433 --name mssql -h sql1 -d mcr.microsoft.com/mssql/server:2019-latest

docker run -d -h authorisation-server -p 8001:8001 -p 3000:3000 --add-host=mssql:host-gateway --name authorisation-server authorisation-server

[tom-schier]

That image would certainly help other participants, and work with particular architectures.
However, the solution in the PR #9 provides even more granularity, and it useful when the gateways need to be independent of any other services. That is the solution the DSB has used in the implementation of the NodeJS test server.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[cdr-mustafa]

Hi @tom-schier

TLS and MTLS gateways are tightly coupled with the authorisation-server and serve routing to the authorisation-server on specific hostnames and ports in a local development environment.
Moving TLS and MTLS gateways out into their own container images might not benefit the community. Additionally, it will require the community to design and configure their auth server implementation in a specific way that aligns with these TLS and MTLS gateways.

[JamesMBligh]

@cdr-mustafa, I believe Tomas created this PR specifically because we were trying to use the mock authorisation server as it was intended but we were using our own resource server in a separate Docker container. The DSB has two separate resource servers, one in Java and one in NodeJS, and we wanted to test them in conjunction with the mock authorisation server.

In this scenario both the authorisation and resource servers need to sit behind the TLS/MTLS gateway.

Could you advise how we could achieve this without the PR changes or possibly amendments to the PR to allow both a combined container and decomposed container model to work?

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[cdr-mustafa]

@JamesMBligh Just wanted to clarify when we are talking about test, is it testing in the local development environment or in Kubernetes?

In Local development environment, you want to add two resources API and test them in conjunction with Auth Server. Auth Server is running on localhost:8001. The TLS/MTLS gateway configuration for the CDR Auth Server uses the same downstream host and port for each defined route. Splitting the TLS/MTLS gateways into separate container instances will not allow you to use your own resource server, as the gateway will still be routed to the same downstream location (localhost:8001). There will be modifications required to TLS/MTLS gateways to support resource servers operating on different host/port and will have to add CDR data holder resource APIs. Therefore, to cater for a "bring your own resource server" scenario, it is advised that users construct their own gateways, that aligns with their own implementations with full control over the route configuration (host/port).
If you already have your own TLS/MTLS gateways and you want to include the Auth Server alongside your resource server, then you can use the Auth Server in "standalone" mode using Docker file.

When you are deploying your solution in Kubernetes, you can use Nginx ingress controller or Application gateway ingress controller to route your request to multiple resource API servers.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.