OpenShift provisioning #49
Description
WildFly Glow CLI should allow to directly deploy the scanned application onto OpenShift.
Introduce a new OPENSHIFT kind of deployment.
The workflow
- User connects to an OpenShift Cluster (e.g.: OpenShift sandbox)
- User install oc command line to be allowed to log to the cluster.
- User calls oc login ...
- At this point WildFly Glow can create a BuildConfig, sending it the scanned war and discovered provisioning configuration. Oncee the build is done, a Deployment, Service and Route are created.
- WildFly Glow displays the Route to the Deployment.
Smart build of the Application image
We have the opportunity to create an efficient build by provisioning the server only once for a given set of layers/feature-packs.
The image build is split in 2 phases:
- Build the image containing the server, cache it, key being SHA of WildFly Glow generated provisioning.xml.
- Build the application image from the wildfly-runtime image. Copy the server from the cached server image. Copy the deployments and optional initialization script.
Note: The server image build is only executed if no image is already present in the cache.
Support for Database and Remote Messaging
In such case, there should be zero configuration required to have the application to attach to a Database or a Messaging Broker.
- When postgresql addon is enabled , a postgreSQL service should be created, deployed, and the Application deployment should be bound to it (credentials, host/port, ...).
- When mariadb addon is enabled , a mariadb service should be created, deployed, and the Application deployment should be bound to it (credentials, host/port, ...).
- When mysql addon is enabled , a mysql service should be created, deployed, and the Application deployment should be bound to it (credentials, host/port, ...).
- When cloud-remote-messaging addon is enabled , an Artemis Broker service should be created, deployed, and the Application deployment should be bound to it (credentials, host/port, ...).
Support for Keycloak
When elytron-oidc-client layer is discovered, a keycloak instance is started. It is then expected that some actions are taken from the keycloak admin console.
The keycloak admin console route and credentials are printed to the user with the list of steps to follow.
WildFly Glow will also set all the required env variables allowing the deployment to connect to OIDC provider.
Extending the Deployment with some more environment variables
One should be able to provide a file containing a list of env variables + values i norder to enrich the application deployment environment (e.g.: To create topic/Queues, ...).
Note that all environment variables set in the deployment (from the deployers and the user provided ones) are advertised by WildFly Glow.
Generation of yaml files
All the yaml resources files are stored in the server-<wildfly version> directory.
Disabling deployers
The deployers should be skip by the mean of options. By default deployers are enabled. When the deployers are disabled, some env variables are still injected into the deployment, Values being the description of the expected value. These values are to be updated manually in the deployement according to the OpenShift cluster context.
Support for HA profile
- Multiple instances
- DNS_PING protocol enabled in the deployment
- Creation of the headless service to allow for member discovery
- Use StatefulSet instead of Deployment
Fine tuning the provisioned server
On Openshift, we could have a need to fine tune the server running in the cluster.
For some advanced cases, it should be possible to provide a bash script file to fine tune the server (add user, call CLI commands. Example of such script:
$JBOSS_HOME/bin/add-user.sh -a -u quickstartUser -p quickstartPwd1! -g guest
# ${CLI_SCRIPT_FILE} is the script that will get executed at server boot.
echo "/subsystem=logging/logger=org.wildfly.security:add(level=ALL,handlers=[CONSOLE])" >> ${CLI_SCRIPT_FILE}
In addition a user should be able to provide a CLI script file containing only CLI commands to be executed. Example of such file:
/system-property=foo:add(value=foo)
/subsystem=logging/logger=org.xnio:add(level=ALL,handlers=[CONSOLE])
Injecting the route in the deployment
We have the opportunity to know in advance the route that will get exposed. It can be of interest to configure the server (a remote socket binding accessible from outside the cluster).
This is done by the mean of the env variable: APPLICATION_ROUTE_HOST
Stability handling
The SERVER_ARGS=--stability=<stability level> env variable is automatically set if a stability level has been specified.