i2incommon/comanage-base-devel repository overview

⁠comanage-base-image

Multi-arch Docker base image for COmanage deployments (Rocky Linux 10), with:

• PHP (from Remi) selected via build arg
• Apache HTTPD + SSL
• Shibboleth SP rebuilt from source (3.4.x or 3.5.x)
• CI/CD via Jenkins with security scanning and Docker Hub publishing

Use this as a foundation for COmanage-related images that require PHP, Apache, and Shibboleth SP.

⁠Overview

This base image:

• Installs PHP from the Remi repository, configured by the PHP_VERSION build argument.
• Installs Apache HTTPD and supporting build/runtime dependencies.
• Rebuilds Shibboleth SP from source RPMs for either 3.4.x or 3.5.x (selected at build time).
• Supports multi-architecture builds (amd64 and arm64) using docker buildx.

The container entrypoint is /bin/bash to allow downstream images or orchestration to define the final runtime command.

⁠Shibboleth SP Versions

Two Shibboleth SP build flows are available:

• 3.4.x (Rocky Linux 9 artifacts)
• 3.5.x (Rocky Linux 10 artifacts)

At build time, select the version with the SHIBBOLETH_VERSION build argument:

• 3.5 (default) → builds Shibboleth SP 3.5.x
• 3.4 → builds Shibboleth SP 3.4.x

The build scripts live under slashRoot/opt (e.g., build-sp-3.4.sh and build-sp-3.5.sh) and are invoked by the Docker build with a target architecture parameter (amd64 or arm64).

⁠Build-time Arguments

• PHP_VERSION (required): PHP stream from Remi, e.g., 8.1, 8.2, 8.3.
• SHIBBOLETH_VERSION (optional, default 3.5): 3.5 or 3.4.
• TARGETARCH (normally auto-set by buildx): amd64 or arm64. Used to select the correct RPM architecture during the Shibboleth rebuild.

Examples:

• --build-arg PHP_VERSION=8.3
• --build-arg SHIBBOLETH_VERSION=3.4
• --build-arg TARGETARCH=amd64 (only needed when not using buildx --platform)

⁠Usage Examples

⁠Example 1: Run an interactive COmanage base container for debugging

Assume you have built or pulled an image like:

• yourorg/comanage-base:php8.3-shib3.5

Start a container with an interactive shell, mounting local Apache/Shibboleth config:

# run container
 docker run --rm -it \
    --name comanage-base-dev \
    -v "(pwd)/apache/conf.d:/etc/httpd/conf.d:ro" \ -v "(pwd)/shibboleth:/etc/shibboleth:ro" \
    -p 8443:8443 \
    yourorg/comanage-base:php8.3-shib3.5

Inside the container you can then start services manually, for example:

# inside the container
httpd -DFOREGROUND & shibd php -v

This is useful for verifying PHP extensions, Apache modules, and Shibboleth configuration before building higher-level COmanage images.

⁠Example 2: Build a COmanage application image FROM this base

Use the base image as the foundation for a COmanage app (e.g., Registry or Directory):

# Example
dockerfile FROM yourorg/comanage-base:php8.3-shib3.5
# Install COmanage app code (example: copy from build context)
COPY app/ /var/www/html/
# Optional: add site-specific Apache and Shibboleth configuration
COPY apache/comanage.conf /etc/httpd/conf.d/comanage.conf COPY shibboleth/shibboleth2.xml /etc/shibboleth/shibboleth2.xml
# Adjust file ownership/permissions if needed
RUN chown -R apache:apache /var/www/html
# Default command: start Apache in the foreground
CMD ["/usr/sbin/httpd", "-DFOREGROUND"]

Build and run:

# Example
docker build -t yourorg/comanage-registry:latest . docker run --rm -p 8443:8443 yourorg/comanage-registry:latest

This pattern lets you keep all OS/PHP/Shibboleth concerns in the base image while application-specific logic lives in derived images.

⁠Jenkins Pipeline (Summary)

The pipeline performs:

1. Build context setup (derive maintainer, image name, PHP version; compute tag from branch).
2. Clean previous artifacts to avoid cross-build contamination.
3. Build two local images via docker buildx:
   • linux/amd64 → tagged as IMAGENAME_TAG
   • linux/arm64 → tagged as IMAGENAME_TAG:arm64
   • passes PHP_VERSION as a build arg.
4. Test (placeholder).
5. Security scan with Trivy for both images; publishes HTML reports; fails on CRITICAL vulns.
6. Push: builds and pushes a multi-arch image to ${MAINTAINER}/${IMAGENAME}:${TAG}.
7. Update Docker Hub Overview using this README.
8. Cleanup: remove temporary images and prune caches.
9. Notify (e.g., Slack) for production builds and on failures.

⁠Building the Image Manually

Prerequisites:

• Docker with BuildKit
• For multi-arch: docker buildx and a builder instance
• Network access to Remi and Shibboleth package repos

⁠License

See LICENSE⁠ for the complete license terms.