Configuring Image Registry to use OpenShift Data Foundation
1. Create a Persistent Volume Claim for the Image Registry to use.
1. In the OpenShift Web Console, click Storage → Persistent Volume Claims.
2. Set the Project to openshift-image-registry.
3. Click Create Persistent Volume Claim.
From the list of available storage classes retrieved above, specify the Storage Class with the provisioner openshift-storage.cephfs.csi.ceph.com.
Specify the Persistent Volume Claim Name, for example, ocsregistry.
Specify an Access Mode of Shared Access (RWX).
Specify a Size of at least 100 GB.
Click Create.
Wait until the status of the new Persistent Volume Claim is listed as Bound.
2. Configure the cluster’s Image Registry to use the new Persistent Volume Claim.
1. Click Administration → Custom Resource Definitions.
2. Click the Config custom resource definition associated with the imageregistry.operator.openshift.io group.
3. Click the Instances tab.
4. Beside the cluster instance, click the Action Menu (⋮) → Edit Config.
5. Add the new Persistent Volume Claim as persistent storage for the Image Registry.
Add the following under spec:, replacing the existing storage: section if necessary.
storage:
pvc:
claim: <new-pvc-name> For example:
storage:
pvc:
claim: ocs4registry Click Save
3. Verify that the new configuration is being used.
1. Click Workloads → Pods.
2. Set the Project to openshift-image-registry.
3. Verify that the new image-registry-* pod appears with a status of Running, and that the previous image-registry-* pod terminates.
4. Click the new image-registry-* pod to view pod details.
5. Scroll down to Volumes and verify that the registry-storage volume has a Type that matches your new Persistent Volume Claim, for example, ocsregistry.
A DHCP server unless using static IP addressing. A base domain name.
The OpenShift Container Platform cluster’s network must also meet the following requirements: Connectivity between all cluster nodes Connectivity for each node to the internet Access to an NTP server for time synchronization between the cluster nodes
Example DNS zone database
$TTL 1W
@ IN SOA ns1.example.com. root (
2019070700 ; serial
3H ; refresh (3 hours)
30M ; retry (30 minutes)
2W ; expiry (2 weeks)
1W ) ; minimum (1 week)
IN NS ns1.example.com.
IN MX 10 smtp.example.com.
;
;
ns1.example.com. IN A 192.168.1.1
smtp.example.com. IN A 192.168.1.5
;
helper.example.com. IN A 192.168.1.5
;
api.ocp4.example.com. IN A 192.168.1.5 1
api-int.ocp4.example.com. IN A 192.168.1.5 2
;
*.apps.ocp4.example.com. IN A 192.168.1.5 3
;
control-plane0.ocp4.example.com. IN A 192.168.1.97 4
control-plane1.ocp4.example.com. IN A 192.168.1.98
control-plane2.ocp4.example.com. IN A 192.168.1.99
;
worker0.ocp4.example.com. IN A 192.168.1.11 5
worker1.ocp4.example.com. IN A 192.168.1.7
;
;EOF
Provides name resolution for the Kubernetes API. The record refers to the IP address of the API load balancer. ↩︎
Provides name resolution for the Kubernetes API. The record refers to the IP address of the API load balancer and is used for internal cluster communications. ↩︎
Provides name resolution for the wildcard routes. The record refers to the IP address of the application ingress load balancer. The application ingress load balancer targets the machines that run the Ingress Controller pods. The Ingress Controller pods run on the worker machines by default. ↩︎
Provides name resolution for the control plane machines. ↩︎
Provides name resolution for the worker machines. ↩︎
Example DNS zone database for reverse records
$$TTL 1W
@ IN SOA ns1.example.com. root (
2019070700 ; serial
3H ; refresh (3 hours)
30M ; retry (30 minutes)
2W ; expiry (2 weeks)
1W ) ; minimum (1 week)
IN NS ns1.example.com.
;
5.1.168.192.in-addr.arpa. IN PTR api.ocp4.example.com.
5.1.168.192.in-addr.arpa. IN PTR api-int.ocp4.example.com.
;
97.1.168.192.in-addr.arpa. IN PTR control-plane0.ocp4.example.com.
98.1.168.192.in-addr.arpa. IN PTR control-plane1.ocp4.example.com.
99.1.168.192.in-addr.arpa. IN PTR control-plane2.ocp4.example.com.
;
11.1.168.192.in-addr.arpa. IN PTR worker0.ocp4.example.com.
7.1.168.192.in-addr.arpa. IN PTR worker1.ocp4.example.com.
;
;EOF
Review the pending CSRs and ensure that you see the client requests with the Pending or Approved status for each machine that you added to the cluster:
oc get csr
To approve them individually, run the following command for each valid CSR:
oc adm certificate approve <csr_name>
Now that your client requests are approved, you must review the server requests for each machine that you added to the cluster:
oc get csr
If the remaining CSRs are not approved, and are in the Pending status, approve the CSRs for your cluster machines:
oc adm certificate approve <csr_name>
# To approve all pending CSRs, run the following command:
oc get csr -o go-template='{{range .items}}{{if not .status}}{{.metadata.name}}{{"\n"}}{{end}}{{end}}' | xargs oc adm certificate approve
After all client and server CSRs have been approved, the machines have the Ready status. Verify this by running the following command:
ocp-user: Users with OpenShift access Any users who should be able to log-in to OpenShift must be members of this group All of the below mentioned users are in this group ocp-normal-dev: Normal OpenShift users Regular users of OpenShift without special permissions Contains: normaluser1, teamuser1, teamuser2 ocp-fancy-dev: Fancy OpenShift users Users of OpenShift that are granted some special privileges Contains: fancyuser1, fancyuser2 ocp-teamed-app: Teamed app users A group of users that will have access to the same OpenShift Project Contains: teamuser1, teamuser2
1. Sign in to the Azure portal. Search for Automation Accounts. In the search results, select Automation Accounts.
2. On the next screen, click Add.
3. In the AddAutomation Account pane, enter a name for your new Automation account in the Name field. You can’t change this name after it’s chosen.
If you have more than one subscription, use the Subscription field to specify the subscription to use for the new account.
For Resourcegroup, enter or select a new or existing resource group.
For Location, select an Azure datacenter location.
For the Create Azure Run As account option, ensure that Yes is selected, and then click Create.
2. Import AzureRM,profile
1. From your Automationaccount, under Shared Resources, select Modules. In the search bar, enter the module name (for example, AzureRM.Profile).
2. On the PowerShell Module page, select Import to import the module into your Automation account.
3. Select I agree to update all of the Azure modules.
4. Wait for the installation to complete.
3. Create Runbook
1. Click Create a runbook.
2. Enter a name for the runbook and select its type. The runbook name must start with a letter and can contain letters, numbers, underscores, and dashes.
4. Click Save and Publish (before publishing please have a test for the runbook).
4. Test the Runbook
Before you publish the runbook to make it available in production, you should test it to make sure that it works properly. Testing a runbook runs its Draft version and allows you to view its output interactively.
1. In the Azure portal, open your Automation account. Select Runbooks under Process Automation to open the list of runbooks. Click your runbook.
2. Click Edit.
3. Click Test pane to open the Test pane.
4. Enter the AZURESUBSCRIPTIONID, AZUREVMLIST and ACTION’s values. Click Start to start the test.
5. When the runbook job completes, close the Test pane to return to the canvas.
5. Create a Schedule in the Azure portal
1. From your Automation account, on the left-hand pane select Schedules under Shared Resources. On the Schedules page, select Add a schedule.
2. Choose Schedule.
3. Create a new schedule.
4. Select whether the schedule runs once or on a reoccurring schedule by selecting Once or Recurring. If you select Once, specify a start time and then select Create. If you select Recurring, specify a start time. For Recurevery, select how often you want the runbook to repeat. Select by hour, day, week, or month.
If you select Week, the days of the week are presented for you to choose from. Select as many days as you want. The first run of your schedule will happen on the first day selected after the start time. For example, to choose a weekend schedule, select Saturday and Sunday.
If you select Month, you’re given different options. For the Monthlyoccurrences option, select either Monthdays or Weekdays. If you select Monthdays, a calendar appears so that you can choose as many days as you want. If you choose a date such as the 31st that doesn’t occur in the current month, the schedule won’t run. If you want the schedule to run on the last day, select Yes under Run on last day of month. If you select Week days, the Recur every option appears. Choose First, Second, Third, Fourth, or Last. Finally, choose a day to repeat on.
5. When you’re finished, select Create.
6. Choose Parameters and run settings.
7. Enter the AZURESUBSCRIPTIONID, AZUREVMLIST and ACTION’s values.
8. Click OK.
9.Finished. Follow the steps above to create a stop schedule.