Building Applications

Procedure

1. Navigate to Home → Projects.
2. Click Create Project.
3. Enter your project details.
4. Click Create.

1. Click the Project drop-down menu to see a list of all available projects. Select Create Project.

   Figure 2.1. Create project

   
2. In the Create Project dialog box, enter a unique name, such as myproject, in the Name field.
3. Optional: Add the Display Name and Description details for the project.
4. Click Create.
5. Use the left navigation panel to navigate to the Project view and see the dashboard for your project.

6. Optional:

   • Use the Project drop-down menu at the top of the screen and select all projects to list all of the projects in your cluster.
   • Use the Details tab to see the project details.
   • If you have adequate permissions for a project, you can use the Project Access tab to provide or revoke administrator, edit, and view privileges for the project.

Procedure

1. Navigate to Home → Projects.

2. Select a project to view.

   On this page, click Workloads to see workloads in the project.

Procedure

1. To view a list of projects, run:

   $ oc get projects

2. You can change from the current project to a different project for CLI operations. The specified project is then used in all subsequent operations that manipulate project-scoped content:

   $ oc project <project_name>

1. In the Developer perspective, navigate to the Project view.
2. In the Project page, select the Project Access tab.

3. Click Add Access to add a new row of permissions to the default ones.

   Figure 2.2. Project permissions

   
4. Enter the user name, click the Select a role drop-down list, and select an appropriate role.
5. Click Save to add the new permissions.

1. In the Search view, use the Resources drop-down list to search for Console.

2. From the available options, select the Console operator.openshift.io/v1.

   Figure 2.3. Searching Console resource

   
3. Select cluster under the Name list.
4. Navigate to the YAML tab to view and edit the YAML code.

5. In the YAML code under spec, add or edit the list of availableClusterRoles and save your changes:

   spec:
     customization:
       projectAccess:
         availableClusterRoles:
         - admin
         - edit
         - view

Procedure

1. Select Developer from the context selector at the top of the web console navigation menu.
2. Click +Add
3. At the top of the page, select the name of the project that you want to add to.
4. Click a method for adding to your project, and then follow the workflow.

Procedure

1. Navigate to Home → Projects.
2. Select a project to see its status.

Procedure

1. Run:

   $ oc status

   This command provides a high-level overview of the current project, with its components and their relationships.

Procedure

1. Navigate to Home → Projects.
2. Locate the project that you want to delete from the list of projects.
3. On the far right side of the project listing, select Delete Project from the Options menu .
4. When the Delete Project pane opens, enter the name of the project that you want to delete in the field.
5. Click Delete.

Procedure

1. Run:

   $ oc delete project <project_name>

Procedure

1. Log in as a user with cluster-admin privileges.

2. Generate the default project template:

   $ oc adm create-bootstrap-project-template -o yaml > template.yaml

3. Use a text editor to modify the generated template.yaml file by adding objects or modifying existing objects.

4. The project template must be created in the openshift-config namespace. Load your modified template:

   $ oc create -f template.yaml -n openshift-config

5. Edit the project configuration resource using the web console or CLI.

   • Using the web console:

     1. Navigate to the Administration → Cluster Settings page.
     2. Click Global Configuration to view all configuration resources.
     3. Find the entry for Project and click Edit YAML.

   • Using the CLI:

     1. Edit the project.config.openshift.io/cluster resource:

        $ oc edit project.config.openshift.io/cluster

6. Update the spec section to include the projectRequestTemplate and name parameters, and set the name of your uploaded project template. The default name is project-request.

   Project configuration resource with custom project template

   apiVersion: config.openshift.io/v1
   kind: Project
   metadata:
     ...
   spec:
     projectRequestTemplate:
       name: <template_name>

7. After you save your changes, create a new project to verify that your changes were successfully applied.

Procedure

1. Log in as a user with cluster-admin privileges.

2. View the self-provisioners cluster role binding usage by running the following command:

   $ oc describe clusterrolebinding.rbac self-provisioners

   Example output

   Name:		self-provisioners
   Labels:		<none>
   Annotations:	rbac.authorization.kubernetes.io/autoupdate=true
   Role:
     Kind:	ClusterRole
     Name:	self-provisioner
   Subjects:
     Kind	Name				Namespace
     ----	----				---------
     Group	system:authenticated:oauth

   Review the subjects in the self-provisioners section.

