Hoe bouw je een WSO2 APIM image op basis van RedHat UBI-Minimal in OpenShift

APIs zijn de levensader van moderne applicaties en het effectief beheren ervan is cruciaal. WSO2 API Manager (APIM) komt naar voren als een krachtig hulpmiddel voor het maken, publiceren en beveiligen van je API’s. Maar hoe benut je het volledige potentieel in een containerized omgeving zoals OpenShift?

Sommige bedrijven hebben beleidsregels die vereisen dat RedHat UBI-minimal wordt gebruikt als basisafbeelding voor het maken van nieuwe afbeeldingen. Wat zijn de voor- en nadelen? Hoe pas je de standaard WSO2 APIM Docker-bestanden aan om compatibel te zijn met ubi-minimal?

Deze blog verkent het proces van het bouwen en implementeren van WSO2 APIM-afbeeldingen in OpenShift met de UBI-minimal basisafbeelding, zodat je je API’s met flexibiliteit en precisie kunt beheren.

Wat is RedHat UBI-Minimal

RedHat UBI-minimal is een lichte containerbasisafbeelding die zich richt op minimale grootte en beveiliging. Gebouwd door RedHat, is het vrij herdistribueerbaar, maar de ondersteuning is beperkt tot de kernfunctionaliteit. Het maakt gebruik van microdnf voor pakketbeheer en is ideaal voor kleinere implementaties waarbij grootte en beveiliging prioriteit hebben.

Of het “beter” is om RedHat UBI-minimal als basisafbeelding te gebruiken voor de implementatie van WSO2 APIM in OpenShift hangt af van je specifieke behoeften en prioriteiten. Hier is een opsomming van de voor- en nadelen om je te helpen beslissen:

• Voordelen van het gebruik van ubi-minimal:
  • Kleinere afbeeldingsgrootte: ubi-minimal is een minimalistische afbeelding met alleen de essentiële componenten, wat resulteert in een kleinere voetafdruk en snellere implementatietijden.
  • Beveiligingsfocus: Red Hat onderhoudt en werkt ubi-minimal bij met beveiligingspatches, wat de algehele beveiligingspositie van je implementatie kan verbeteren.
  • Vrij herdistribueerbaar: Je kunt ubi-minimal-afbeeldingen vrij delen en hergebruiken zonder licentiebeperkingen, wat belangrijk kan zijn voor open-sourceprojecten of samenwerkingsomgevingen.

• Nadelen van het gebruik van ubi-minimal:
  • Beperkte functionaliteit: Omdat ubi-minimal een minimalistische afbeelding is, kan het functionaliteiten missen die WSO2 APIM vereist, waardoor je tijdens de implementatie extra pakketten moet installeren.
  • Pakketbeheer: Hoewel ubi-minimal microdnf gebruikt, een lichte pakketbeheerder, kan dit verschillen van je favoriete beheertools, wat mogelijk extra configuratiestappen vereist.
  • Ondersteuning: Red Hat ondersteunt alleen Red Hat-technologieën binnen een abonnement. Voor bredere ondersteuning, buiten de kernfunctionaliteit, moet je mogelijk alternatieve oplossingen onderzoeken.

Op basis van de voordelen van UBI-minimal en beleidsregels binnen je organisatie, kan het nodig zijn om het als basisafbeelding te gebruiken en je eigen Dockerfile op basis van RedHat UBI-minimal te creëren.

Algemeen WSO2 APIM Dockerfile

In deze sectie wordt een voorbeeld van een Docker-bestand getoond. Je kunt dit aanpassen of bibliotheken of apps toevoegen die je nodig hebt. In “ubi-minimal” kun je “microdnf” gebruiken om de benodigde pakketten te installeren. Vervolgens moet je WSO2 APIM 4.3 of een andere versie die je nodig hebt, downloaden. Je kunt het rechtstreeks downloaden van het repositorybeheer van je organisatie tijdens het buildproces, door de voorbeeldcode te gebruiken die het downloadt van je Nexus-repository met de referentiesparameters op regel 21, of je kunt het kopiëren vanuit je lokale directory. Je kunt dit voorbeeld vinden in regel 22, die is gecommentarieerd.

