Suggestion: refactor to use Galleon

Wildfly now has features such as the Keycloak SAML Adapter which are only available as Galleon layers (see https://docs.wildfly.org/32/WildFly_Elytron_Security.html#Keycloak_SAML_Integration). As it is not possible to install a Galleon layer on a Wildfly that was not provisioned using Galleon the current docker images are not a useful starting point.

If these Dockerfiles moved to something like:

# Add the WildFly distribution to /opt, and make wildfly the owner of the extracted tar content
# Make sure the distribution is available from a well-known place
RUN cd $HOME \
    && curl -L -O https://github.com/wildfly/galleon/releases/download/$GALLEON_VERSION/galleon-$GALLEON_VERSION.zip \
    && unzip galleon-$GALLEON_VERSION.zip
    && ./galleon-$GALLEON_VERSION/bin/galleon.sh install wildfly-ee:current#$WILDFLY_VERSION --dir=wildfly-$WILDFLY_VERSION \

but probably provisioning directly into /opt/jboss/wildfly it would be possible to extend them and add layers with:

RUN  ./galleon-$GALLEON_VERSION/bin/galleon.sh install org.keycloak:keycloak-saml-adapter-galleon-pack:$KEYCLOAK_VERSION --layers=keycloak-client-saml --dir=wildfly-$WILDFLY_VERSION

[jmesnil]

@jellisgwn Thanks for the report, I think that'd be a great enhancement to our Docker images.

The good news is that the Docker image contains a WildFly server that is already "Galleon-ready".
You can use Galleon to add Galleon layers to it directly from your image .

As an example, I've created a custom image on top of it based on this Dockerfile:

FROM quay.io/wildfly/wildfly

ENV GALLEON_HOME=/opt/jboss/galleon

# Install Galleon in /opt/jboss/galleon
USER root
ENV GALLEON_VERSION=6.0.3.Final
RUN microdnf install unzip -y \
    && cd /opt/jboss/ \
    && curl -L -O https://github.com/wildfly/galleon/releases/download/$GALLEON_VERSION/galleon-$GALLEON_VERSION.zip \
    && unzip galleon-$GALLEON_VERSION.zip \
    && mv galleon-$GALLEON_VERSION galleon \
    && rm galleon-$GALLEON_VERSION.zip \
    && mkdir /opt/jboss/.m2 \
    && chown -R jboss:0 /opt/jboss/ \
    && chmod -R g+rw /opt/jboss/

# Use galleon to provision the Keycloak SAML Adapter
USER jboss
ENV KEYCLOAK_VERSION=26.0.0
RUN ${GALLEON_HOME}/bin/galleon.sh install \
        org.keycloak:keycloak-saml-adapter-galleon-pack:$KEYCLOAK_VERSION \
        --layers=keycloak-client-saml \
        --dir=$JBOSS_HOME \
    && rm -rf $HOME/.m2/repository

I split the RUN instructions in 2 as the first one to install Galleon really belongs in the quay.io/wildfly/wildfly base image as you suggest.

When it'll be done, your Dockerfile could be as simple as:

FROM quay.io/wildfly/wildfly

ENV KEYCLOAK_VERSION=26.0.0
RUN ${GALLEON_HOME}/bin/galleon.sh install \
        org.keycloak:keycloak-saml-adapter-galleon-pack:$KEYCLOAK_VERSION \
        --layers=keycloak-client-saml \
        --dir=$JBOSS_HOME \
    && rm -rf $HOME/.m2/repository

# ADD your deployments

Please tell me if this solution (and the proposed workaround) would work for you and I can open a PR to add Galleon to the quay.io/wildfly/wildfly images.

Thanks!

@jmesnil thanks! i'll try this and get back to you.

my previous attempts to apply galleon layers to the downloaded wildfly bundle failed, but i'll need to retry that experiment now to see why it was failing. my recollection is that the error message was quite clear that it wasn't possible. lets see what i missed.

[jmesnil]

As an aside, if you want the full power of provisioning WildFly with Galleon, an alternative is to use our builder and runtime images.

You could achieve the same results as above with the following config.

• a galleon/provisioning.xml that contains all feature packs and layers to provision:

<?xml version="1.0" ?>

<installation xmlns="urn:jboss:galleon:provisioning:3.0">
    <feature-pack location="org.wildfly:wildfly-galleon-pack:33.0.0.Final" />
    <feature-pack location="org.wildfly.cloud:wildfly-cloud-galleon-pack:7.0.2.Final" />
    <feature-pack location="org.keycloak:keycloak-saml-adapter-galleon-pack:26.0.0">
    </feature-pack>
    <config model="standalone" name="standalone.xml">
        <layers>
            <include name="keycloak-client-saml"/>
        </layers>
    </config>
</installation>

• a Dockerfile that is based on quay.io/wildfly/wildfly-s2i and quay.io/wildfly/wildfly-runtime base images:

FROM quay.io/wildfly/wildfly-s2i AS BUILDER
ENV GALLEON_USE_LOCAL_FILE true
RUN mkdir -p /tmp/src
COPY --chown=jboss:root galleon /tmp/src/galleon
# Run the assemble script to provision the server.
RUN /usr/local/s2i/assemble


FROM quay.io/wildfly/wildfly-runtime AS RUNTIME

COPY --from=BUILDER --chown=jboss:root $JBOSS_HOME $JBOSS_HOME

# ADD your deployments

@jmesnil your initial answer looks to be working, but leaves me with an image that is twice the size. is that unavoidable?

[jmesnil]

You're right, the galleon provision of the SAML adapter is touching the WildFly installation. That means that the image has 2 layers with WildFly bits (hence twice the size).
That's an unfortunate side effect of provisioning the installation in 2 steps. If you compare that with the builder/runtime approach where provisioning is done in a single step, the image is more efficient at preserving space.

tried a similar approach using COPY --from= and was able to shrink the image a little, but not down to the hoped for size of the original + size of the adapter.

will look at the builder + runtime approach next.

back to this and determined that the initial approach fits our immediate requirements.

having galleon available in the base image would be good simplification.