3. Remove the self-provisioner cluster role from the group system:authenticated:oauth.

   • If the self-provisioners cluster role binding binds only the self-provisioner role to the system:authenticated:oauth group, run the following command:

     $ oc patch clusterrolebinding.rbac self-provisioners -p '{"subjects": null}'

   • If the self-provisioners cluster role binding binds the self-provisioner role to more users, groups, or service accounts than the system:authenticated:oauth group, run the following command:

     $ oc adm policy \
         remove-cluster-role-from-group self-provisioner \
         system:authenticated:oauth

4. Edit the self-provisioners cluster role binding to prevent automatic updates to the role. Automatic updates reset the cluster roles to the default state.

   • To update the role binding using the CLI:

     1. Run the following command:

        $ oc edit clusterrolebinding.rbac self-provisioners

     2. In the displayed role binding, set the rbac.authorization.kubernetes.io/autoupdate parameter value to false, as shown in the following example:

        apiVersion: authorization.openshift.io/v1
        kind: ClusterRoleBinding
        metadata:
          annotations:
            rbac.authorization.kubernetes.io/autoupdate: "false"
          ...

   • To update the role binding by using a single command:

     $ oc patch clusterrolebinding.rbac self-provisioners -p '{ "metadata": { "annotations": { "rbac.authorization.kubernetes.io/autoupdate": "false" } } }'

5. Log in as an authenticated user and verify that it can no longer self-provision a project:

   $ oc new-project test

   Example output

   Error from server (Forbidden): You may not request a new project via this API.

   Consider customizing this project request message to provide more helpful instructions specific to your organization.

Procedure

1. Edit the project configuration resource using the web console or CLI.

   • Using the web console:

     1. Navigate to the Administration → Cluster Settings page.
     2. Click Global Configuration to view all configuration resources.
     3. Find the entry for Project and click Edit YAML.

   • Using the CLI:

     1. Log in as a user with cluster-admin privileges.

     2. Edit the project.config.openshift.io/cluster resource:

        $ oc edit project.config.openshift.io/cluster

2. Update the spec section to include the projectRequestMessage parameter and set the value to your custom message:

   Project configuration resource with custom project request message

   apiVersion: config.openshift.io/v1
   kind: Project
   metadata:
     ...
   spec:
     projectRequestMessage: <message_string>

   For example:

   apiVersion: config.openshift.io/v1
   kind: Project
   metadata:
     ...
   spec:
     projectRequestMessage: To request a project, contact your system administrator at projectname@example.com.

3. After you save your changes, attempt to create a new project as a developer or service account that is unable to self-provision projects to verify that your changes were successfully applied.

Procedure

1. In the +Add view, click on the Samples tile to see the Samples page.
2. On the Samples page, select one of the available sample applications to see the Create Sample Application form.

3. In the Create Sample Application Form:

   • In the Name field, the deployment name is displayed by default. You can modify this name as required.
   • In the Builder Image Version, a builder image is selected by default. You can modify this image version by using the Builder Image Version drop-down list.
   • A sample Git repository URL is added by default.
4. Click Create to create the sample application. The build status of the sample application is displayed on the Topology view. After the sample application is created, you can see the deployment added to the application.

Procedure

1. In the +Add view, click the View all quick starts link to view the Quick Starts page.
2. In the Quick Starts page, click the tile for the quick start that you want to use.
3. Click Start to begin the quick start.

Procedure

1. In the +Add view, click From Git in the Git Repository tile to see the Import from git form.
2. In the Git section, enter the Git repository URL for the codebase you want to use to create an application. For example, enter the URL of this sample Node.js application https://github.com/sclorg/nodejs-ex. The URL is then validated.

3. Optional: You can click Show Advanced Git Options to add details such as:

   • Git Reference to point to code in a specific branch, tag, or commit to be used to build the application.
   • Context Dir to specify the subdirectory for the application source code you want to use to build the application.
   • Source Secret to create a Secret Name with credentials for pulling your source code from a private repository.

