Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Suggestion: refactor to use Galleon #226

Open
jellisgwn opened this issue Oct 8, 2024 · 7 comments
Open

Suggestion: refactor to use Galleon #226

jellisgwn opened this issue Oct 8, 2024 · 7 comments

Comments

@jellisgwn
Copy link

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
Copy link
Contributor

jmesnil commented Oct 8, 2024

@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!

@jellisgwn
Copy link
Author

@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
Copy link
Contributor

jmesnil commented Oct 8, 2024

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

@jellisgwn
Copy link
Author

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

@jmesnil
Copy link
Contributor

jmesnil commented Oct 9, 2024

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.

@jellisgwn
Copy link
Author

jellisgwn commented Oct 10, 2024

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.

@jellisgwn
Copy link
Author

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

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants