8 Procuring Software for an Enterprise Deployment

Procure the required software such as the software distributions, the container images, the WebLogic Kubernetes Operator, and the appropriate connector bundle.

This chapter includes the following topics:

Identifying and Obtaining Software Distributions for an Enterprise Deployment

Before you begin to install and configure an enterprise topology, you must download the container images from Oracle Support.

For more information about downloading the container images, see Container Images for Oracle Identity and Access Management, and Oracle IDM Microservices (Doc ID 2723908.1). Oracle is migrating container delivery to the Oracle Container Registry (https://container-registry.oracle.com). Later images will be delivered by using this mechanism.

After you have downloaded the container images, you can stage them either locally on each of your Kubernetes worker nodes or host them in a container registry. If you want to use a container registry, see Using an OCI Container Registry.

Oracle strongly recommends that you use a container registry to store your images. However, you can manually load the images on to each worker node. See Staging Container Images.

Note:

If you are using Oracle Advanced Authentication, you must use a container registry.

If you use a container registry, you have the option of either pulling the images on demand to the worker node which requires them (see individual product chapters) or pulling the image ahead of time to every Kubernetes worker node in your deployment. If you choose to pull the images ahead of time, see Downloading Images from a Container Registry.

For obtaining the pre-built container images, see the Support document Oracle Identity and Access Management 12.2.1.4 Products with Kubernetes.

Oracle HTTP Server will be installed outside of the Kubernetes cluster. Therefore, a traditional software distribution is required.

Oracle Software Distributions Used in this Guide

Table 8-1 lists the distributions used in this guide.

For general information about how to obtain Oracle HTTP Server software, see Obtaining Product Distributions in Planning an Installation of Oracle Fusion Middleware.

For more specific information about locating and downloading specific Oracle Fusion Middleware products, see the Oracle Fusion Middleware Download, Installation, and Configuration Readme Files on OTN.

Note:

The information in this guide is meant to complement the information contained in the Oracle Fusion Middleware certification matrixes. If there is a conflict of information between this guide and the certification matrixes, then the information in the certification matrixes must be considered the correct version, as they are frequently updated.

Table 8-1 Oracle Fusion Middleware Distributions to Download for Installing and Configuring the Enterprise Deployment Topology

Distribution Image Name Tag/Release Description

Oracle HTTP Server 12c

fmw_12.2.1.4.0_ohs_linux64.bin

NA

Download this distribution to install the Oracle HTTP Server software on the web tier.

Oracle WebLogic Operator

weblogic-kubernetes-operator

4.1.8

Used to configure the WebLogic Operator, which is used to configure the domain, and if necessary, run RCU.

Oracle Unified Directory 12c

oracle/oud

12.2.1.4-jdk8-ol7-220411.1613

Download this version or later and install on each Kubernetes worker node or load into a container registry.

Oracle Unified Directory Services Manager

oracle/oudsm

12.2.1.4-jdk8-ol7-220411.1608

Download this version or later and install on each Kubernetes worker node or load into a container registry.

Oracle Access Manager 12c

oracle/oam

12.2.1.4-jdk8-ol7-220418.0839

Download this version or later and install on each Kubernetes worker node or load into a container registry.

Oracle Identity Governance 12c

oracle/oig

12.2.1.4-jdk8-ol7-220420.0828

Download this version or later and install on each Kubernetes worker node or load into a container registry.

Oracle Identity Role Intelligence

oiri

oiri-ui

oiri-ding

oiri-cli

12.2.1.4.220429

Download this version or later and install on each Kubernetes worker node or load into a container registry.

Oracle Advanced Authentication

oaa-mgmt

oaa-svc

oaa-policy

oaa-admin

oaa-spui

oaa-factor-fido

oaa-factor-totp

oaa-factor-sms

oaa-factor-email

oaa-factor-yotp

oaa-factor-push

oaa-factor-kba

oaa-drss

risk-engine

risk-cc

12.2.1.4.1_20220419

Download this version or later and install on each Kubernetes worker node or load it into a container registry.

Note:

  • The tags in this table show the base release. You should use the latest image, which contains the most recent Bundle Patch. A tag reflects the version you are using. For example: 12.2.1.4.0-8-ol7-210721.0755.
  • Oracle Advanced Authentication is also dependent on the following images being available in your container registry:
    • docker.io/library/alpine:latest
    • container-registry.oracle.com/database/instantclient:12.2.0.1
    • container-registry.oracle.com/os/oraclelinux:8-slim
  • The commands to download and tag these images are as follows:
    podman pull container-registry.oracle.com/database/instantclient:12.2.0.1
    podman tag container-registry.oracle.com/database/instantclient:12.2.0.1 <container_image_registry>/shared/oracle/database-instantclient:12.2.0.1
    podman pull container-registry.oracle.com/os/oraclelinux:8-slim
    podman tag container-registry.oracle.com/os/oraclelinux:8-slim <container_image_registry>/shared/oracle/linux:8-slim

If you are using Docker, then replace podman with docker in the above commands.

About Container Image Names

Container images have names in a specific format depending on whether you have pre-loaded them or pulled them from a container registry.

In the subsequent chapters, some procedures/instructions require you to provide the names of the container images. The image name depends on whether you are using a container registry or staging the images locally. The following description explains how you can determine the container image name to use for your deployments.

Typically, a container image name has the following format:
<REPOSITORY_NAME>/<IMAGE_NAME>:<IMAGE_VERSION>

If you have pre-loaded your images using the steps described in Staging Container Images, the image name will have this format: oracle/oam:12.2.1.4.0-8-ol7-210721.0755.

In Oracle Cloud Native Environment, the format is localhost/oracle/oam:12.2.1.4.0-8-ol7-210721.0755

If you are pulling your image from a container registry, the container name will be preceeded with the repository name. Assuming that your resgistry is iad.ocir.io/mytenancy, your image name will be iad.ocir.io/mytenancy/oracle/oam:12.2.1.4.0-8-ol7-210721.0755.

To determine the exact image name, you can use the following command, where your image has been pre-loaded:
docker images
OR
sudo podman images

Obtaining Software from the Oracle Container Registry

Before you download container images from the Oracle Container Registry, you must first log in to the Oracle Container Registry using your support credentials and accept the license agreements for each container you want to deploy.

After you accept the licence agreement, you can pull the images directly from the Oracle Container Registry. Ensure that you pull the images with the latest bundled patches applied.

You can use these images in the following ways:

Downloading Images from a Container Registry

If you use a container registry, you can pull images from the registry either on-demand or in advance. Pulling images in advance results in a faster deployment but means that you will have the images available on all worker nodes regardless of whether you are running a container on that worker node or not.

Note:

The latest images in Oracle container registry is only available after you have logged into the registry and is available with a suffix of _cpu. For example, the latest oam images are available in oam_cpu.

To download the images from a container registry, you should execute the commands on each worker node.

Pulling the Images to Docker

To download the images to Docker:

  1. Log in to the container registry using the command:
    docker login registryname
    For example:
    docker login container-registry.oracle.com
  2. Pull the image using a command similar to:
    docker pull container-registry.oracle.com/middleware/oam_cpu:12.2.1.4-jdk8-ol8-<date-stamp>

    For example:

    docker pull container-registry.oracle.com/middleware/oam_cpu:12.2.1.4-jdk8-ol8-240415

Pulling the Images to CRI-O

You have two options to download the images to CRI-O:

Option 1: Using podman

If you have podman installed on your worker nodes, you can use podman to load the images.

Note:

You should run podman as the root user.
  1. Log in to the container registry using the command:
    sudo podman login registryname
    For example:
    sudo podman login container-registry.oracle.com
  2. Pull the image using a command similar to:
    sudo podman pull container-registry.oracle.com/middleware/oam_cpu:12.2.1.4-jdk8-ol8-<date-stamp>

    For example:

    sudo podman pull container-registry.oracle.com/middleware/oam_cpu:12.2.1.4-jdk8-ol8-240415
Option 2: Using crictl
If you do not have podman installed on your worker nodes, for example in OKE environments, you can load the images using the crictl command:
crictl pull --creds username:password repository/image:version

Where username and password are the name of the user and the associated password that you use to access the registry.

For example:
crictl pull --creds myuser:password container-registry.oracle.com/middleware/oam_cpu:12.2.1.4-jdk8-ol8-240415

Oracle Advanced Authentication

If you have downloaded the OAA images from Oracle Support rather than via the container registry you will have a downloaded zip file.

To load the images containers in a zip file, first unzip the file using the following command:

unzip oaa-install-<REL>.zip

You will get an image archive file called /oaa-install/oaa-<REL>.tar.

This file can be staged using the commands in Staging Container Images.

Staging Container Images

If you upload images to a container registry or use manually staged images, you have to stage those images in the local container repository. If you are using your own container registry you must first stage the images in a local repository so that you can upload them to your registry. You can perform this task on any host that has access to the docker or podman commands. The host does not need to be a part of the Kubernetes cluster.

If you are using locally staged images, each worker node should have access to all the container images in your deployment. Kubernetes decides on which worker node it wants to start a container. Therefore, you should have the image available on all hosts. If you are using locally staged images, you can use these instructions to load the images into each worker node manually. However, if you are using a container registry but want to load the image to the worker nodes ahead of time, you should manually pull the image from the container registry to each worker node.

Staging Images in Docker

If you are using Docker as your container repository, you must stage the Oracle Identity and Access Manager container images in the Docker repository on each of the Kubernetes worker nodes.

If you want to store your container images in a container registry, see Using an OCI Container Registry.

To stage the container images:

  1. Download the prebuilt container image from Oracle Support.
  2. Load the images into the local container repository using the downloaded tar file by running the following command:

    Note:

    If you are manually staging the images on each worker host, you should repeat this step on every worker host.
    docker load < container_image_file
    For example:
    docker load < oracle_oig_122140.PSU2020July.tar

    Note:

    If you are loading a multi-image archive file such as the file used by Oracle Advanced Authentication, this command will load multiple images into the local repository.
  3. After the image is loaded, ensure that the container images are available by using the following command:
    docker images
    The output appears as the sample shown below:
    
    REPOSITORY                          TAG                             IMAGE ID         CREATED          SIZE
    oracle/oud                          12.2.1.4.0                      1786d05b19ce     3 months ago     998MB
    oracle/oud                          12.2.1.4.0-201209.2159.080      1786d05b19ce     3 months ago     998MB
    oracle/oig                          12.2.1.4.0                      285184517ac6     3 months ago     5.02GB
    oracle/oig                          12.2.1.4.0-201116.0936.300      285184517ac6     3 months ago     5.02GB
    oracle/oudsm                        12.2.1.4.0                      8bbcb8e034e5     4 months ago     2.77GB
    oracle/oudsm                        12.2.1.4.0-201116.1247.350      8bbcb8e034e5     4 months ago     2.77GB
    oracle/oam                          12.2.1.4.0                      9a75c5cd0faa     4 months ago     3.39GB
    oracle/oam                          12.2.1.4.0-201116.0940.060      9a75c5cd0faa     4 months ago     3.39GB
    weblogic-kubernetes-operator        3.3.0                           7b26071abce6     7 months ago     388MB
    oracle/weblogic-kubernetes-operator 3.3.0                           7b26071abce6     7 months ago     388MB
    k8s.gcr.io/kube-proxy               v1.18.4                         718fa77019f2     9 months ago     117MB
    k8s.gcr.io/kube-scheduler           v1.18.4                         c663567f869e     9 months ago     95.3MB
    k8s.gcr.io/kube-apiserver           v1.18.4                         408913fc18eb     9 months ago     173MB
    k8s.gcr.io/kube-controller-manager  v1.18.4                         e8f1690127c4     9 months ago     162MB
    alpine                              latest                          a24bb4013296     10 months ago    5.57MB
    calico/node                         v3.14.1                         04a9b816c753     10 months ago    263MB
    calico/pod2daemon-flexvol           v3.14.1                         7f93af2e7e11     10 months ago    112MB
    calico/cni                          v3.14.1                         35a7136bc71a     10 months ago    225MB
    calico/kube-controllers             v3.14.1                         ac08a3af350b     10 months ago    52.8MB
    k8s.gcr.io/pause                    3.2                             80d28bedfe5d     13 months ago    683kB
    k8s.gcr.io/coredns                  1.6.7                           67da37a9a360     14 months ago    43.8MB
    k8s.gcr.io/etcd                     3.4.3-0                         303ce5db0e90     17 months ago    288MB

Staging Images in CRI-O

If you are using CRI-O as your container repository, the standard repository for Oracle Cloud Native Environment deployments, you must stage the Oracle Identity and Access Manager container images in the CRI-O repository on each Kubernetes worker node.

If you want to store your container images in a container registry, see Using an OCI Container Registry.

Note:

  • The commands in this section rely on the podman command. By default, this command is available on the Oracle Cloud Native Environment. However, you should manually install the command into the OKE environments which use CRI-O (Release 1.20+). You should run the podman commands as the root user.
  • If you are using a multi-image archive files such as the file used by Oracle Advanced Authentication, you should use the latest release of podman. The release provided with OCNE 1.3 does not support multiple-image archives.

To stage the container images:

  1. Download the prebuilt container image from Oracle Support.
  2. Load the images into the local container repository using the downloaded tar file by running the following command:

    Note:

    If you are manually staging the images on each worker host, you should repeat this step on every worker host.
    podman load < container_image_file
    For example:
    podman load < oracle_oig_122140.PSU2020July.tar

    Note:

    If you are loading a multi-image archive file such as the file used by Oracle Advanced Authentication, this command will load multiple images into the local repository.
  3. After the image is loaded, ensure that the container images are available by using the following command:
    podman images

    Note:

    Oracle Cloud Native Environment has a different directory container images for each user. The Kubernetes engine for Oracle Cloud Native Environment uses the container store specified in the root user's configuration. Loading images using any user other than the root user will not make those images visible to Kubernetes. To ensure that you satisfy this requirement, podman commands must be run by the root user.

    As an extra validation, use the following command as a root user to ensure that the system can see your images:
    crictl images

    This command should be run on a worker node.

    The output appears as the sample shown below:
    
    REPOSITORY                          TAG                             IMAGE ID         CREATED          SIZE
    oracle/oud                          12.2.1.4.0                      1786d05b19ce     3 months ago     998MB
    oracle/oud                          12.2.1.4.0-201209.2159.080      1786d05b19ce     3 months ago     998MB
    oracle/oig                          12.2.1.4.0                      285184517ac6     3 months ago     5.02GB
    oracle/oig                          12.2.1.4.0-201116.0936.300      285184517ac6     3 months ago     5.02GB
    oracle/oudsm                        12.2.1.4.0                      8bbcb8e034e5     4 months ago     2.77GB
    oracle/oudsm                        12.2.1.4.0-201116.1247.350      8bbcb8e034e5     4 months ago     2.77GB
    oracle/oam                          12.2.1.4.0                      9a75c5cd0faa     4 months ago     3.39GB
    oracle/oam                          12.2.1.4.0-201116.0940.060      9a75c5cd0faa     4 months ago     3.39GB
    weblogic-kubernetes-operator        3.3.0                           7b26071abce6     7 months ago     388MB
    oracle/weblogic-kubernetes-operator 3.3.0                           7b26071abce6     7 months ago     388MB
    k8s.gcr.io/kube-proxy               v1.18.4                         718fa77019f2     9 months ago     117MB
    k8s.gcr.io/kube-scheduler           v1.18.4                         c663567f869e     9 months ago     95.3MB
    k8s.gcr.io/kube-apiserver           v1.18.4                         408913fc18eb     9 months ago     173MB
    k8s.gcr.io/kube-controller-manager  v1.18.4                         e8f1690127c4     9 months ago     162MB
    alpine                              latest                          a24bb4013296     10 months ago    5.57MB
    calico/node                         v3.14.1                         04a9b816c753     10 months ago    263MB
    calico/pod2daemon-flexvol           v3.14.1                         7f93af2e7e11     10 months ago    112MB
    calico/cni                          v3.14.1                         35a7136bc71a     10 months ago    225MB
    calico/kube-controllers             v3.14.1                         ac08a3af350b     10 months ago    52.8MB
    k8s.gcr.io/pause                    3.2                             80d28bedfe5d     13 months ago    683kB
    k8s.gcr.io/coredns                  1.6.7                           67da37a9a360     14 months ago    43.8MB
    k8s.gcr.io/etcd                     3.4.3-0                         303ce5db0e90     17 months ago    288MB

Logging in to GitHub

The examples below require that you pull images and scripts from github.com, a public repository. To successfully pull images from GitHub, should log in to the repository.

You can log in to GitHub in one of two ways:

  • By performing a manual login on each host, which requires access to the repository.
  • By creating a Kubernetes secret, which grants access to the Kubernetes cluster.

Creating a Secret to Access GitHub

If you need to deploy containers from GitHub, you should create a token that authenticates you with the container registry.

Creating a GitHub Token

This section assumes that you have a GitHub account. If you do not have a GitHub account, you must create one before continuing

To create a GitHub token:

  1. Access the URL https://github.com/settings/tokens. You will be prompted to log in to your account.
  2. Ensure that Personal Access Tokens is selected and click Generate New Token.
  3. Specify a name for the token. For example: Image downloads.
  4. Set an expiry date for the token.
  5. In the Select scopes section:
    • Select repo and under it, select public_repo.
    • Select read:packages.
  6. Click Generate Token.

Make a note of the generated token. You will not be able to find it again.

Creating a Kubernetes Secret

After creating a GitHub token, you can now create a Kubernetes secret that will allow you to pull images from GitHub. The following command will create a Kubernetes secret called 'github' in the default namespace:

kubectl create secret docker-registry github --docker-server=ghcr.io --docker-username=mygituser --docker-password="mytoken"

Logging in to GitHub Manually

To log in to GithHub manually on each worker host, use the following commands.

For Docker
docker login ghcr.io

When prompted, specify your user name and the token you created earlier. See Creating a GitHub Token.

For Cri-O
sudo  podman login ghcr.io

When prompted, specify your user name and the token you created earlier.

Staging the WebLogic Operator for Kubernetes

Use the WebLogic Operator for Kubernetes to deploy Oracle Access Manager or Oracle Identity Governance. There are two parts to the WebLogic Operator: the WebLogic Operator Container Image and the WebLogic Operator deployment scripts.

The WebLogic Operator for Kubernetes is available from oracle.github.io. Sign in to GitHub to download the container image.

Staging the Oracle WebLogic Kubernetes Image in Docker

To download the Docker image, use the following commands:
docker pull ghcr.io/oracle/weblogic-kubernetes-operator:<VERSION>
docker tag ghcr.io/oracle/weblogic-kubernetes-operator:<VERSION> weblogic-kubernetes-operator:<VERSION>
For example: To stage the image on Docker, use the following commands:
docker pull ghcr.io/oracle/weblogic-kubernetes-operator:3.3.0
docker tag ghcr.io/oracle/weblogic-kubernetes-operator:<VERSION> weblogic-kubernetes-operator:3.3.0

You should stage the Operator on all the worker nodes or place it into a registry that is accessible by the cluster.

Staging the Oracle WebLogic Kubernetes Image in CRI-O

To download the container image, use the following command:
sudo podman pull ghcr.io/oracle/weblogic-kubernetes-operator:<VERSION>
sudo podman tag ghcr.io/oracle/weblogic-kubernetes-operator:<VERSION> weblogic-kubernetes-operator:<VERSION>

For example: To stage the image on CRI-O, use the following command:

sudo podman pull ghcr.io/oracle/weblogic-kubernetes-operator:3.3.0
sudo podman tag ghcr.io/oracle/weblogic-kubernetes-operator:3.3.0 weblogic-kubernetes-operator:3.3.0

Note:

You should use the podman commands as the root user.

You should stage the Operator on all the worker nodes or place it into a registry that is accessible by the cluster.

Staging the Code Repository

Oracle provides a sample code repository to deploy Oracle Identity and Access Management in Kubernetes. The procedures explained in this guide use the sample code repository extensively. Download the sample code repository to a temporary work directory on your configuration host.

A configuration host is any host in your cluster which can run helm and kubectl commands. For example, in an OCI installation, this host could be a bastion host. For an Oracle Cloud Native Environment installation, it could be the operator node or any of the control plane hosts. Alternatively, you may have defined a specific host for the purpose.

The sample code is available from GitHub. You may need to create an account and log in if you do not have access.

To download the scripts, log in to GitHub and perform the following steps:

  1. Create a temporary work directory on the configuration host:
    mkdir <work_dir>
    For example:
    mkdir /workdir
  2. Change directory to this location:
    cd /workdir
  3. Download the samples using the command:
    git clone https://github.com/oracle/fmw-kubernetes.git

These commands create a directory called fmw-kubernetes, where all of the sample files are stored. You can use the files directly from this location or copy the files you need to another temporary working directory. To keep everything separate, the procedures explained in this guide recommend copying the files to product working directories. For example: /workdir/OAM. However, it is optional.

Note:

This code repository also includes sample automation scripts for deploying Oracle Identity and Access Management as per the instructions provided in this guide.

Downloading the Oracle Connector Bundle for Oracle Identity Governance

If you are planning to integrate Oracle Identity Governance with outside systems, you have to download the appropriate connector bundle. In an enterprise deployment, the LDAP connector is used to integrate with Oracle Unified Directory (OUD) and Oracle Internet Directory (OID).

Download the latest version of the Oracle Connector bundle from Oracle Identity Manager Connector Downloads.