4. Optional: You can import a devfile, a Dockerfile, or a builder image through your Git repository to further customize your deployment.

   • If your Git repository contains a devfile, a Dockerfile, or a builder image, it is automatically detected and populated on the respective path fields. If a devfile, a Dockerfile, and a builder image are detected in the same repository, the devfile is selected by default.
   • To edit the file import type and select a different strategy, click Edit import strategy option.
   • If multiple devfiles, Dockerfiles, or builder images are detected, to import a specific devfile, Dockerfile, or a builder image, specify the respective paths relative to the context directory.

5. After the Git URL is validated, the recommended builder image is selected and marked with a star. If the builder image is not auto-detected, select a builder image. For the https://github.com/sclorg/nodejs-ex Git URL, by default the Node.js builder image is selected.

   1. Optional: Use the Builder Image Version drop-down to specify a version.
   2. Optional: Use the Edit import strategy to select a different strategy.

6. In the General section:

   1. In the Application field, enter a unique name for the application grouping, for example, myapp. Ensure that the application name is unique in a namespace.

   2. The Name field to identify the resources created for this application is automatically populated based on the Git repository URL if there are no existing applications. If there are existing applications, you can choose to deploy the component within an existing application, create a new application, or keep the component unassigned.

      Note

      The resource name must be unique in a namespace. Modify the resource name if you get an error.

7. In the Resources section, select:

   • Deployment, to create an application in plain Kubernetes style.
   • Deployment Config, to create an OpenShift Container Platform style application.
   • Knative Service, to create a microservice.
   Note

   The Knative Service option is displayed in the Import from git form only if the Serverless Operator is installed in your cluster. For further details refer to documentation on installing OpenShift Serverless.

8. In the Pipelines section, select Add Pipeline, and then click Show Pipeline Visualization to see the pipeline for the application.
9. In the Advanced Options section, the Create a route to the application is selected by default so that you can access your application using a publicly available URL. You can clear the check box if you do not want to expose your application on a public route.
10. Optional: You can use the following advanced options to further customize your application:

Procedure

1. In the Topology view, right-click anywhere in the Topology view to see the Add to Project menu.
2. Hover over the Add to Project menu to see the menu options, and then select the Upload JAR file option to see the Upload JAR file form . Alternatively, you can drag and drop the JAR file in the Topology view.
3. In the JAR file field, browse for the required JAR file on your local machine and upload it. Alternatively, you can drag and drop the JAR file on the field. A toast alert is displayed at the top right if an incompatible file type is dragged and dropped on the Topology view. A field error is displayed if an incompatible file type is dropped on the field in the upload form.
4. You can further specify optional Java commands to customize your deployed application. The Runtime Icon and Builder Image is selected by default. If a Builder Image is not auto-detected, select a Builder Image. If required, you can change the version using the Builder Image Version drop-down list.
5. In the optional Application Name field, enter a unique name for your application for the resource labelling.
6. In the Name field, enter a unique component name to name the associated resources.
7. In the Resources field, choose the resource type for your application.
8. In the Advanced options, click on Create a Route to the Application to configure a public URL for your deployed application.

9. Click Create to deploy the application. The user sees a toast notification notifying that the JAR file is being uploaded and takes a while. The toast notification also includes a link to view the build logs.

   Note

   If the user attempts to close the browser tab while the build is running, a web alert would be displayed asking the user if they actually want to leave the page.

Procedure

1. In the Developer perspective, navigate to the +Add view and from the Developer Catalog tile, click All Services to view all the available services in the Developer Catalog.
2. Under All Services, select the kind of service or the component you need to add to your project. For this example, select Databases to list all the database services and then click MariaDB to see the details for the service.

3. Click Instantiate Template to see an automatically populated template with details for the MariaDB service, and then click Create to create and view the MariaDB service in the Topology view.

   Figure 3.1. MariaDB in Topology

   

Procedure

1. Create a new project in the OpenShift Container Platform web console for this procedure. This example uses a project called my-etcd.

2. Navigate to the Operators → Installed Operators page. The Operators that have been installed to the cluster by the cluster administrator and are available for use are shown here as a list of cluster service versions (CSVs). CSVs are used to launch and manage the software provided by the Operator.

   Tip

   You can get this list from the CLI using:

   $ oc get csv