Verwijder alle geïnstalleerde pakketten aan het einde om ongebruikte ruimte vrij te maken.

FROM registry.access.redhat.com/ubi9/ubi-minimal:latest
ARG WSO2_SERVER_NAME=wso2am
ARG WSO2_SERVER_VERSION
ARG WSO2_PATCH_LEVEL
ARG NEXUS_USERNAME
ARG NEXUS_PASSWORD
ARG WSO2_SERVER_DIST_URL
ARG WSO2_FULL_NAME=${WSO2_SERVER_VERSION}.${WSO2_PATCH_LEVEL}
ARG WSO2_BIN_NAME=apim-${WSO2_FULL_NAME}.zip
ARG APP_BASE_DIR=/opt
ARG WSO2_DIR_NAME=${WSO2_SERVER_NAME}-${WSO2_SERVER_VERSION}
ARG WSO2_SERVER_HOME=${APP_BASE_DIR}/${WSO2_DIR_NAME}
ARG JAVA_HOME=/opt/jre

ARG JAVA_CACERTS=${JAVA_HOME}/lib/security/cacerts
# destination WSO2 JKS stores
ARG WSO2_CLIENT_TRUSTSTORE_JKS=${WSO2_SERVER_HOME}/repository/resources/security/client-truststore.jks

LABEL maintainer="WSO2 Docker For RHEL <Afarin>"  \
      com.wso2.docker.source="https://github.com/wso2/docker-apim"
# Install required packages for unpacking WSO2 sourcen
RUN microdnf install --nodocs -y --setopt install_weak_deps=0 unzip findutils \
    && microdnf clean all

# download from nexus or copy WSO2 binary from local file system
RUN curl -u ${NEXUS_USERNAME}:${NEXUS_PASSWORD} -o ${APP_BASE_DIR}/${WSO2_BIN_NAME} ${WSO2_SERVER_DIST_URL}
# COPY --chown=root:root local/wso2_APIM_4.3.0.zip ${APP_BASE_DIR}/${WSO2_BIN_NAME}

# This Dockerfile command creates necessary directories, sets permissions, unzips wso2 zipfiles,
# and copies specific directories to the target location.
RUN mkdir -p \
        ${WSO2_SERVER_HOME} && \
    chown -R root:root ${WSO2_SERVER_HOME} && \
    unzip -d ${APP_BASE_DIR} ${APP_BASE_DIR}/${WSO2_BIN_NAME} && \
    rm -rf ${WSO2_SERVER_HOME}/dbscripts && \
    find ${WSO2_SERVER_HOME} -type f -exec chmod "u=rw,g=rw,o=rw" {} + && \
    find ${WSO2_SERVER_HOME} -type d -exec chmod "u=rwx,g=rwx,o=rwx" {} + && \
    find ${WSO2_SERVER_HOME} -name "*.sh" -type f -exec chmod "u+x,g+x" {} +

COPY --from=jenkins/jenkins:rhel-ubi9-jdk21 --chown=root:root /opt/java/openjdk/ ${JAVA_HOME}
COPY --chown=root:root local/docker-entrypoint.sh ${WSO2_SERVER_HOME}

RUN ${JAVA_HOME}/bin/keytool -importkeystore -srckeystore ${JAVA_CACERTS} -destkeystore ${WSO2_CLIENT_TRUSTSTORE_JKS} -srcstorepass changeit -deststorepass wso2carbon -v; exit 0

### Delete package manager stuff
RUN microdnf remove  -y unzip findutils \
    && microdnf clean all

