This method/pattern is our opinionated implementation of the GitOps principles, using the latest and greatest tooling available, to enable the hitting of one big red button (figuratively) to start provisioning a platform that provides Cluster and Virtual Machine Provisioning capabilities, Governance and policy management, observability of Clusters and workloads and finally deployment of applications, such as IBM Cloud Paks, all within a single command*.
- Codified, Repeatable and Auditable.
*Disclaimer, may actually be more than just one command to type. 😉
The method/pattern is not intended to be used straight into Production, and a lot of assumptions have been made when putting this together. It's main intention is to show the Art of the Possible
, but it can be used as base to roll your own.
Whilst all efforts have been made to provide a complete One Touch Provisioning
method/pattern, it may not suit every environment and your mileage may vary.
This asset has been built on the shoulders of giants and leverages the great work and effort undertaken by the Cloud Native Toolkit - GitOps Production Deployment Guide, IBM Garage TSA and Red Hat Communities of Practice teams. Without these efforts, then this asset would have struggled to get off the ground.
The reference architecture for this GitOps workflow can be found here.
- One Touch Provisioning across Multi Cloud
- Elevator Pitch
- Table of contents
- Note
- Pattern Capabilities
- Pre-requisites
- Overview of Git Repositories
- Setup git repositories
- Install and configure OpenShift GitOps
- Bootstrap the OpenShift cluster
- Managing OpenShift Clusters via OpenShift GitOps
- Managing IaaS Providers within IBM Infrastructure Automation
- Deployment of Cloud Paks through OpenShift GitOps
This repository provides an opinionated point of view on how tooling and principles such as Terraform
, Ansible
and GitOps
can be used to manage the infrastructure, services and application layers of OpenShift/Kubernetes based systems. It takes into account the various personas interacting with the system and accounts for separation of duties.
It is assumed that you have already configured the compute, networks, storage, Security Groups, Firewalls, VPC, etc to enable the platform to be deployed. The asset will not perform those actions for you, and it will fail if you attempt to deploy it without those all pre-configured.
This respository is not intended to be a Step-by-Step Guide and some prior knowledge in OpenShift/Kubernetes/VM Provisioning is expected.
-
The pattern will deploy an opionated OpenShift Advanced Cluster Management - Hub running OpenShift GitOps (ArgoCD), OpenShift Pipelines (Tekton), OpenShift Data Foundation (Rook.io), Ansible Automation Platform (Additional Subscription required), Red Hat Advanced Cluster Management (Open Cluster Management), Red Hat Advanced Cluster Security (Stackrox), Quay Registry, Quay Container Security, OpenShift Virtualisation (KubeVirt), IBM Infrastructure Automation from the IBM Cloud Pak for AIOps 3.2, SealedSecrets, Instana, Turbonomics and RHACM Observability.
-
Deployment and management of Managed OpenShift Clusters via OpenShift GitOps (everything is Infrastructure as Code) onto Amazon Web Services, Microsoft Azure, IBM Cloud, Google Cloud Platform, VMWare vSphere and Bare-metal environments, including Single Node OpenShift onto On Premise hosts. Allowing Managed OpenShift Clusters to be treated as "Cattle" not "Pets".
-
Deployed Managed OpenShift Clusters on AWS, Azure and GCP can be Hibernated when not in-use to reduce the amount of resources consumed on your provider, potentially lowering costs.
-
Configured to Auto-Discover OpenShift Clusters from provided Red Hat OpenShift Cluster Manager credentials, and provide the opportunity to import the OpenShift clusters as Managed Clusters and automatically configure them into the OpenShift GitOps Cluster.
-
Centralised OpenShift GitOps for deployment of Applications across any Managed OpenShift Cluster. View all deployed Applications across the entire fleet of OpenShift Clusters, regardless of Clusters location (i.e. AWS, GCP, on-premise etc).
-
Automatically apply policies and governance to ALL Clusters within Red Hat Advanced Cluster Management, regardless of Clusters location.
-
Hub Cluster can self-host Instana Virtual Machine using OpenShift Virtualisation and managed via OpenShift GitOps, or automatically deployed to an IaaS environment using IBM Infrastructure Automation.
-
Can be configured to automatically connect to IaaS environments, enable deployment of Virtual Machines via IBM Infrastructure Automation and OpenShift Pipelines.
-
Can be configured to automatically deploy applications to Managed Clusters via OpenShift GitOps. An example provided will deploy IBM Cloud Pak for Integration (utilising full GitOps Principles) to Managed Clusters.
- Zero Touch Provisioning of Managed OpenShift Clusters to Bare-metal nodes (think Edge deployments)
We leverage two Open Source technologies to underpin the functionality within this pattern. One is ArgoCD (aka OpenShift Gitops) and the other is Open Cluster Management (aka Red Hat Advanced Cluster Management or RHACM).
To fully appreciate the terminology used within RHACM and more so within the pattern, we will spend a few moments helping provide some context.
RHACM is built around a Hub and Spoke architecture. With the Hub Cluster, running RHACM, providing cluster and application lifecycle along with other aspects such as Governance and Observability of any Spoke Clusters under it's management.
The diagram below shows a typical Hub and Spoke deployment over various clouds.
We leverage several repositories to make up the pattern. These may seem as overwhelming to begin with, but there is some method and thoughts behind them. We approached this pattern with scale in mind and running a single mono repository with all the manifests quickly showed that it does not lend itself to scale that well.
We really want a method that allows a decentralised approach to scale. One where teams are working together across the entire pattern, with some guard-rails, to enable rapid deployment of OpenShift Clusters, Applications and Policies at scale.
Taking the Kubernetes Ownership Model, we looked at which personas would typically contribute and have ownership over a repository and separated a single mono repository into several to reflect that. An example would be a Platform team that primarily contributes and has ownership over a repository that defines the infrastructure-related components of a Kubernetes Cluster, e.g. namespaces, machinesets, ingress-controllers, storage etc, they may also be best placed to contribute and own a repository that defines how OpenShift Clusters are created on different Cloud Providers. Similar examples can be given for a set of Services which support Application developers, where we would separate these into their own repositories, again owned and primarily contributed by a Services team. A Risk/Security team owning and primarily contributing to a Policies repository is another example.
We then look to enable all these repositories as centralised repositories, either at an organisational, business or product level, where each OpenShift Cluster, including the Hub Cluster, is deployed with OpenShift GitOps (aka ArgoCD) and bootstrapped via a single repository, within which hold ArgoCD Applications that point back to these centralised repositories.
The advantages of this approach is a reduction of duplicated code and ensures that deployed OpenShift Clusters all meet or share the same configuration, where applicable. For example node sizes, autoscaling, networking etc or RBAC policies that are important for overall governance and security. As a result, the desired configurations are fully replicated across the Clusters, regardless of where they land, Public, Private, On-Prem etc.
Manually identifying drift and maintaining conformance across different clusters within different Clouds as they scale is, of course, not a viable alternative, so this approach lends itself very well.
By utilising a shared and decentralised approach, this has the added advantage of lowering the barrier to entry (e.g., a Developer needs to understand how we are deploying a cluster, they can read the Git Repository without needing to delay the Platform team), lowering the cost for change and Opening up Opportunities to Innovate.
For our pattern, we've termed the above 1 + 5 + n Git Repositories.
-
1 Repository being the Red Hat Advanced Cluster Management Hub Cluster
-
5 Repositories (Infrastructure, Services, Applications, Clusters, Policies) being common / shared
-
n Repository being the repository that you will use to bootstrap your deployed managed OpenShift Cluster
By using a common set of repositories we can quickly scale out Cluster Deployments and reducing the risk of misconfiguration and drift.
As we mature this method/pattern, we have seen different use-cases where the need for a different Git Repository organisation has been required.
Our view by leveraging the 1 + 5 + n Git Repositories it allows more flexability to what is deployed into cluster and works better at scale. The Line of Business, Product team, end-users etc can have full control via their own ArgoCD instance which is configured against a Git repository they control. This works for privacy and security as they control who can and cannot see the objects within their repository. We'll term this a self-managed Cluster
. This may suit a team which has experience in OpenShift, clearly understand their requirements, and are comfortable managing the environment themselves.
However there are occassions where there maybe a requirement for a Cluster to be provisioned and the end-users wish for a more managed cluster
. They understand their applications, and prefer to just focus on those aspects. They are happy to commit to a Git Repository that they do not own and prefer that management of the Cluster is owned by another team. In this scenario, it would make sense to manage the cluster and its applications via the Hub Repository alone. Think of this as a shared-multi-tenancy
operational model. Everyone with access to the Git repository can see all objects within. To demo this model, we've left example folder structures for the managed
use-case. This can be found in 0-bootstrap/spokeclusters/
.
It should be noted that these are just a few methods to manage your environments, and we encourage you to choose a method that works for you.
Minimum OpenShift v4.8+ is required.
Firstly, build a "bare-bones" Red Hat OpenShift cluster using either IPI (Installer Provisioned Infrastructure), UPI (User Provisioned Infrastructure) methods or a Managed OpenShift offering like AWS ROSA, Azure ARO, IBM Cloud - ROKS.
Leveraging the work undertaken by the Cloud Native Toolkit team, you can utilise the following Github repositories to assist you with your UPI install of OpenShift.
- Azure
- AWS
- VMWare
- IBM Cloud VMWare Cloud Director
- GCP
- IBM Power Systems - PowerVC
- IBM Power Systems - HMC
- IBM Cloud PowerVS
-
Install the OpenShift CLI oc (version 4.9+) . The binary can be downloaded from the Help menu from the OpenShift Console.
-
Install helm and kubeseal from brew.sh
brew install kubeseal && brew install helm
-
Log in from a terminal window.
oc login --token=<token> --server=<server>
- An
IBM Entitlement Key
is required to pull IBM Cloud Pak specific container images from the IBM Entitled Registry.
To get an entitlement key:
- Log in to MyIBM Container Software Library with an IBMid and password associated with the entitled software.
- Select the View library option to verify your entitlement(s).
- Select the Get entitlement key to retrieve the key.
-
Create a Secret containing the entitlement key within the
ibm-infra-automation
namespace.oc new-project ibm-infra-automation || true oc create secret docker-registry ibm-entitlement-key -n ibm-infra-automation \ --docker-username=cp \ --docker-password="<entitlement_key>" \ --docker-server=cp.icr.io \ --docker-email=myemail@ibm.com
-
The following set of Git repositories will be used for our GitOps workflow.
-
Main GitOps repository (https://github.com/one-touch-provisioning/otp-gitops): This repository contains all the ArgoCD Applications for the
infrastructure
,services
andapplication
layers. Each ArgoCD Application will reference a specific K8s resource (yaml resides in a separate git repository), contain the configuration of the K8s resource, and determine where it will be deployed into the cluster. -
Infrastructure GitOps repository (https://github.com/one-touch-provisioning/otp-gitops-infra): Contains the YAMLs for cluster-wide and/or infrastructure related K8s resources managed by a cluster administrator. This would include
namespaces
,clusterroles
,clusterrolebindings
,machinesets
to name a few. -
Services GitOps repository (https://github.com/one-touch-provisioning/otp-gitops-services): Contains the YAMLs for K8s resources which will be used by the
application
layer. This could includesubscriptions
for Operators, YAMLs of custom resources provided, or Helm Charts for tools provided by a third party. These resource would usually be managed by the Administrator(s) and/or a DevOps team supporting application developers. -
Apps GitOps repository (https://github.com/one-touch-provisioning/otp-gitops-apps): Contains the YAMLs for K8s resources to deploy
applications
. -
Clusters GitOps repository (https://github.com/one-touch-provisioning/otp-gitops-clusters): Contains the YAMLs for K8s resources to deploy
OpenShift Clusters
. -
Policies GitOps repository (https://github.com/one-touch-provisioning/otp-gitops-policies): Contains the YAMLs for K8s resources to deploy
Policies
to clusters.
-
-
Create a new GitHub Organization using instructions from this GitHub documentation.
-
From each template repository, click the
Use this template
button and create a copy of the repository in your new GitHub Organization. Note: Make sure the repositories are public so that ArgoCD can access them. -
(Optional) OpenShift GitOps can leverage GitHub tokens. Many users may wish to use private Git repositories on GitHub to store their manifests, rather than leaving them publically readable. The following steps will need to repeated for each repository.
-
Generate GitHub Token
-
Visit https://github.com/settings/tokens and select "Generate new token". Give your token a name, an expiration date and select the scope. The token will need to have repo access.
-
Click on "Generate token" and copy your token! You will not get another chance to copy your token and you will need to regenerate if you missed to opportunity.
-
-
Generate OpenShift GitOps Namespace
oc apply -f setup/setup/0_openshift-gitops-namespace.yaml
-
Generate Secret
-
export the GitHub token you copied earlier.
$ export GITHUB_TOKEN=<insert github token> $ export GIT_ORG=<git organisation>
-
Create a secret that will reside within the
openshift-gitops
namespace.$ mkdir repo-secrets $ cat <<EOF > setup/ocp/repo-secrets/otp-gitops-repo-secret.yaml apiVersion: v1 kind: Secret metadata: name: otp-gitops-repo-secret namespace: openshift-gitops labels: argocd.argoproj.io/secret-type: repository stringData: url: https://github.com/${GIT_ORG}/otp-gitops password: ${GITHUB_TOKEN} username: not-used EOF
-
Repeat the above steps for
otp-gitops-infra
,otp-gitops-services
,otp-gitops-apps
,otp-gitops-clusters
andotp-gitops-policies
repositories.
-
-
Apply Secrets to the OpenShift Cluster
oc apply -f setup/ocp/repo-secrets/ rm -rf setup/ocp/repo-secrets
-
-
Clone the repositories locally.
mkdir -p <gitops-repos> cd <gitops-repos> # Example: set default Git org for clone commands below GIT_ORG=one-touch-provisioning # Clone using SSH git clone git@github.com:$GIT_ORG/otp-gitops.git git clone git@github.com:$GIT_ORG/otp-gitops-infra.git git clone git@github.com:$GIT_ORG/otp-gitops-services.git git clone git@github.com:$GIT_ORG/otp-gitops-apps.git git clone git@github.com:$GIT_ORG/otp-gitops-clusters.git git clone git@github.com:$GIT_ORG/otp-gitops-policies.git
-
Update the default Git URl and branch references in your
otp-gitops
repository by running the provided script./scripts/set-git-source.sh
script.cd otp-gitops GIT_ORG=<GIT_ORG> GIT_BRANCH=master ./scripts/set-git-source.sh git add . git commit -m "Update Git URl and branch references" git push origin master
- Red Hat OpenShift GitOps uses Argo CD, an open-source declarative tool, to maintain and reconcile cluster resources.
-
Install the OpenShift GitOps Operator and create a
ClusterRole
andClusterRoleBinding
.cd setup oc apply -f setup while ! oc wait crd applications.argoproj.io --timeout=-1s --for=condition=Established 2>/dev/null; do sleep 30; done while ! oc wait pod --timeout=-1s --for=condition=Ready -l '!job-name' -n openshift-gitops > /dev/null; do sleep 30; done
-
Create a custom ArgoCD instance with custom checks. To customise which health checks, comment out those you don't need in
setup/argocd-instance/kustomization.yaml
.oc apply -k argocd-instance while ! oc wait pod --timeout=-1s --for=condition=ContainersReady -l app.kubernetes.io/name=openshift-gitops-cntk-server -n openshift-gitops > /dev/null; do sleep 30; done
Note: We use a custom openshift-gitops-repo-server image to enable the use of Plugins within OpenShift Gitops. This is required to allow RHACM to utilise the Policy Generator plugin. The Dockerfile can be found here: https://github.com/one-touch-provisioning/otp-custom-argocd-repo-server.
-
If using IBM Cloud ROKS as a Hub Cluster, you will need to configure TLS.
scripts/patch-argocd-tls.sh
-
(Optional) Create a console link to OpenShift GitOps
export ROUTE_NAME=openshift-gitops-cntk-server export ROUTE_NAMESPACE=openshift-gitops export CONSOLE_LINK_URL="https://$(oc get route $ROUTE_NAME -o=jsonpath='{.spec.host}' -n $ROUTE_NAMESPACE)" envsubst < <(cat setup/4_consolelink.yaml.envsubst) | oc apply -f -
If you are running a managed OpenShift cluster on IBM Cloud, you can deploy OpenShift Data Foundation as an add-on.
On AWS, Azure, GCP and vSphere run the following script to configure the machinesets, infra nodes and storage definitions for the Cloud
you are using for the Hub Cluster
./scripts/infra-mod.sh
- The bootstrap YAML follows the app of apps pattern.
-
Retrieve the ArgoCD/GitOps URL and admin password and log into the UI
oc get route -n openshift-gitops openshift-gitops-cntk-server -o template --template='https://{{.spec.host}}' # Passsword is not needed if Log In via OpenShift is used (default) oc extract secrets/openshift-gitops-cntk-cluster --keys=admin.password -n openshift-gitops --to=-
-
The resources required to be deployed for this asset have been pre-selected, and you should just need to clone the
otp-gitops
repository in your Git Organization if you have not already done so. However, you can review and modify the resources deployed by editing the following.0-bootstrap/hub/1-infra/kustomization.yaml 0-bootstrap/hub/2-services/kustomization.yaml
If you choose to disable any Infrastructure or Services resources before the Initial Bootstrap, you will need to re-commit those changes back to your Git repository, otherwise they will not be picked up by OpenShift GitOps.
-
Deploy the OpenShift GitOps Bootstrap Application.
oc apply -f 0-bootstrap/hub/bootstrap.yaml
-
Its recommended to deploy the Infrastructure components, then the Service Componenets once complete. ArgoCD Sync waves are used to managed the order of manifest deployments, but we have seen occassions where applying both the Infrastructure and Services layers at the same time can fail. YMMV.
Once the Infrastructure layer has been deployed, update the 0-bootstrap/hub/kustomization.yaml
manifest to enable the Services layer and commit to Git. OpenShift GitOps will then automatically deploy the Services.
resources:
- 1-infra/1-infra.yaml
## Uncomment 2-services/2-services.yaml once
## 1-infra/1-infra.yaml has been completed
- 2-services/2-services.yaml
## Uncomment to deploy Clusters and Applications
## Must be done after all steps for 1-infra & 2-services
## have been completed.
# - 3-clusters/3-clusters.yaml
# - 4-apps/4-apps.yaml
# - 5-policies/5-policies.yaml
After Infrastructure Automation and RHACM have been installed successfully - all apps are synced in ArgoCD.
The route to IBM Infrastructure Automation is
oc -n ibm-common-services get route cp-console --template '{{.spec.host}}'
To use Infrastructure Automation, use the following users with the password Passw0rd
.
POD=$(oc -n ldap get pod -l app=ldap -o jsonpath="{.items[0].metadata.name}")
oc -n ldap exec $POD -- ldapsearch -LLL -x -H ldap:// -D "cn=admin,dc=ibm,dc=com" -w Passw0rd -b "dc=ibm,dc=com" "(memberOf=cn=operations,ou=groups,dc=ibm,dc=com)" dn
The default admin
password is:
oc -n ibm-common-services get secret platform-auth-idp-credentials -o jsonpath='{.data.admin_password}' | base64 -d
The route to Red Hat Advanced Cluster Management is
oc -n open-cluster-management get route multicloud-console --template '{{.spec.host}}'
Within this asset we treat Managed Clusters as OpenShift GitOps Applications. This allows us to Create, Destroy, Hibernate and Import Managed Clusters into Red Hat Advanced Cluster Manmagement via OpenShift GitOps.
We've now simplied the life-cycling of OpenShift Clusters on AWS, Google Cloud and Azure via the use of Cluster Pools and ClusterClaims.
Cluster Pools allows you pre-set a common cluster configuration and RHACM will take that configuration and apply it to each Cluster it deploys from that Cluster Pool. An example could be that a Production Cluster may consume specific Compute resources, exist in a multi-zone configuration and requires a particular version of OpenShift to be deployed and RHACM will deploy a cluster to meet those requirements.
Once a Cluster Pool has been created, you can submit ClusterClaims to deploy a cluster from that pool.
We have retained the ability to deploy clusters outside of Cluster Pools and updated these methods to support External Secrets Operator.
Review the Clusters
layer kustomization.yaml to enable/disable the Clusters that will be deployed via OpenShift GitOps.
resources:
## ClusterPools - Seperated by Env and Cloud
- argocd/clusterpools/cicd/aws/aws-cicd-pool/aws-cicd-pool.yaml
- argocd/clusterpools/cicd/azure/azure-cicd-pool/azure-cicd-pool.yaml
#- argocd/clusterpools/dev/aws/aws-dev-pool/aws-dev-pool.yaml
#- argocd/clusterpools/test/aws/aws-test-pool/aws-test-pool.yaml
#- argocd/clusterpools/prod/aws/aws-prod-pool/aws-prod-pool.yaml
## Deploy Clusters
## ClusterClaims - Seperated by Env and Cloud
- argocd/clusterclaims/dev/aws/project-simple.yaml
#- argocd/clusterclaims/prod/aws/project-simple.yaml
#- argocd/clusterclaims/cicd/aws/project-cicd.yaml
#- argocd/clusterclaims/test/aws/project-easy.yaml
## ClusterDeployments - Seperated by Env and Cloud
### AWS
#- argocd/clusters/cicd/aws/aws-cicd/aws-cicd.yaml
#- argocd/clusters/dev/aws/aws-dev/aws-dev.yaml
- argocd/clusters/prod/aws/aws-prod/aws-prod.yaml
### Azure
#- argocd/clusters/cicd/azure/azure-cicd/azure-cicd.yaml
- argocd/clusters/prod/azure/azure-prod/azure-prod.yaml
-
We have have provided examples for deploying new clusters into AWS, Azure, IBM Cloud and VMWare. Cluster Deployments require the use of your Cloud Provider API Keys to allow RHACM to connect to your Cloud Provider and deploy via Terraform an OpenShift cluster. We originally utilised the SealedSecrets Controller to encrypt your API Keys and provided a handy script for each Cloud Provider within the
Clusters
repository, underclusters/deploy/sealed-secrets/<cloud provider>
for your use. -
More recently we have updated the pattern to allow the use of an external keystore, e.g. Vault and leveraged the use of the External Secrets Operator to pull in the Cloud Providers API keys automatically. This has allowed us to simplify the creation of new clusters and reduce the values needed. The new method is stored within the
Clusters
repository, underclusters/deploy/external-secrets/<cloud provider>
- Red Hat Advanced Cluster Management 2.5 makes the use of the Discovery Service, that will auto-discover and import OpenShift Clusters configured within your RHOCM account. You can still perform this action outside of the Discovery Service, but this does mean that manual steps are required.
resources:
## Discover & Import Existing Clusters
- argocd/clusters/discover/discover-openshift.yaml
- You can Hibernate deployed Managed OpenShift Clusters running on AWS, Azure and GCP when not in use to reduce on running costs. This has to be done AFTER a cluster has been deployed. This is accomplished by modifying the
spec.powerState
fromRunning
toHibernating
of the ClusterDeployment manifest (Located underotp-gitops-clusters repo/clusters/deploy/<aws|azure|gcp>/<cluster-name>/templates/clusterdeployment.yaml
) of the Managed OpenShift Cluster and committing to Git.
spec:
powerState: Hibernating
- To resume a hibernating Managed OpenShift Cluster, you modify the
spec.powerState
value fromHibernating
toRunning
and commit to Git.
- Details to follow.
We will use IBM Cloud Pak for Integration (CP4i) as an example Application that can be deployed onto your Managed Clusters. As mentioned previously, we re-use the GitOps approach, and utilise OpenShift GitOps to configure the cluster ready for CP4i, through deploying OpenShift Container Storage, creating Nodes with the correct CPU and Memory, installing the necessary services and tools, and finally, deploy CP4i with MQ and ACE.
There is a few minor manual steps which need to be completed, and that is preparing the CP4i respository with your Cloud details and adding the IBM Cloud Pak Entitlement Secret into the Managed Cluster. In future, we aim to automate this step via SealedSecrets, Vault and Ansible Tower.
We will use the Cloud Native Toolkit - GitOps Production Deployment Guide repositories and it is assumed you have already configured these repostories by following the very comprehensive guide put together by that team. That configuration of those repositories are beyond the scope of this asset.
# Log into Managed Cluster that the CP4i will be deployed too via oc login
oc login --token=<token> --server=<server>
# Clone the multi-tenancy-gitops repository you configured via the Cloud Native Toolkit - GitOps Production Deployment Guide
git clone git@github.com:cp4i-cloudpak/multi-tenancy-gitops.git
cd multi-tenancy-gitops
# Run the infra-mod.sh script to configure the Infrastruture details of the Managed Cluster
./scripts/infra-mod.sh
# Create an IBM Entitlement Secret within the tools namespace
## To get an entitlement key:
## 1. Log in to https://myibm.ibm.com/products-services/containerlibrary with an IBMid and password associated with the entitled software.
## 2. Select the **View library** option to verify your entitlement(s).
## 3. Select the **Get entitlement key** to retrieve the key.
oc new-project tools || true
oc create secret docker-registry ibm-entitlement-key -n tools \
--docker-username=cp \
--docker-password="<entitlement_key>" \
--docker-server=cp.icr.io
Note: Our aim is to reduce these steps in future releases of the asset.
You will need to update the tenents/cloudpaks/cp4i/cp4i-placement-rule.yaml
file within the otp-gitops-apps
repository to match the cluster you wish to deploy the Cloud Pak to and commit to Git.
apiVersion: apps.open-cluster-management.io/v1
kind: PlacementRule
metadata:
name: ibm-cp4i-argocd
namespace: openshift-gitops
labels:
app: ibm-cp4i-argocd
spec:
clusterConditions:
- status: "True"
type: ManagedClusterConditionAvailable
clusterSelector:
matchExpressions: []
matchLabels:
# Replace value with Cluster you wish to provision too.
name: aws-ireland
Uncomment the CP4i Application within Application
kustomization.yaml file and commit to Git.
resources:
# Deploy Applications to Managed Clusters
## Include the Applications you wish to deploy below
## An example has been provided
- argocd/cloudpaks/cp4i/cp4i.yaml
OpenShift GitOps will create a RHACM Application that subscribes to the multi-tenancy-gitops
repository you configured and apply the manifests to the Managed Cluster's OpenShift-GitOps controller.