3. On the Installed Operators page, click the etcd Operator to view more details and available actions.

   As shown under Provided APIs, this Operator makes available three new resource types, including one for an etcd Cluster (the EtcdCluster resource). These objects work similar to the built-in native Kubernetes ones, such as Deployment or ReplicaSet, but contain logic specific to managing etcd.

4. Create a new etcd cluster:

   1. In the etcd Cluster API box, click Create instance.
   2. The next screen allows you to make any modifications to the minimal starting template of an EtcdCluster object, such as the size of the cluster. For now, click Create to finalize. This triggers the Operator to start up the pods, services, and other components of the new etcd cluster.

5. Click on the example etcd cluster, then click the Resources tab to see that your project now contains a number of resources created and configured automatically by the Operator.

   Verify that a Kubernetes service has been created that allows you to access the database from other pods in your project.

6. All users with the edit role in a given project can create, manage, and delete application instances (an etcd cluster, in this example) managed by Operators that have already been created in the project, in a self-service manner, just like a cloud service. If you want to enable additional users with this ability, project administrators can add the role using the following command:

   $ oc policy add-role-to-user edit <user> -n <target_project>

Procedure

1. Hover over the MongoDB service to see a dangling arrow on the node.

   Figure 4.8. Connector

   
2. Click and drag the arrow towards the Node.js component to connect the MongoDB service with it.
3. Click on the MongoDB service to see the Overview Panel. In the Annotations section, click the edit icon to see the Key = app.openshift.io/connects-to and Value = [{"apiVersion":"apps.openshift.io/v1","kind":"DeploymentConfig","name":"nodejs-ex"}] annotation added to the service.

Procedure

1. Create a CatalogSource resource that adds the PostgresSQL Database Operator provided by Red Hat to the OperatorHub.

   1. In the +Add view, click the YAML option to see the Import YAML screen.

   2. Add the following YAML file to apply the CatalogSource resource:

      apiVersion: operators.coreos.com/v1alpha1
      kind: CatalogSource
      metadata:
          name: sample-db-operators
          namespace: openshift-marketplace
      spec:
          sourceType: grpc
          image: quay.io/redhat-developer/sample-db-operators-olm:v1
          displayName: Sample DB OLM registry
          updateStrategy:
              registryPoll:
                  interval: 30m

   3. Click Create to create the CatalogSource resource in your cluster.

2. Install the Red Hat-provided PostgreSQL Database Operator:

   1. In the Administrator perspective of the console, navigate to Operators → OperatorHub.
   2. In the Database category, select the PostgreSQL Database Operator and install it.

3. Create a database (DB) instance for the application:

   1. Switch to the Developer perspective and ensure that you are in the appropriate project, for example, test-project.
   2. In the +Add view, click the YAML option to see the Import YAML screen.

   3. Add the service instance YAML in the editor and click Create to deploy the service. Following is an example of what the service YAML will look like:

      apiVersion: postgresql.baiju.dev/v1alpha1
      kind: Database
      metadata:
       name: db-demo
      spec:
       image: docker.io/postgres
       imageName: postgres
       dbName: db-demo

      A DB instance is now deployed in the Topology view.

4. In the Topology view, hover over the Node.js component to see a dangling arrow on the node.

5. Click and drag the arrow towards the db-demo-postgresql service to make a binding connection with the Node.js application. A service binding request is created and the Service Binding Operator controller injects the DB connection information into the application deployment as environment variables. After the request is successful, the application is redeployed and the connection is established.

   Figure 4.10. Binding connector

   

1. Download the Helm binary and add it to your path:

   # curl -L https://mirror.openshift.com/pub/openshift-v4/clients/helm/latest/helm-linux-amd64 -o /usr/local/bin/helm

2. Make the binary file executable:

   # chmod +x /usr/local/bin/helm

3. Check the installed version:

   $ helm version

   Example output

   version.BuildInfo{Version:"v3.0", GitCommit:"b31719aab7963acf4887a1c1e6d5e53378e34d93", GitTreeState:"clean", GoVersion:"go1.13.4"}

1. Download the latest .exe file and put in a directory of your preference.
2. Right click Start and click Control Panel.
3. Select System and Security and then click System.
4. From the menu on the left, select Advanced systems settings and click Environment Variables at the bottom.
5. Select Path from the Variable section and click Edit.
6. Click New and type the path to the folder with the .exe file into the field or click Browse and select the directory, and click OK.

