4:59 p.m.
Looking at the feedback in the questionare, there are several requests to make
provisioning and configuration of KC deployments easier.
I was also thinking about this in relation to our testsuite for a while, and whether there
should be a separate module for this. Either inside the testsuite module, or possibly even
in the projecr root - in case we want it to be usable both by the testsuite (via API) and
manually, by people who want to deploy Keycloak and other interacting sevices somewhere in
their cloud or kubernetes/openshift cluster.
Another option would be to create an entirely separate project (akin to
jboss-dockerfiles/keycloak [1] or the Kubernetes Helm project [2]) which could even
support multiple versions of Keycloak and other components. Perhaps some install/upgrade
wizzards and examples could be put there. Not sure how an external project would be usable
with the testsuite though. The question is to what extent these two use cases are even
compatible (devops/maintenance vs extensive integration testing). Benefit of combining
both use cases would be reusing common stuff (DRY).
In the testsuite we currently use 2 different solutions:
1) Integration testsuite uses Maven/Ant/JBossCLI to prepare configurations on local FS and
then manages lifecycle of all components through Arquillian. Additionally there are
testsuite-specific server extensions and custom test apps.
2) Performance testsuite uses Maven/Ant/JBossCLI to prepare configurations on local FS and
then uses Docker Compose to build and orchestrate the services. The tests then run against
a "remote" provisioned system.
There is also a PR from Radim Vansa who created a provisioning solution for OpenShift a
while ago, which I have yet to review and merge.
And we need to add some bare-metal provisioning option for testing in bare-metal labs
(probably ansible).
I think all of these different solutions could be put under one roof.
Maybe something like this:
keycloak/
...
core/
adapters/
model/
examples/
...
distribution/
provisioning/
provisioning-api/
provisioner-local/
provisioner-docker/
provisioner-openshift/
provisioner-ansible/
...
testsuite/
integration/
performance/
Or like this, if just inside the testsuite:
keycloak/
...
testsuite/
provisioning/
integration/
performance/
The provisioning API would have a simple interface:
interface Provisioner {
List<String> getConfiguredServices();
void buildService(String service);
void startService(String service);
void stopService(String service);
}
Particular provisioner module would the look something like this:
provisioner-X/
src/main/
java/.../ProvisionerX.java (wrapper for external provisioning tool or API)
resources/... (for exmple jboss-cli scripts, dockerfiles, ansible
playbooks, etc.)
pom.xml/<profiles>/
server
server-db-vendor-1
server-db-vendor-2
...
server-ldap-vendor-1
server-ldap-vendor-2
...
server-cache
server-load-balancer
client-set-1
client-set-2
client-set-3
...
webdriver-vendor-1/
webdriver-vendor-2/
...
The process would consist of:
1) Configuring required provisioner modules:
- user provides connection parameters and credentials if needed (kubernetes/openshift,
ssh keys for anisble, etc.)
- user provides configuration parameters for services
2) Building required provisioner modules:
- building provisioning module will prepare all local artifacts which will be needed for
running methods of the Provisioner interface
- after module is built the provisioner implementation/wrapper will be runnable directly
with Java or indirectly from script (this would be useful the dev-ops scenario)
- also the external provisioning tool (such as docker-compose or ansible) will be
runnable directly at this point
3) Running the testsuite. The testsuite delegates to the API to spin up or tear down the
services as needed.
The integration testsuite would default to the `provisioner-local` module which would just
contain stuff which is now located in: testsuite/integration-arquillian/servers.
But it could be instructed to use a different provisioning module(s).
It would be nice if individual services or sets of services could be combined across
different provisioners, and if this would also allow for integration of externally
provided services such as existing DB servers.
That's the general idea. I've brought this up once before but it was never a
priority. Maybe it's time to consider it again and let everyone chip in with their
ideas.
I think this consolidation would be useful at least within the testsuite. It is also kind
of related to the microservice-oriented testing approach which I mentioned in my previous
post.
Regards,
Tomas
[1] https://github.com/jboss-dockerfiles/keycloak
[2] https://github.com/helm/charts/tree/master/stable/keycloak