Chainguard Container for jre-crac

Minimalist Wolfi-based OpenJDK JRE image with CRaC support. Used for running Java applications.

Chainguard Containers are regularly-updated, secure-by-default container images.

Download this Container Image

For those with access, this container image is available on cgr.dev:

docker pull cgr.dev/ORGANIZATION/jre-crac:latest

Be sure to replace the ORGANIZATION placeholder with the name used for your organization's private repository within the Chainguard Registry.

CRaC Application Example

This section outlines how you can build and run a Java application leveraging CRaC with the Chainguard JRE CRaC Image.

In this example, we'll be using the SpringBoot PetClinic application, with the docs provided here.

Start by cloning the source code for SpringBoot PetClinic:

git clone https://github.com/spring-projects/spring-petclinic && cd spring-petclinic

Now, edit the pom.xml, and add org.crac as a dep, under the dependencies section:

    <dependency>
      <groupId>org.crac</groupId>
      <artifactId>crac</artifactId>
      <version>1.4.0</version>
    </dependency>

Then create a multistage Dockerfile, copying the program after it has been built to the JRE CRaC image:

FROM cgr.dev/ORGANIZATION/jdk-crac

COPY . /home/build/

RUN ./mvnw package

FROM cgr.dev/ORGANIZATION/jre-crac

COPY --from=0 /home/build/target/spring-petclinic-3.3.0-SNAPSHOT.jar /app/

CMD ["-XX:CRaCMinPid=70000", "-XX:CRaCCheckpointTo=/app/checkpoint", "-jar", "/app/spring-petclinic-3.3.0-SNAPSHOT.jar"]

In this example, we've set a high minimum PID as, by default, the process will run with PID 1. We must set the minimum PID as it will conflict with the PID of the process used for restore later. It's also generally a good practice as lower PIDs are typically allocated for other system processes and they must not clash on restore.

Following that, you can build the image:

docker build -t petclinic .

Note that this example tags the image with petclinic. You can now run the image by referencing this tag, as in the following command:

docker run --privileged -v ./checkpoint:/app/checkpoint --name petclinic-before petclinic

Wait until we see that it has started on port 8080.

Open a new terminal, and take a checkpoint:

docker exec petclinic-before jcmd spring-petclinic JDK.checkpoint

On moving back to the original terminal, you'll see the container has stopped. Let's resume the program from the checkpoint:

docker run --privileged -v ./checkpoint:/app/checkpoint --name petclinic-after petclinic -XX:CRaCRestoreFrom=/app/checkpoint

The program should have successfully restored from the checkpoint!:

2024-10-31T13:29:52.236Z  INFO 70473 --- [Attach Listener] o.s.c.support.DefaultLifecycleProcessor  : Restarting Spring-managed lifecycle beans after JVM restore
2024-10-31T13:29:52.258Z  INFO 70473 --- [Attach Listener] o.s.b.w.embedded.tomcat.TomcatWebServer  : Tomcat started on port 8080 (http) with context path '/'
2024-10-31T13:29:52.268Z  INFO 70473 --- [Attach Listener] o.s.c.support.DefaultLifecycleProcessor  : Spring-managed lifecycle restart completed (restored JVM running for 211 ms)

Differences between our JRE and JRE CRaC images

JRE CRaC includes CRaC CRIU

CRaC CRIU allows you to restore you Java programs using the CRaC API quickly with fewer resources.

JRE CRaC runs as root by default

To facilitate an easier workflow for performing checkpoints/restores, the image runs as root by default. It is not possible to leverage CRaC at runtime as non-root.

If you need to use a non-root user, specify java via the USER directive in the Dockerfile.

JRE CRaC disables rseq

Running with rseq enabled breaks restores leveraging CRaC:

pie: 70001: Error (criu/pie/restorer.c:467): failed sys_rseq(0x7f453767a4a0, 0x20, 0x0, 0x53053053) = -22
pie: 70001: Error (criu/pie/restorer.c:2055): Restorer fail 70001
Error (criu/cr-restore.c:2605): Restoring FAILED

If you need to re-enable rseq, pass GLIBC_TUNABLES=glibc.pthread.rseq=1 to the ENV directive in the Dockerfile.

What are Chainguard Containers?

Chainguard Containers are minimal container images that are secure by default.

In many cases, the Chainguard Containers tagged as :latest contain only an open-source application and its runtime dependencies. These minimal container images typically do not contain a shell or package manager. Chainguard Containers are built with Wolfi, our Linux undistro designed to produce container images that meet the requirements of a more secure software supply chain.

The main features of Chainguard Containers include:

• Minimal design, without unnecessary software bloat
• Daily builds to ensure container images are up-to-date with available security patches
• High quality build-time SBOMs attesting to the provenance of all artifacts within the image
• Verifiable signatures provided by Sigstore
• Reproducible builds with Cosign and apko (read more about reproducibility)

For cases where you need container images with shells and package managers to build or debug, most Chainguard Containers come paired with a -dev variant.

Although the -dev container image variants have similar security features as their more minimal versions, they feature additional software that is typically not necessary in production environments. We recommend using multi-stage builds to leverage the -dev variants, copying application artifacts into a final minimal container that offers a reduced attack surface that won’t allow package installations or logins.

Learn More

To better understand how to work with Chainguard Containers, please visit Chainguard Academy and Chainguard Courses.

In addition to Containers, Chainguard offers VMs and Libraries. Contact Chainguard to access additional products.

Trademarks

This software listing is packaged by Chainguard. The trademarks set forth in this offering are owned by their respective companies, and use of them does not imply any affiliation, sponsorship, or endorsement by such companies.