1. Download the latest .exe file and put in a directory of your preference.
2. Click Search and type env or environment.
3. Select Edit environment variables for your account.
4. Select Path from the Variable section and click Edit.
5. Click New and type the path to the directory with the exe file into the field or click Browse and select the directory, and click OK.

1. Download the Helm binary and add it to your path:

   # curl -L https://mirror.openshift.com/pub/openshift-v4/clients/helm/latest/helm-darwin-amd64 -o /usr/local/bin/helm

2. Make the binary file executable:

   # chmod +x /usr/local/bin/helm

3. Check the installed version:

   $ helm version

   Example output

   version.BuildInfo{Version:"v3.0", GitCommit:"b31719aab7963acf4887a1c1e6d5e53378e34d93", GitTreeState:"clean", GoVersion:"go1.13.4"}

Procedure

1. Create a new project:

   $ oc new-project mysql

2. Add a repository of Helm charts to your local Helm client:

   $ helm repo add stable https://kubernetes-charts.storage.googleapis.com/

   Example output

   "stable" has been added to your repositories

3. Update the repository:

   $ helm repo update

4. Install an example MySQL chart:

   $ helm install example-mysql stable/mysql

5. Verify that the chart has installed successfully:

   $ helm list

   Example output

   NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION
   example-mysql mysql 1 2019-12-05 15:06:51.379134163 -0500 EST deployed mysql-1.5.0 5.7.27

1. In the Developer perspective, navigate to the +Add view and select a project. Then click Helm Chart option to see all the Helm Charts in the Developer Catalog.
2. Select a chart and read the description, README, and other details about the chart.

3. Click Install Helm Chart.

   Figure 5.1. Helm charts in developer catalog

   

4. In the Install Helm Chart page:

   1. Enter a unique name for the release in the Release Name field.
   2. Select the required chart version from the Chart Version drop-down list.

   3. Configure your Helm chart by using the Form View or the YAML View.

      Note

      Where available, you can switch between the YAML View and Form View. The data is persisted when switching between the views.

   4. Click Install to create a Helm release. You will be redirected to the Topology view where the release is displayed. If the Helm chart has release notes, the chart is pre-selected and the right panel displays the release notes for that release.

Procedure

1. Create a new project:

   $ oc new-project nodejs-ex-k

2. Download an example Node.js chart that contains OpenShift Container Platform objects:

   $ git clone https://github.com/redhat-developer/redhat-helm-charts

3. Go to the directory with the sample chart:

   $ cd redhat-helm-charts/alpha/nodejs-ex-k/

4. Edit the Chart.yaml file and add a description of your chart:

   apiVersion: v2 1
   name: nodejs-ex-k 2
   description: A Helm chart for OpenShift 3
   icon: https://static.redhat.com/libs/redhat/brand-assets/latest/corp/logo.svg 4

   1

   The chart API version. It should be v2 for Helm charts that require at least Helm 3.

   2

   The name of your chart.

   3

   The description of your chart.

   4

   The URL to an image to be used as an icon.

5. Verify that the chart is formatted properly:

   $ helm lint

   Example output

   [INFO] Chart.yaml: icon is recommended
   
   1 chart(s) linted, 0 chart(s) failed

6. Navigate to the previous directory level:

   $ cd ..

7. Install the chart:

   $ helm install nodejs-chart nodejs-ex-k

8. Verify that the chart has installed successfully:

   $ helm list

   Example output

   NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION
   nodejs-chart nodejs-ex-k 1 2019-12-05 15:06:51.379134163 -0500 EST deployed nodejs-0.1.0  1.16.0

Procedure

1. To add a new Helm Chart Repository, you must add the Helm Chart Repository custom resource (CR) to your cluster.

   Sample Helm Chart Repository CR

   apiVersion: helm.openshift.io/v1beta1
   kind: HelmChartRepository
   metadata:
     name: <name>
   spec:
    # optional name that might be used by console
    # name: <chart-display-name>
     connectionConfig:
       url: <helm-chart-repository-url>

   For example, to add an Azure sample chart repository, run:

   $ cat <<EOF | oc apply -f -
   apiVersion: helm.openshift.io/v1beta1
   kind: HelmChartRepository
   metadata:
     name: azure-sample-repo
   spec:
     name: azure-sample-repo
     connectionConfig:
       url: https://raw.githubusercontent.com/Azure-Samples/helm-charts/master/docs
   EOF

