diff --git a/modules/ROOT/pages/container-images.adoc b/modules/ROOT/pages/container-images.adoc index 7609e17dcc..252464bb4a 100644 --- a/modules/ROOT/pages/container-images.adoc +++ b/modules/ROOT/pages/container-images.adoc @@ -23,10 +23,12 @@ You can append an Open Liberty container image tag to the `icr.io/appcafe/open-l Select from the following container image tags for the latest Open Liberty release from ICR. +* `kernel-slim-java21-openj9-ubi-minimal` * `kernel-slim-java17-openj9-ubi` * `kernel-slim-java11-openj9-ubi` * `kernel-slim-java8-openj9-ubi` * `kernel-slim-java8-ibmjava-ubi` +* `full-java21-openj9-ubi-minimal` * `full-java17-openj9-ubi` * `full-java11-openj9-ubi` * `full-java8-openj9-ubi` @@ -49,11 +51,11 @@ ibmcloud cr images --restrict appcafe/open-liberty You can use an Open Liberty container image tag in a `Dockerfile` or `Containerfile` file to build an application image that adds a single application and its corresponding configuration. Do not configure the container manually after it is started, except for debugging purposes, because these changes are not reflected in new containers that are created from the image. -Set your image template similar to the following example, which uses the `kernel-slim-java17-openj9-ubi` tag to build an image that uses the latest Open Liberty release with the OpenJ9 distribution of Java 17. +Set your image template similar to the following example, which uses the `kernel-slim-java21-openj9-ubi-minimal` tag to build an image that uses the latest Open Liberty release with the OpenJ9 distribution of Java 21. [source,dockerfile] ---- -FROM icr.io/appcafe/open-liberty:kernel-slim-java17-openj9-ubi +FROM icr.io/appcafe/open-liberty:kernel-slim-java21-openj9-ubi-minimal # Add a Liberty server configuration including all necessary features COPY --chown=1001:0 server.xml /config/ @@ -84,7 +86,7 @@ You can also use xref:instanton.adoc[Open Liberty InstantOn] to improve the star Open Liberty container image tags use the following naming convention. [subs=+quotes] ---- -_**-****-****-**ubi +--- ---- The following tag values determine the resources that are included in a container image. @@ -92,7 +94,7 @@ The following tag values determine the resources that are included in a containe Fix pack version:: This value is optional. If you do not specify a fix pack version, your container image includes the latest release of Open Liberty. In addition to the latest release, the two most recent quarterly fix pack releases are always maintained for the `kernel-slim` and `full` image types. + -Open Liberty quarterly release versions end in `.3`, `.6`, `.9`, or `.12`. For example, if the latest Open Liberty release is `22.0.0.10`, then the `22.0.0.9` and `22.0.0.6` releases are also maintained in ICR. To pull one of these release versions instead of the latest, add your chosen release version to the beginning of any of the `kernel-slim` or `full` image tags in the previous list. For example, if `22.0.0.9` is a recent quarterly release, you can pull an image that includes the `22.0.0.9` release with an OpenJ9 distribution of Java 8 by specifying the `22.0.0.9-full-java8-openj9-ubi` tag. The `beta` images are available only for the latest beta release. +Open Liberty quarterly release versions end in `.3`, `.6`, `.9`, or `.12`. For example, if the latest Open Liberty release is `24.0.0.1`, then the `23.0.0.12` and `23.0.0.9` releases are also maintained in ICR. To pull one of these release versions instead of the latest, add your chosen release version to the beginning of any of the `kernel-slim` or `full` image tags in the previous list. For example, if `23.0.0.12` is a recent quarterly release, you can pull an image that includes the `23.0.0.12` release with an OpenJ9 distribution of Java 8 by specifying the `23.0.0.12-full-java8-openj9-ubi` tag. The `beta` image is available only for the latest beta release of Liberty and includes the latest Java JRE. Liberty image type:: Two different image types are available: `kernel-slim` or `full`. The `full` type provides a server with all Open Liberty features and packages installed. @@ -103,11 +105,21 @@ Java version:: This value determines the version of Java SE that the runtime uses. Tags are available for all Java long term support (LTS) releases that are listed on the xref:java-se.adoc[Java SE Support page]. Java type:: -This value determines the type of Java SE distribution that the runtime uses. Current options are IBM Semeru with Eclipse OpenJ9 and, for Java SE 8 only, the IBM SDK, Java Technology Edition. +This value determines the type of Java SE distribution that the runtime uses. Current options are IBM Semeru Runtime with Eclipse OpenJ9, named `openj9` and, for Java SE 8 only, the IBM SDK, Java Technology Edition, named `ibmjava`. -In addition to the tags that follow this naming convention, Open Liberty offers three preformatted tags that pull particular images. +Java 21 images are based on Universal Base Image (UBI) 9 minimal and include IBM Semeru Runtimes for Java 21 JRE. This combination offers a compact and effective Java runtime that is suited for applications that need Java 21. -* `latest`: This tag simplifies pulling the full latest Open Liberty release with Java 8. It is an alias for the `full-java8-openj9-ubi` tag. If you do not specify a tag value, `latest` is used by default. -* `beta`: This tag provides the most recent beta release, which includes all the features and capabilities from the most recent release, plus new and updated features that are currently in development. +Java 8, 11 and 17 images with the `openj9` type are based on Universal Base Image (UBI) 8 standard and include IBM Semeru Runtime for the respective Java version with the JDK. Images with the `ibmjava` type are based on Universal Base Image (UBI) 8 standard and include IBM Java 8 JRE. + +Base image type:: +Liberty images are available with two different types of Red Hat Universal Base Image (UBI): `ubi-minimal` or `ubi`. +`ubi-minimal` offers a minimized pre-installed content set and the package manager `microdnf` for adding additional packages. +`ubi` offers the standard images with access to `yum` repositories and includes utilities such as `tar` and `gzip`. + + +In addition to the tags that follow this naming convention, Open Liberty offers the following preformatted tags that pull particular images. + +* `latest`: This tag simplifies pulling the full latest Open Liberty release with the latest Java JRE. It is an alias for the `full-java21-openj9-ubi-minimal` tag. If you do not specify a tag value, `latest` is used by default. +* `beta`: This tag is based on Universal Base Image (UBI) 9 minimal and the latest Java JRE and provides the most recent beta release of Liberty, which includes all the features and capabilities from the most recent release, plus new and updated features that are currently in development. diff --git a/modules/ROOT/pages/instanton.adoc b/modules/ROOT/pages/instanton.adoc index 32de2d312c..1a562f8432 100644 --- a/modules/ROOT/pages/instanton.adoc +++ b/modules/ROOT/pages/instanton.adoc @@ -63,14 +63,14 @@ For more information about limitations with early startup code and possible work [#prereq] == Runtime and host build system prerequisites -Starting with Open Liberty version 23.0.0.6, all X86-64/AMD64 UBI xref:container-images.adoc[Open Liberty container images] include the prerequisites for InstantOn to checkpoint and restore Open Liberty application processes. Open Liberty Ubuntu container images are not enabled for InstantOn. +Starting with Open Liberty version 23.0.0.6, all X86-64/AMD64 UBI xref:container-images.adoc[Open Liberty container images] include the prerequisites for InstantOn to checkpoint and restore Open Liberty application processes. In version 24.0.0.1 and later, Power and Z (s390x) processor architectures are also supported when you use IBM Semeru Java version 21.0.1+. Open Liberty Ubuntu container images are not enabled for InstantOn. -Currently, InstantOn is supported with IBM Semeru Java version 11.0.19+ and IBM Semeru Java version 17.0.7+. InstantOn is expected to support new versions of IBM Semeru Java as they are released. Currently, InstantOn is not supported on other Java vendor implementations. +Currently, InstantOn is supported with IBM Semeru Java version 11.0.19+, IBM Semeru Java version 17.0.7+, and IBM Semeru Java version 21.0.1+. InstantOn is expected to support new versions of IBM Semeru Java as they are released. Currently, InstantOn is not supported on other Java vendor implementations. To use InstantOn during an application container image build, the host machine must satisfy the following prerequisites: - Uses the Linux Operating System with kernel version 5.9 or greater -- Uses the X86-64/AMD64 processor architecture +- Uses one of the following the processor architectures: X86-64/AMD64, Power (with IBM Semeru Java version 21.0.1+), Z (s390x) (with IBM Semeru Java version 21.0.1+) - Allows execution of privileged container builds by using Podman or Docker The use of privileged containers in the application container image build is required only when you build the container image with InstantOn. Running the resulting InstantOn application image does not require the use of privileged containers. @@ -235,11 +235,11 @@ Special considerations are required to run an InstantOn application image locall 1. The host that is running the container image must use Linux kernel 5.9 or greater 2. The Linux capabilities CHECKPOINT_RESTORE and SETPCAP must be granted to the running container 3. The necessary system calls must be granted to the running container -4. The host processor must be X86-64/AMD64 +4. The host processor must be X86-64/AMD64. If you are running IBM Semeru Java version 21.0.1+, Power and Z (s390x) processor architectures are also supported. === Running an InstantOn application image locally -If a host system is running the Linux kernel 5.9 or greater with the X86-64/AMD64 processor, you can run an InstantOn application image by using Podman or Docker locally. The following command runs the `liberty-app-instanton` InstantOn application image with Podman: +If a host system is running the Linux kernel 5.9 or greater with the X86-64/AMD64 processor, you can run an InstantOn application image by using Podman or Docker locally. If you are running IBM Semeru Java version 21.0.1+, Power and Z (s390x) processor architectures are also supported. The following command runs the `liberty-app-instanton` InstantOn application image with Podman: [source,sh] ---- diff --git a/modules/ROOT/pages/java-se.adoc b/modules/ROOT/pages/java-se.adoc index 9f1275850f..1bb975d18c 100644 --- a/modules/ROOT/pages/java-se.adoc +++ b/modules/ROOT/pages/java-se.adoc @@ -68,19 +68,11 @@ The following table lists the Java SE versions that Open Liberty supports and pr |21 |Yes |29.0.0.10 -| +|https://developer.ibm.com/languages/java/semeru-runtimes/downloads/?version=21[IBM Semeru 21] |https://adoptium.net/temurin/releases/?version=21[Eclipse Temurin 21] |https://docs.oracle.com/en/java/javase/21/migrate/toc.htm[Java SE 21 migration guide] |=== -//// -|20 -|No -|https://developer.ibm.com/languages/java/semeru-runtimes/downloads/[IBM Semeru 20] -|https://developer.ibm.com/languages/java/semeru-runtimes/downloads/?version=20 -|https://adoptium.net/temurin/releases/?version=20[Eclipse Temurin 20] -|https://docs.oracle.com/en/java/javase/20/migrate/toc.htm[Java SE 20 migration guide] -//// == Migration tools @@ -94,4 +86,3 @@ java -jar binaryAppScanner.jar myapp.war --analyze --sourceJava=ibm8 --targetJav ``` Plug-ins that run a similar analysis on your application are available from Eclipse in the https://marketplace.eclipse.org/content/ibm-websphere-application-server-migration-toolkit-was-liberty[Eclipse marketplace]. - diff --git a/modules/ROOT/pages/verifying-package-signatures.adoc b/modules/ROOT/pages/verifying-package-signatures.adoc index b50a016ed6..a486b1c0e1 100644 --- a/modules/ROOT/pages/verifying-package-signatures.adoc +++ b/modules/ROOT/pages/verifying-package-signatures.adoc @@ -15,21 +15,21 @@ You can use signature files and the corresponding public key to verify the authenticity and integrity of an Open Liberty release package. Signature files are produced for every package of an Open Liberty release. -Signature files are available for every Open Liberty release. The Open Liberty project uses its private key to digitally sign each Open Liberty release. You can use the Open Liberty public key to check the signature, verify that the package was released by Open Liberty, and that it was not modified since its release. +The Open Liberty project uses its private key to digitally sign each Open Liberty release. You can use the Open Liberty public key to check the signature, verify that the package was released by Open Liberty, and that it was not modified since its release. -You can verify a release package either locally, by using the `openssl` command and a `*.sig` file, or on Maven Central, by using the `gpg` command. When you verify the release locally, you can also verify the authenticity of the Open Liberty public key by using a certificate (`.cer`) file. +You can verify a release package either locally, by using the `openssl` command and a `.sig` file, or on Maven Central, by using the `gpg` command. When you verify the release locally, you can also verify the authenticity of the Open Liberty public key by using a certificate (`.cer`) file. == Verifying Open Liberty release package signatures with OpenSSL -To verify an Open Liberty release package locally, you must first download an Open Liberty `.zip` package, the corresponding `*.sig` file, and the Open Liberty public key, which is included in the certificate (`.cer`) file. You can then run the `openssl` command to verify the package signature. Optionally, you can verify the authenticity of the Open Liberty public key before you verify the release package. +To verify an Open Liberty release package locally, you must first download an Open Liberty `.zip` release package, the corresponding `.sig` file, and a `.cer` file, which includes the Open Liberty public key. After you extract the Open Liberty public key from the `.cer` file, you can run the `openssl` command to verify the package signature. Optionally, you can verify the authenticity of the Open Liberty public key before you extract it from the `.cer` file. In the following examples, replace the `` and `` variables with the public key (`.cer`), signature (`.sig`), and release package (`.zip`) files that you are using to verify a release package. -1. Go to the **Download package** section of the Open Liberty https://www.openliberty.io/start/[Get Started page] and download an Open Liberty `.zip` package and the corresponding `.sig` and `.cer` files. +1. Go to the **Download package** section of the Open Liberty https://www.openliberty.io/start/[Get Started page] and download an Open Liberty `.zip` release package and the corresponding `.sig` and `.cer` files. 2. Verify the authenticity of the Open Liberty public key. + -The Open Liberty public key is embedded in the certificate file. Before you extract the Open Liberty public key, you can verify that it was produced by Open Liberty. Run the following https://www.openssl.org/docs/man1.1.1/man1/openssl-dgst.html[openssl command] from the directory that contains the certificate file. +The Open Liberty public key is embedded in the `.cer` file. Before you extract the Open Liberty public key, you can verify that it was produced by Open Liberty. Run the following https://www.openssl.org/docs/man1.1.1/man1/openssl-dgst.html[openssl command] from the directory that contains the `.cer` file: + [source,sh] ---- @@ -62,7 +62,7 @@ Certificate: 3. Extract the public key from the `.cer` file as a `.pem` file. + -The Open Liberty public key is embedded in the `.cer` file. To extract the key to a separate `.pem` file, run the following command from the directory that contains the certificate file. +The Open Liberty public key is embedded in the `.cer` file. To extract the key to a separate `.pem` file, run the following command from the directory that contains the `.cer` file: + [source,sh] ---- @@ -81,7 +81,7 @@ openssl dgst -sha256 -verify .pem -signature " + gpg (GnuPG) 2.2.20; Copyright (C) 2020 Free Software Foundation, Inc. This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. @@ -147,21 +151,27 @@ Your decision? 5 Do you really want to set this key to ultimate trust? (y/N) y ---- -3. Verify the file by running the `gpg2 --verify` command. The following example verifies the Open Liberty 23.0.0.2 release package. +5. Verify the release package by running the `gpg2 --verify` command from the directory that contains the Open Liberty public key and the `.zip` and `.asc` release package files that you downloaded from Maven central. ++ +The following example uses the `openliberty-runtime-24.0.0.1.zip.asc` file to verify the 24.0.0.1 release package signature. Replace this value with the release package that you want to validate. + [source,sh] ---- -gpg2 --verify openliberty-runtime-23.0.0.2.zip.asc +gpg2 --verify openliberty-runtime-24.0.0.1.zip.asc ---- === Results -If the verification is successful, the command produces console output that is similar to the following example. +If the verification succeeds, the command produces console output that is similar to the following example: [source,sh] ---- -gpg: assuming signed data in 'openliberty-runtime-23.0.0.2.zip' -gpg: Signature made Thu 02 Mar 2023 09:02:22 AM PST +gpg: assuming signed data in 'openliberty-runtime-24.0.0.1.zip' +gpg: Signature made Thu Jan 25 08:18:11 2024 EST gpg: using RSA key E70E5D6C3F1E452CB0F67DF1BD9FD5BE9E68CA00 +gpg: checking the trustdb +gpg: marginals needed: 3 completes needed: 1 trust model: pgp +gpg: depth: 0 valid: 2 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 2u +gpg: next trustdb check due at 2027-02-09 gpg: Good signature from "International Business Machines Corporation " [ultimate] ----