New enhancements for Liberty InstantOn in 23.0.0.2-beta

Initially, the InstantOn beta provided three phases during the startup process where a checkpoint could occur:

Of these three options, the features phase offers the least value in terms of improving an application startup time. Scenarios where an application deployment would want to use features over beforeAppStart are very limited and are not good use cases for Liberty InstantOn. For the 23.0.0.2-beta, the features checkpoint phase has been removed. This change leaves only two options to choose from for the checkpoint: beforeAppStart and afterAppStart.

For criu to take a checkpoint of and restore a process, the criu binary must be granted additional Linux capabilities. In particular, for the Open Liberty 22.0.0.11-beta, it needed to be granted checkpoint_restore, net_admin and sys_ptrace capabilities.

The Open Liberty 23.0.0.2-beta removes the need for the net_admin capability for both the checkpoint and restore of a process; also, the sys_ptrace capability is no longer necessary to restore the process when running the application with Liberty InstantOn. This change is an improvement: the net_admin and sys_ptrace capabilities grant a broad set of capabilities that might be unacceptable when deploying an application to the cloud. The 23.0.0.2-beta introduces a requirement for the setpcap capability; the use of this capability is described in the next section.

The Liberty InstantOn beta image contains the prerequisites for building an application container image with a checkpoint server process. Applications can use the Liberty InstantOn beta image as a base to create their own application container image with a checkpoint process. For the 22.0.0.11-beta, this was a three step process:

For the 23.0.0.2-beta, this process is simplified for systems that are running on kernel versions with the clone3 system call and the checkpoint_restore capability. These kernel features, available in kernel version 5.9 or greater, make it possible to perform the process checkpoint during the container build. One additional Linux capability, called setpcap, must be granted to criu to allow the process checkpoint from a container build to be restored successfully. The setpcap grants criu the ability to drop capabilities for the restored process. This function is necessary in cases where the checkpoint process running during the build step has fewer Linux capabilities granted to it than the container does when running the application image. When criu detects this situation, it drops the Linux capabilities associated with restored process to match the reduced set that is used during the container build.

To do the process checkpoint during the container build step, the Dockerfile for the application must be updated with an additional RUN instruction at the end to perform the process checkpoint. Using the example application project from the original post, add RUN checkpoint.sh afterAppStart to the end of the Dockerfile:

This configuration adds the application process checkpoint as the last layer of the application container image. The checkpoint.sh script allows you to specify either afterAppStart or beforeAppStart to indicate what phase of the startup should perform the process checkpoint. With podman, you can use the --add-cap and --security-opt options to grant the container build the necessary capabilities to take a checkpoint during the container build step. This reduces the application container image build to the following step:

If the host OS has kernel version 5.9+, then the clone3 system call is used by criu. This removes the need to mount ns_last_pid. With the 23.0.0.2-beta, the getting-started-instanton container can be run with the following command:

The 23.0.0.2-beta removes the requirement to add the sys_ptrace or net_admin when running the application container with Liberty InstantOn. Note that podman grants running containers the setpcap capability by default. So, you might be able to run the container without explicitly adding this capability with --cap-add.

As you can see, we continue to refine the InstantOn beta to make it easier to consume. Stay tuned for more updates in coming beta releases, including how to deploy InstantOn to public clouds like AWS. If you have any requests or suggestions, we would love to hear from you!