2. Navigate to the Developer Catalog in the web console to verify that the Helm charts from the chart repository are displayed.

   For example, use the Chart repositories filter to search for a Helm chart from the repository.

   Figure 5.2. Chart repositories filter

   
   Note

   If a cluster administrator removes all of the chart repositories, then you cannot view the Helm option in the +Add view, Developer Catalog, and left navigation panel.

1. In the openshift-config namespace, create a ConfigMap object with a custom CA certificate in PEM encoded format, and store it under the ca-bundle.crt key within the config map:

   $ oc create configmap helm-ca-cert \
   --from-file=ca-bundle.crt=/path/to/certs/ca.crt \
   -n openshift-config

2. In the openshift-config namespace, create a Secret object to add the client TLS configurations:

   $ oc create secret tls helm-tls-configs \
   --cert=/path/to/certs/client.crt \
   --key=/path/to/certs/client.key \
   -n openshift-config

   Note that the client certificate and key must be in PEM encoded format and stored under the keys tls.crt and tls.key, respectively.

3. Add the Helm repository as follows:

   $ cat <<EOF | oc apply -f -
   apiVersion: helm.openshift.io/v1beta1
   kind: HelmChartRepository
   metadata:
     name: <helm-repository>
   spec:
     name: <helm-repository>
     connectionConfig:
       url: <URL for the Helm repository>
       tlsConfig:
           name: helm-tls-configs
       ca:
   	name: helm-ca-cert
   EOF

   The ConfigMap and Secret are consumed in the HelmChartRepository CR using the tlsConfig and ca fields. These certificates are used to connect to the Helm repository URL.

4. By default, all authenticated users have access to all configured charts. However, for chart repositories where certificates are needed, you must provide users with read access to the helm-ca-cert config map and helm-tls-configs secret in the openshift-config namespace, as follows:

   $ cat <<EOF | kubectl apply -f -
   apiVersion: rbac.authorization.k8s.io/v1
   kind: Role
   metadata:
     namespace: openshift-config
     name: helm-chartrepos-tls-conf-viewer
   rules:
   - apiGroups: [""]
     resources: ["configmaps"]
     resourceNames: ["helm-ca-cert"]
     verbs: ["get"]
   - apiGroups: [""]
     resources: ["secrets"]
     resourceNames: ["helm-tls-configs"]
     verbs: ["get"]
   ---
   kind: RoleBinding
   apiVersion: rbac.authorization.k8s.io/v1
   metadata:
     namespace: openshift-config
     name: helm-chartrepos-tls-conf-viewer
   subjects:
     - kind: Group
       apiGroup: rbac.authorization.k8s.io
       name: 'system:authenticated'
   roleRef:
     apiGroup: rbac.authorization.k8s.io
     kind: Role
     name: helm-chartrepos-tls-conf-viewer
   EOF

Procedure

1. In the Developer perspective, navigate to the +Add view and select a project.
2. From the Developer Catalog tile, select the Helm Chart option to see all the Helm charts in the Developer Catalog.

3. Use the filters to the left of the list of Helm charts to filter the required charts:

   • Use the Chart Repositories filter to filter charts provided by Red Hat Certification Charts or OpenShift Helm Charts.
   • Use the Source filter to filter charts sourced from Partners, Community, or Red Hat. Certified charts are indicated with the ( ) icon.

Procedure

1. In the Topology view, select the Helm release to see the side panel.
2. Click Actions → Upgrade Helm Release.
3. In the Upgrade Helm Release page, select the Chart Version you want to upgrade to, and then click Upgrade to create another Helm release. The Helm Releases page displays the two revisions.

1. In the Developer perspective, navigate to the Helm view to see the Helm Releases in the namespace.
2. Click the Options menu adjoining the listed release, and select Rollback.
3. In the Rollback Helm Release page, select the Revision you want to rollback to and click Rollback.
4. In the Helm Releases page, click on the chart to see the details and resources for that release.

