Skip to content

alpine-openjdk7

Deprecation Warning

This image has been deprecated and no updates (or support) may be available in future. Even though it is a container, it may or may not keep working as expected, use at your own risk.

updated stars forks watchers issues issues-pr
pulls stars aarch64 armhf armv7l x86_64

Container for Alpine Linux + S6 + GNU LibC + OpenJDK 7


This image serves as the base image for applications / services that require an OpenJDK7 compiler/runtime.

Based on Alpine Linux from the glibc image with the openjdk7 packages installed in it.

JDK 7 Deprecation

OpenJDK 7.*.* prebuilt packages has been excluded from Alpine Linux Repositories since v3.19. This image uses the packages from the v3.18 repo.


Get the Image

Pull the image from Docker Hub.

docker pull woahbase/alpine-openjdk7
Image Tags

The image is tagged respectively for the following architectures,

   aarch64

   armhf

   armv7l

   x86_64

latest tag is retagged from x86_64, so pulling without any tag fetches you that image. For any other architectures specify the tag for that architecture. e.g. for armv8 or aarch64 host it is alpine-openjdk7:aarch64.

non-x86_64 builds have embedded binfmt_misc support and contain the qemu-user-static binary that allows for running it also inside an x86_64 environment that has support for it.


Run

We can call java commands directly on the container, or run bash in the container to get a shell,

docker run --rm -it --name docker_openjdk7 woahbase/alpine-openjdk7 java -version
docker run --rm -it --name docker_openjdk7 woahbase/alpine-openjdk7 /bin/bash
Multi-Arch Support

If you want to run images for other architectures on a x86_64 machine, you will need to have binfmt support configured for your machine before running the image. multiarch, has made it easy for us containing that into a docker container, just run

docker run --rm --privileged multiarch/qemu-user-static --reset -p yes

Now images built for other architectures will also be executable. This is optional though, without the above, you can still run the image that is made for your architecture.


Configuration

We can customize the runtime behaviour of the container with the following environment variables.

ENV Vars Default Description
JAVA_HOME /usr/lib/jvm/java-1.7-openjdk (Preset) Specifies which Java runtime environment (JRE) to use.
S6_NEEDED_PACKAGES empty string Space-separated list of extra APK packages to install on start. E.g. "curl git tzdata"
PUID 1000 Id of S6_USER.
PGID 100 Group id of S6_USER.
S6_USER alpine (Preset) Default non-root user for services to drop privileges to.
S6_USERHOME /home/alpine (Preset) HOME directory for S6_USER.
Did you know?

You can check your own UID/GID by running the command id in a terminal.


Build Your Own

Feel free to clone (or fork) the repository and customize it for your own usage, build the image for yourself on your own systems, and optionally, push it to your own public (or private) repository.

Here's how...


Setting up


Before we clone the /repository, we must have Git, GNU make, and Docker (optionally, with buildx plugin for multi-platform images) setup on the machine. Also, for multi-platform annotations, we might require enabling experimental features of Docker.

Now, to get the code,

Clone the repository with,

git clone https://github.com/woahbase/alpine-openjdk
cd alpine-openjdk
Always Check Before You Make!

Did you know, we could check what any make target is going to execute before we actually run them, with

make -n <targetname> <optional args>

Build and Test


To create the image for your architecture, run the build and test target with

make build test JVVMAJOR=7

For building an image that targets another architecture, it is required to specify the ARCH parameter when building. e.g.

make build test ARCH=aarch64 JVVMAJOR=7
make build test ARCH=armhf JVVMAJOR=7
make build test ARCH=armv7l JVVMAJOR=7
make build test ARCH=x86_64 JVVMAJOR=7

Make to Run


Running the image creates a container and either starts a service (for service images) or provides a shell (can be either a root-shell or usershell) to execute commands in, depending on the image. We can run the image with

make run JVVMAJOR=7

But if we just need a root-shell in the container without any fance pre-tasks (e.g. for debug or to test something bespoke), we can run bash in the container with --entrypoint /bin/bash. This is wrapped in the makefile as

make shell JVVMAJOR=7
Nothing vs All vs Run vs Shell

By default, if make is run without any arguments, it calls the target all. In our case this is usually mapped to the target run (which in turn may be mapped to shell).

There may be more such targets defined as per the usage of the image. Check the makefile for more information.


Push the Image


If the build and test steps finish without any error, and we want to use the image on other machines, it is the next step push the image we built to a container image repository (like /hub), for that, run the push target with

make push JVVMAJOR=7

If the built image targets another architecture then it is required to specify the ARCH parameter when pushing. e.g.

make push ARCH=aarch64 JVVMAJOR=7
make push ARCH=armhf JVVMAJOR=7
make push ARCH=armv7l JVVMAJOR=7
make push ARCH=x86_64 JVVMAJOR=7

That's all folks! Happy containerizing!


Maintenance

Sources at Github. Images at Docker Hub.

Maintained (or sometimes a lack thereof?) by WOAHBase.