RUN rm -fr /var/cache/* /var/lib/dnf /var/lib/rpm /var/lib/rpm-state /etc/yum.repos.d /etc/dnf

WORKDIR ${WSO2_SERVER_HOME}

ENV WORKING_DIRECTORY=${WSO2_SERVER_HOME} \
    WSO2_SERVER_HOME=${WSO2_SERVER_HOME} \
    JAVA_HOME=${JAVA_HOME} \
    WSO2_APIM_VERSION=${WSO2_FULL_NAME}
ENTRYPOINT ["${WSO2_SERVER_HOME}/docker-entrypoint.sh"]
EXPOSE 5672 8672 8280 8243 9099 9443 9611 9711 9763 9999 11111

Geoptimaliseerde WSO2 APIM op basis van profiel

Als je van plan bent om WSO2 APIM op een gedistribueerde manier te installeren, is het beter om afzonderlijke afbeeldingen op basis van profielen te hebben. Zoals je weet, kun je de Gateway scheiden van het Control Plane, waarna je twee componenten hebt.

Je kunt zelfs de Gateway en de Traffic-manager scheiden, waarna je drie componenten hebt. Je kunt deze link volgen om een gedistribueerde omgeving op te zetten, maar dat valt buiten dit blogonderwerp.

Door de onderstaande code uit te voeren, kun je je APIM optimaliseren voor een specifiek profiel.

sh <API-M_HOME>/bin/profileSetup.sh  -Dprofile=<preferred-profile>

De onderstaande code laat zien hoe je een geoptimaliseerde en verkleinde versie van WSO2 APIM voor elk profiel kunt maken.

ARG WSO2_SERVER_NAME=wso2am
ARG WSO2_SERVER_VERSION
ARG WSO2_PATCH_LEVEL
ARG WSO2_PROFILE
ARG NEXUS_USERNAME
ARG NEXUS_PASSWORD
ARG WSO2_SERVER_DIST_URL
ARG WSO2_FULL_NAME=${WSO2_SERVER_VERSION}.${WSO2_PATCH_LEVEL}
ARG WSO2_BIN_NAME=apim-${WSO2_FULL_NAME}.zip
ARG APP_BASE_DIR=/opt
ARG WSO2_DIR_NAME=${WSO2_SERVER_NAME}-${WSO2_SERVER_VERSION}
ARG WSO2_SERVER_HOME=${APP_BASE_DIR}/${WSO2_DIR_NAME}

###
# Setup the build image.
#
FROM registry.access.redhat.com/ubi9/ubi-minimal:latest as builder
ARG WSO2_SERVER_NAME
ARG WSO2_SERVER_VERSION
ARG WSO2_PATCH_LEVEL
ARG WSO2_PROFILE
ARG WSO2_FULL_NAME
ARG WSO2_BIN_NAME
ARG APP_BASE_DIR
ARG WSO2_DIR_NAME
ARG WSO2_SERVER_HOME
ARG WSO2_SERVER_DIST_URL
ARG WSO2_LIB_DIR=${WSO2_SERVER_HOME}/repository/components/lib
ARG WSO2_DROPINS_DIR=${WSO2_SERVER_HOME}/repository/components/dropins

LABEL maintainer="WSO2 Docker For RHEL <Afarin>"  \
      com.wso2.docker.source="https://github.com/wso2/docker-apim"
LABEL WSO2-APIM-VERSION=${WSO2_FULL_NAME}

# Nexus configs for downloading binaries and plugins
ARG NEXUS_USERNAME
ARG NEXUS_PASSWORD
ARG NEXUS_REPO_URL

# Install required packages for unpacking WSO2 sourcen
RUN microdnf install --nodocs -y --setopt install_weak_deps=0 unzip findutils \
    && microdnf clean all

# download WSO2 binary
RUN curl -u ${NEXUS_USERNAME}:${NEXUS_PASSWORD} -o ${APP_BASE_DIR}/${WSO2_BIN_NAME} ${WSO2_SERVER_DIST_URL}
# COPY --chown=root:root local/wso2_APIM_4.3.0.zip ${APP_BASE_DIR}/${WSO2_BIN_NAME}

# This Dockerfile command creates necessary directories, sets permissions, unzips wso2 zipfiles,
# and copies specific directories to the target location.
RUN mkdir -p \
        ${WSO2_SERVER_HOME} && \
    chown -R root:root ${WSO2_SERVER_HOME} && \
    unzip -d ${APP_BASE_DIR} ${APP_BASE_DIR}/${WSO2_BIN_NAME} && \
    rm -rf ${WSO2_SERVER_HOME}/dbscripts && \
    find ${WSO2_SERVER_HOME} -type f -exec chmod "u=rw,g=rw,o=rw" {} + && \
    find ${WSO2_SERVER_HOME} -type d -exec chmod "u=rwx,g=rwx,o=rwx" {} + && \
    find ${WSO2_SERVER_HOME} -name "*.sh" -type f -exec chmod "u+x,g+x" {} + 

# strip down to ${WSO2_PROFILE} profile
RUN ${WSO2_SERVER_HOME}/bin/profileSetup.sh -Dprofile=${WSO2_PROFILE}

###
# Setup the runtime image
#
FROM registry.access.redhat.com/ubi9/ubi-minimal:latest
ARG WSO2_FULL_NAME
ARG WSO2_SERVER_HOME
ARG APP_BASE_DIR

ARG JAVA_HOME=/opt/jre

ARG JAVA_CACERTS=${JAVA_HOME}/lib/security/cacerts
# destination WSO2 JKS stores
ARG WSO2_CLIENT_TRUSTSTORE_JKS=${WSO2_SERVER_HOME}/repository/resources/security/client-truststore.jks
ARG WSO2_CARBON_JKS=${WSO2_SERVER_HOME}/repository/resources/security/wso2carbon.jks

COPY --from=builder --chown=root:root ${WSO2_SERVER_HOME} ${WSO2_SERVER_HOME}
COPY --chown=root:root local/docker-entrypoint.sh ${WSO2_SERVER_HOME}

COPY --from=jenkins/jenkins:rhel-ubi9-jdk21 --chown=root:root /opt/java/openjdk/ ${JAVA_HOME}

RUN ${JAVA_HOME}/bin/keytool -importkeystore -srckeystore ${JAVA_CACERTS} -destkeystore ${WSO2_CLIENT_TRUSTSTORE_JKS} -srcstorepass changeit -deststorepass wso2carbon -v; exit 0;

# WSO2 needs to change permissions before starting! A script was written only with shell commands, without installing any extra tool.
COPY --chown=root:root local/change_permissions.sh /
RUN chmod +x /change_permissions.sh && \
    sh /change_permissions.sh "u=rwx,g=rwx,o=rx" ${WSO2_SERVER_HOME} 

### Delete packet manager stuff
RUN rm -fr /var/cache/* /var/lib/dnf /var/lib/rpm /var/lib/rpm-state /etc/yum.repos.d /etc/dnf

WORKDIR ${WSO2_SERVER_HOME}

ENV WORKING_DIRECTORY=${WSO2_SERVER_HOME} \
    WSO2_SERVER_HOME=${WSO2_SERVER_HOME} \
    JAVA_HOME=${JAVA_HOME} \
    WSO2_APIM_VERSION=${WSO2_FULL_NAME}

EXPOSE 5672 8672 8280 8243 9099 9443 9611 9711 9763 9999 11111

In dit voorbeeld-Dockerbestand gebruiken we een “builder” die fungeert als een tijdelijke afbeelding. We installeren alle benodigde afbeeldingen, downloaden WSO2 APIM en kunnen ook alle andere benodigde bibliotheken zoals databaseconnectoren of messaging-libraries toevoegen. Vervolgens unzippen we deze en installeren (of kopiëren ze naar de dropin- of lib-directory).

RUN ${WSO2_SERVER_HOME}/bin/profileSetup.sh -Dprofile=${WSO2_PROFILE}

De laatste regel in de builder is de bovenstaande lijn. Deze is verantwoordelijk voor het optimaliseren van de huidige APIM-configuratie voor het opgegeven profiel dat aan de variabele “WSO2_PROFILE” wordt doorgegeven. Het verwijdert onnodige bestanden voor elk profiel. Vanaf dit punt hebben we een geoptimaliseerde versie van de APIM-configuratie.

In dit voorbeeld hebben we een bash-bestand genaamd “local/change_permissions.sh” aangeroepen dat verantwoordelijk is voor het instellen van machtigingen voor de gekopieerde mappen en bestanden van de builder. De voorbeeldcode is beschikbaar in de Yenlo-repository.

Bouwen

Nu zijn we klaar om dit bestand in de OpenShift-omgeving te bouwen. We hebben twee Dockerbestanden gedefinieerd: een simpele en een geoptimaliseerde versie. Voor de simpele versie moet je een “BuildConfig” maken in je OpenShift-cluster. Kies Binary als bron en geef “wso2-apim-simple” als naam. Door de onderstaande opdracht in de directory van je simpele Dockerfile uit te voeren, wordt het bouwen van de afbeelding gestart op basis van je Dockerfile. Na succesvolle voltooiing wordt een afbeelding gemaakt in de image repository van het cluster en is deze beschikbaar voor gebruik.

oc start-build wso2-apim-simple –-from-dir .

Voor de geoptimaliseerde versie moeten we 3 verschillende “BuildConfig”-bestanden maken. Je moet alle benodigde variabelen doorgeven. Een van de belangrijkste variabelen is “WSO2_PROFILE”, die je moet instellen. Voor elk bestand gebruik je een van de volgende profielnamen:

• gateway-worker
• control-plane
• traffic-manager

Stel dat je ze wso2-apim-gw, wso2-apim-cp, wso2-apim-tm noemt en de juiste waarde instelt voor elk van hen in de “WSO2_PROFILE” variabele, dan kun je door de onderstaande opdrachten uit te voeren 3 verschillende afbeeldingen maken, geoptimaliseerd voor hun specifieke doeleinden.

oc start-build wso2-apim-gw –-from-dir .

oc start-build wso2-apim-cp –-from-dir .

oc start-build wso2-apim-tm –-from-dir .

Vergeet niet dat je voor het uitvoeren van de “oc”-opdracht eerst de “oc cli” moet installeren en inloggen op je cluster in de OpenShift-omgeving.

Conclusie

Het implementeren van WSO2 API Manager (APIM) met RedHat UBI-minimal op OpenShift voldoet niet alleen aan strikte organisatorische beleidslijnen, maar biedt ook een gestroomlijnde, veilige en efficiënte benadering voor het beheren van je API’s. Door gebruik te maken van het lichte UBI-minimal-afbeelding, kun je de afbeeldingsgrootte aanzienlijk verkleinen, de veiligheid verbeteren en voldoen aan de licentievereisten, waardoor het een uitstekende keuze is voor moderne, container-gebaseerde omgevingen.

In dit blog hebben we de complexiteit van het maken, bouwen en implementeren van WSO2 APIM-afbeeldingen met UBI-minimal behandeld. We hebben de essentiële stappen besproken, van het begrijpen van de voor- en nadelen van UBI-minimal tot het aanpassen van de Dockerfile voor WSO2 APIM en het optimaliseren ervan voor specifieke profielen. De voorbeelden laten zien hoe je afhankelijkheden effectief beheert, omgevingen configureert en ervoor zorgt dat je API-beheersoplossing zowel robuust als flexibel is.

Door de beschreven procedures te volgen, kun je geoptimaliseerde WSO2 APIM-afbeeldingen maken die zijn afgestemd op je specifieke implementatiebehoeften, of het nu gaat om een gateway worker, control plane of traffic manager. Dit verbetert niet alleen de prestaties, maar zorgt er ook voor dat elk component perfect is afgestemd op zijn rol binnen de gedistribueerde architectuur.

Aangezien API’s blijven bijdragen aan innovatie en connectiviteit in moderne applicaties, is het essentieel om een solide, efficiënte en veilige oplossing voor API-beheer te hebben. WSO2 APIM op UBI-minimal binnen OpenShift biedt een veelbelovende richting, waarbij de voordelen van open-source flexibiliteit worden gecombineerd met de robuustheid van enterprise-grade oplossingen. Omarm deze benadering om nieuwe niveaus van efficiëntie en veiligheid te bereiken in je API-beheer.