5. Go to the Revision History tab to see all the revisions for the chart.

   Figure 5.3. Helm revision history

   
6. If required, you can further use the Options menu adjoining a particular revision and select the revision to rollback to.

Procedure

1. In the Topology view, right-click the Helm release and select Uninstall Helm Release.
2. In the confirmation prompt, enter the name of the chart and click Uninstall.

1. The elements of a ReplicationController definition.
2. Triggers for creating a new deployment automatically.
3. The strategy for transitioning between deployments.
4. Lifecycle hooks.

1. Executes any pre lifecycle hook.
2. Scales up the new replication controller based on the surge count.
3. Scales down the old replication controller based on the max unavailable count.
4. Repeats this scaling until the new replication controller has reached the desired replica count and the old replication controller has been scaled to zero.
5. Executes any post lifecycle hook.

1. Executes any pre lifecycle hook.
2. Scales down the previous deployment to zero.
3. Executes any mid lifecycle hook.
4. Scales up the new deployment.
5. Executes any post lifecycle hook.

1. In the Actions drop-down menu, select Edit Deployment Config to see the deployment configuration details of the application.
2. In the YAML editor, change the spec.strategy.type to Recreate and click Save.
3. In the Topology view, select the node to see the Overview tab in the side panel. The Update Strategy is now set to Recreate.

4. Use the Actions drop-down menu to select Start Rollout to start an update using the recreate strategy. The recreate strategy first terminates pods for the older version of the application and then spins up pods for the new version.

   Figure 6.2. Recreate update

   

Procedure

1. Define the quota in a file.

2. Use the file to create the quota and apply it to a project:

   $ oc create -f <file> [-n <project_name>]

   For example:

   $ oc create -f core-object-counts.yaml -n demoproject

Procedure

1. Get the list of quotas defined in the project. For example, for a project called demoproject:

   $ oc get quota -n demoproject

   Example output

   NAME                AGE
   besteffort          11m
   compute-resources   2m
   core-object-counts  29m

2. Describe the quota you are interested in, for example the core-object-counts quota:

   $ oc describe quota core-object-counts -n demoproject

   Example output

   Name:			core-object-counts
   Namespace:		demoproject
   Resource		Used	Hard
   --------		----	----
   configmaps		3	10
   persistentvolumeclaims	0	4
   replicationcontrollers	3	20
   secrets			9	10
   services		2	10

Procedure

1. Add a resource quota definition to a project request template:

   • If a project request template does not exist in a cluster:

     1. Create a bootstrap project template and output it to a file called template.yaml:

        $ oc adm create-bootstrap-project-template -o yaml > template.yaml

     2. Add a resource quota definition to template.yaml. The following example defines a resource quota named 'storage-consumption'. The definition must be added before the parameters: section in the template:

        - apiVersion: v1
          kind: ResourceQuota
          metadata:
            name: storage-consumption
            namespace: ${PROJECT_NAME}
          spec:
            hard:
              persistentvolumeclaims: "10" 1
              requests.storage: "50Gi" 2
              gold.storageclass.storage.k8s.io/requests.storage: "10Gi" 3
              silver.storageclass.storage.k8s.io/requests.storage: "20Gi" 4
              silver.storageclass.storage.k8s.io/persistentvolumeclaims: "5" 5
              bronze.storageclass.storage.k8s.io/requests.storage: "0" 6
              bronze.storageclass.storage.k8s.io/persistentvolumeclaims: "0" 7

        1

        The total number of persistent volume claims in a project.

        2

        Across all persistent volume claims in a project, the sum of storage requested cannot exceed this value.

        3

        Across all persistent volume claims in a project, the sum of storage requested in the gold storage class cannot exceed this value.

        4

        Across all persistent volume claims in a project, the sum of storage requested in the silver storage class cannot exceed this value.

        5

        Across all persistent volume claims in a project, the total number of claims in the silver storage class cannot exceed this value.

        6

        Across all persistent volume claims in a project, the sum of storage requested in the bronze storage class cannot exceed this value. When this value is set to 0, the bronze storage class cannot request storage.

        7

        Across all persistent volume claims in a project, the sum of storage requested in the bronze storage class cannot exceed this value. When this value is set to 0, the bronze storage class cannot create claims.

     3. Create a project request template from the modified template.yaml file in the openshift-config namespace:

        $ oc create -f template.yaml -n openshift-config

        Note

        To include the configuration as a kubectl.kubernetes.io/last-applied-configuration annotation, add the --save-config option to the oc create command.

        By default, the template is called project-request.

   • If a project request template already exists within a cluster:

     Note

     If you declaratively or imperatively manage objects within your cluster by using configuration files, edit the existing project request template through those files instead.

     1. List templates in the openshift-config namespace:

        $ oc get templates -n openshift-config

     2. Edit an existing project request template:

        $ oc edit template <project_request_template> -n openshift-config

     3. Add a resource quota definition, such as the preceding storage-consumption example, into the existing template. The definition must be added before the parameters: section in the template.

