This is a cache of https://docs.okd.io/4.6/applications/application_life_cycle_management/odc-creating-applications-using-developer-perspective.html. It is a snapshot of the page at 2024-11-22T02:27:02.526+0000.
Creating applications using the Developer perspective - Application life cycle management | Applications | OKD 4.6
  1. Documentation
×

Creating applications using the Developer perspective

The Developer perspective in the web console provides you the following options from the +Add view to create applications and associated services and deploy them on OKD:

  • From Git: Use this option to import an existing codebase in a Git repository to create, build, and deploy an application on OKD.

  • Container Image: Use existing images from an image stream or registry to deploy it on to OKD.

  • From Dockerfile: Import a dockerfile from your Git repository to build and deploy an application.

  • YAML: Use the editor to add YAML or JSON definitions to create and modify resources.

  • From Catalog: Explore the Developer Catalog to select the required applications, services, or source to image builders and add it to your project.

  • Database: See the Developer Catalog to select the required database service and add it to your application.

  • Operator Backed: Explore the Developer Catalog to select and deploy the required Operator-managed service.

  • helm Chart: Explore the Developer Catalog to select the required helm chart to simplify deployment of applications and services.

Prerequisites

To create applications using the Developer perspective ensure that:

Creating Sample applications

You can use the basic sample applications in the +Add flow of the Developer perspective to create, build, and deploy applications quickly.

The following procedure explains the Samples option in the Developer perspective to create a sample application.

Procedure

  1. In the +Add view, click Samples 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.

Importing a codebase from Git to create an application

You can use the Developer perspective to create, build, and deploy an application on OKD using an existing codebase in GitHub.

The following procedure walks you through the From Git option in the Developer perspective to create an application.

Procedure

  1. In the +Add view, click From Git 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. In the Builder section, after the URL is validated, an appropriate builder image is detected, indicated by a star, and automatically selected. For the https://github.com/sclorg/nodejs-ex Git URL, the Node.js 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 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.

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

  6. In the Resources section, select:

    • Deployment, to create an application in plain Kubernetes style.

    • Deployment Config, to create an OpenShift style application.

    • Knative Service, to create a microservice.

    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.

  7. In the Pipelines section, select Add Pipeline, and then click Show Pipeline Visualization to see the pipeline for the application.

  8. 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.

  9. Optional: You can use the following advanced options to further customize your application:

Routing

By clicking the Routing link, you can perform the following actions:

  • Customize the hostname for the route.

  • Specify the path the router watches.

  • Select the target port for the traffic from the drop-down list.

  • Secure your route by selecting the Secure Route check box. Select the required TLS termination type and set a policy for insecure traffic from the respective drop-down lists.

    For serverless applications, the Knative service manages all the routing options above. However, you can customize the target port for traffic, if required. If the target port is not specified, the default port of 8080 is used.
Health Checks

Click the Health Checks link to add Readiness, Liveness, and Startup probes to your application. All the probes have prepopulated default data; you can add the probes with the default data or customize it as required.

To customize the health probes:

  • Click Add Readiness Probe, if required, modify the parameters to check if the container is ready to handle requests, and select the check mark to add the probe.

  • Click Add Liveness Probe, if required, modify the parameters to check if a container is still running, and select the check mark to add the probe.

  • Click Add Startup Probe, if required, modify the parameters to check if the application within the container has started, and select the check mark to add the probe.

    For each of the probes, you can specify the request type - HTTP GET, Container Command, or TCP Socket, from the drop-down list. The form changes as per the selected request type. You can then modify the default values for the other parameters, such as the success and failure thresholds for the probe, number of seconds before performing the first probe after the container starts, frequency of the probe, and the timeout value.

Build Configuration and Deployment

Click the Build Configuration and Deployment links to see the respective configuration options. Some options are selected by default; you can customize them further by adding the necessary triggers and environment variables.

For serverless applications, the Deployment option is not displayed as the Knative configuration resource maintains the desired state for your deployment instead of a DeploymentConfig.

Scaling

Click the Scaling link to define the number of pods or instances of the application you want to deploy initially.

If you are creating a Knative service, you can also configure the following settings:

  • Set the upper and lower limit for the number of pods that can be set by the autoscaler. If the lower limit is not specified, it defaults to zero.

  • Define the soft limit for the required number of concurrent requests per instance of the application at a given time. It is the recommended configuration for autoscaling. If not specified, it takes the value specified in the cluster configuration.

  • Define the hard limit for the number of concurrent requests allowed per instance of the application at a given time. This is configured in the revision template. If not specified, it defaults to the value specified in the cluster configuration.

Resource Limit

Click the Resource Limit link to set the amount of CPU and Memory resources a container is guaranteed or allowed to use when running.

Labels

Click the Labels link to add custom labels to your application.

  1. Click Create to create the application and see its build status in the Topology view.

Additional resources