This container image includes Apache HTTP Server 2.4 for OpenShift and general usage. Users can choose between RHEL, CentOS and Fedora based images. The RHEL images are available in the Red Hat Container Catalog, the CentOS Stream images are available on Quay.io, and the Fedora images are available in Fedora Registry. The resulting image can be run using podman.
Note: while the examples in this README are calling podman, you can replace any such calls by docker with the same arguments
Apache HTTP Server 2.4 available as container, is a powerful, efficient, and extensible web server. Apache supports a variety of features, many implemented as compiled modules which extend the core functionality. These can range from server-side programming language support to authentication schemes. Virtual hosting allows one Apache installation to serve many different Web sites."
In this example, we assume that you are using the rhel8/httpd-24 image, available through the openshift/httpd:2.4-el8 imagestream tag in Openshift.
To build a simple httpd-sample-app application in Openshift:
oc new-app openshift/httpd:2.4-el8~https://github.com/sclorg/httpd-ex.git
To access the application:
$ oc get pods
$ oc exec <pod> -- curl 127.0.0.1:8080
This image supports the Source-to-Image (S2I) strategy in OpenShift. The Source-to-Image is an OpenShift framework which makes it easy to write images that take application source code as an input, use a builder image like this httpd container image, and produce a new image that runs the assembled application as an output.
To support the Source-to-Image framework, important scripts are included in the builder image:
-
The
/usr/libexec/s2i/runscript is set as the default command in the resulting container image (the new image with the application artifacts). -
The
/usr/libexec/s2i/assemblescript inside the image is run to produce a new image with the application artifacts. The script takes sources of a given application and places them into appropriate directories inside the image. The structure of httpd-app can look like this:
./httpd-cfg
Can contain additional Apache configuration files (*.conf)
./httpd-pre-init
Can contain shell scripts (*.sh) that are sourced before httpd is started
./httpd-ssl
Can contain user's own SSL certificate (in the certs/ subdirectory) and a key (in the private/ subdirectory)
./
Application source code
Compared to the Source-to-Image strategy, using a Dockerfile is a more flexible way to build an httpd container image with an application. Use a Dockerfile when Source-to-Image is not sufficiently flexible for you or when you build the image outside of the OpenShift environment.
To use the httpd image in a Dockerfile, follow these steps:
podman pull rhel8/httpd-24
An example application available at https://github.com/sclorg/httpd-ex.git is used here. To adjust the example application, clone the repository.
git clone https://github.com/sclorg/httpd-ex.git app-src
This step usually consists of at least these parts:
- putting the application source into the container
- moving certificates to the correct place (if available in the application source code)
- setting the default command in the resulting image
For all these three parts, you can either set up all manually and use the httpd or run-httpd commands explicitly in the Dockerfile (3.1.), or you can use the Source-to-Image scripts inside the image (3.2.. For more information about these scripts, which enable you to set-up and run the httpd daemon, see the "Source-to-Image framework and scripts" section above.
FROM registry.redhat.io/rhel8/httpd-24
# Add application sources
ADD app-src/index.html /var/www/html/index.html
# The run script uses standard ways to run the application
CMD run-httpd
3.2. To use the Source-to-Image scripts and build an image using a Dockerfile, create a Dockerfile with this content:
FROM registry.redhat.io/rhel8/httpd-24
# Add application sources to a directory where the assemble script expects them
# and set permissions so that the container runs without the root access
USER 0
ADD app-src/index.html /tmp/src/index.html
RUN chown -R 1001:0 /tmp/src
USER 1001
# Let the assemble script install the dependencies
RUN /usr/libexec/s2i/assemble
# The run script uses standard ways to run the application
CMD /usr/libexec/s2i/run
podman build -t httpd-app .
podman run -d httpd-app
An example of the data on the host for both the examples above, which is served by The Apache HTTP web server:
$ ls -lZ /wwwdata/html
-rw-r--r--. 1 1001 1001 54321 Jan 01 12:34 index.html
-rw-r--r--. 1 1001 1001 5678 Jan 01 12:34 page.html
If you want to run the image directly and mount the static pages available in the /wwwdata/ directory on the host
as a container volume, execute the following command:
$ podman run -d --name httpd -p 8080:8080 -v /wwwdata:/var/www:Z rhel8/httpd-24
This creates a container named httpd running the Apache HTTP Server, serving data from
the /wwwdata/ directory. Port 8080 is exposed and mapped to the host.
The Apache HTTP Server container image supports the following configuration variable, which can be set by using the -e option with the podman run command:
HTTPD_LOG_TO_VOLUME
By default, httpd logs into standard output, so the logs are accessible by using the podman logs command. When HTTPD_LOG_TO_VOLUME is set, httpd logs into /var/log/httpd24, which can be mounted to host system using the container volumes. This option is only allowed when container is run as UID 0.
HTTPD_MPM
The variable HTTPD_MPM can be set to change the default Multi-Processing Module (MPM) from the package default MPM.
If you want to run the image and mount the log files into /wwwlogs on the host
as a container volume, execute the following command:
$ podman run -d -u 0 -e HTTPD_LOG_TO_VOLUME=1 --name httpd -v /wwwlogs:/var/log/httpd24:Z rhel8/httpd-24
To run an image using the event MPM (rather than the default prefork), execute the following command:
$ podman run -d -e HTTPD_MPM=event --name httpd rhel8/httpd-24
You can also set the following mount points by passing the -v /host:/container flag to podman.
/var/www
Apache HTTP Server data directory
/var/log/httpd24
Apache HTTP Server log directory (available only when running as root, path /var/log/httpd is used in case of Fedora based image)
Notice: When mouting a directory from the host into the container, ensure that the mounted directory has the appropriate permissions and that the owner and group of the directory matches the user UID or name which is running inside the container.
Default SSL certificates are generated when Apache HTTP server container is started for the first time or own SSL certificates were not provided (see bolow how to provide them). SSL certificates are not stored in the base image but generated, so each container will have unique default SSL key pair. SSL certificate/key are stored in /etc/httpd/tls directory:
/etc/httpd/tls/localhost.key
/etc/httpd/tls/localhost.crt
In order to provide own SSL certificates for securing the connection with SSL, use the extending feature described above. In particular, put the SSL certificates into a separate directory inside your application:
./httpd-ssl/certs/server-cert-selfsigned.pem
./httpd-ssl/private/server-key.pem
The default behaviour is to look for the certificate and the private key in subdirectories certs/ and private/; those files will be used for the ssl settings in the httpd.
By default, Apache HTTP Server container runs as UID 1001. That means the volume mounted directories for the files (if mounted using -v option) need to be prepared properly, so the UID 1001 can read them.
To run the container as a different UID, use -u option. For example if you want to run the container as UID 1234, execute the following command:
podman run -d -u 1234 rhel8/httpd-24
To log into a volume mounted directory, the container needs to be run as UID 0 (see above).
The httpd deamon in the container logs to the standard output by default, so the log is available in the container log. The log can be examined by running:
podman logs <container>
Dockerfile and other sources for this container image are available on https://github.com/sclorg/httpd-container. In that repository, the Dockerfile for RHEL8 is called Dockerfile.rhel8, the Dockerfile for RHEL9 is called Dockerfile.rhel9, the Dockerfile for CentOS Stream 9 is called Dockerfile.c9s, the Dockerfile for CentOS Stream 10 is called Dockerfile.c10s, and the Dockerfile for Fedora is called Dockerfile.fedora.