2. If you created a project request template, reference it in the cluster’s project configuration resource:

   1. Access the project configuration resource for editing:

      • By using the web console:

        1. Navigate to the Administration → Cluster Settings page.
        2. Click Global Configuration to view all configuration resources.
        3. Find the entry for Project and click Edit YAML.

      • By using the CLI:

        1. Edit the project.config.openshift.io/cluster resource:

           $ oc edit project.config.openshift.io/cluster

   2. Update the spec section of the project configuration resource to include the projectRequestTemplate and name parameters. The following example references the default project request template name project-request:

      apiVersion: config.openshift.io/v1
      kind: Project
      metadata:
        ...
      spec:
        projectRequestTemplate:
          name: project-request

3. Verify that the resource quota is applied when projects are created:

   1. Create a project:

      $ oc new-project <project_name>

   2. List the project’s resource quotas:

      $ oc get resourcequotas

   3. Describe the resource quota in detail:

      $ oc describe resourcequotas <resource_quota_name>

Procedure

1. To select projects based on annotations, run the following command:

   $ oc create clusterquota for-user \
        --project-annotation-selector openshift.io/requester=<user_name> \
        --hard pods=10 \
        --hard secrets=20

   This creates the following ClusterResourceQuota object:

   apiVersion: quota.openshift.io/v1
   kind: ClusterResourceQuota
   metadata:
     name: for-user
   spec:
     quota: 1
       hard:
         pods: "10"
         secrets: "20"
     selector:
       annotations: 2
         openshift.io/requester: <user_name>
       labels: null 3
   status:
     namespaces: 4
     - namespace: ns-one
       status:
         hard:
           pods: "10"
           secrets: "20"
         used:
           pods: "1"
           secrets: "9"
     total: 5
       hard:
         pods: "10"
         secrets: "20"
       used:
         pods: "1"
         secrets: "9"

   1

   The ResourceQuotaSpec object that will be enforced over the selected projects.

   2

   A simple key-value selector for annotations.

   3

   A label selector that can be used to select projects.

   4

   A per-namespace map that describes current quota usage in each selected project.

   5

   The aggregate usage across all selected projects.

   This multi-project quota document controls all projects requested by <user_name> using the default project request endpoint. You are limited to 10 pods and 20 secrets.

2. Similarly, to select projects based on labels, run this command:

   $  oc create clusterresourcequota for-name \1
       --project-label-selector=name=frontend \2
       --hard=pods=10 --hard=secrets=20

   1

   Both clusterresourcequota and clusterquota are aliases of the same command. for-name is the name of the ClusterResourceQuota object.

   2

   To select projects by label, provide a key-value pair by using the format --project-label-selector=key=value.

   This creates the following ClusterResourceQuota object definition:

   apiVersion: quota.openshift.io/v1
   kind: ClusterResourceQuota
   metadata:
     creationTimestamp: null
     name: for-name
   spec:
     quota:
       hard:
         pods: "10"
         secrets: "20"
     selector:
       annotations: null
       labels:
         matchLabels:
           name: frontend

Procedure

1. To view quotas applied to a project, run:

   $ oc describe AppliedClusterResourceQuota

   Example output

   Name:   for-user
   Namespace:  <none>
   Created:  19 hours ago
   Labels:   <none>
   Annotations:  <none>
   Label Selector: <null>
   AnnotationSelector: map[openshift.io/requester:<user-name>]
   Resource  Used  Hard
   --------  ----  ----
   pods        1     10
   secrets     9     20