This is a cache of https://docs.openshift.com/container-platform/4.9/applications/creating_applications/odc-creating-applications-using-developer-perspective.html. It is a snapshot of the page at 2024-11-04T18:37:49.233+0000.
Creating applications using the Developer perspective - Creating applications | Building applications | OpenShift Container Platform 4.9
  1. Documentation
    2. history
×

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 OpenShift Container Platform:

  • Getting started resources: Use these resources to help you get started with Developer Console. You can choose to hide the header using the Options menu kebab.

    • Creating applications using samples: Use existing code samples to get started with creating applications on the OpenShift Container Platform.

    • Build with guided documentation: Follow the guided documentation to build applications and familiarize yourself with key concepts and terminologies.

    • Explore new developer features: Explore the new features and resources within the Developer perspective.

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

    • All Services: Browse the catalog to discover services across OpenShift Container Platform.

    • Database: Select the required database service and add it to your application.

    • Operator Backed: Select and deploy the required Operator-managed service.

    • Helm chart: Select the required Helm chart to simplify deployment of applications and services.

    • Event Source: Select an event source to register interest in a class of events from a particular system.

      The Managed services option is also available if the RHOAS Operator is installed.

  • Git repository: Import an existing codebase, Devfile, or Dockerfile from your Git repository using the From Git, From Devfile, or From Dockerfile options respectively, to build and deploy an application on OpenShift Container Platform.

  • Container images: Use existing images from an image stream or registry to deploy it on to the OpenShift Container Platform.

  • Pipelines: Use Tekton pipeline to create CI/CD pipelines for your software delivery process on the OpenShift Container Platform.

  • Serverless: Explore the Serverless options to create, build, and deploy stateless and serverless applications on the OpenShift Container Platform.

    • Channel: Create a Knative channel to create an event forwarding and persistence layer with in-memory and reliable implementations.

  • Samples: Explore the available sample applications to create, build, and deploy an application quickly.

  • Quick Starts: Explore the quick start options to create, import, and run applications with step-by-step instructions and tasks.

  • From Local Machine: Explore the From Local Machine tile to import or upload files on your local machine for building and deploying applications easily.

    • Import YAML: Upload a YAML file to create and define resources for building and deploying applications.

    • Upload JAR file: Upload a JAR file to build and deploy Java applications.

Note that certain options, such as Pipelines, Event Source, and Import Virtual Machines, are displayed only when the OpenShift Pipelines Operator, OpenShift Serverless Operator, and OpenShift Virtualization Operator are installed, respectively.

Prerequisites

To create applications using the Developer perspective ensure that:

To create serverless applications, in addition to the preceding prerequisites, ensure that:

Creating Sample applications

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

Prerequisites

  • You have logged in to the OpenShift Container Platform web console and are in the Developer perspective.

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.

Creating applications using Quick Starts

The Quick Starts page shows you how to create, import, and run applications on OpenShift Container Platform, with step-by-step instructions and tasks.

Prerequisites

  • You have logged in to the OpenShift Container Platform web console and are in the Developer perspective.

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.

Importing a codebase from Git to create an application

You can use the Developer perspective to create, build, and deploy an application on OpenShift Container Platform 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 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.

      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.

    • Serverless Deployment, to create a Knative service.

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

  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:

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.
Domain mapping

If you are creating a Serverless Deployment, you can add a custom domain mapping to the Knative service during creation.

  • In the Advanced options section, click Show advanced Routing options.

    • If the domain mapping CR that you want to map to the service already exists, you can select it from the Domain mapping drop-down menu.

    • If you want to create a new domain mapping CR, type the domain name into the box, and select the Create option. For example, if you type in example.com, the Create option is Create "example.com".

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

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 serverless deployment, you can also configure the following settings:

  • Min Pods determines the lower limit for the number of pods that must be running at any given time for a Knative service. This is also known as the minScale setting.

  • Max Pods determines the upper limit for the number of pods that can be running at any given time for a Knative service. This is also known as the maxScale setting.

  • Concurrency target determines the number of concurrent requests desired for each instance of the application at a given time.

  • Concurrency limit determines the limit for the number of concurrent requests allowed for each instance of the application at a given time.

  • Concurrency utilization determines the percentage of the concurrent requests limit that must be met before Knative scales up additional pods to handle additional traffic.

  • Autoscale window defines the time window over which metrics are averaged to provide input for scaling decisions when the autoscaler is not in panic mode. A service is scaled-to-zero if no requests are received during this window. The default duration for the autoscale window is 60s. This is also known as the stable window.

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.

Upload JAR files for easy deployment of Java applications

You can use the JAR files in the Topology view of the Developer perspective to deploy your Java applications. You can upload a JAR file using the following options:

  • Navigate to the +Add view of the Developer perspective, and click Upload JAR file in the From Local Machine tile. Browse and select your JAR file, or drag and drop a JAR file to deploy your application.

  • Navigate to the Topology view and use the Upload JAR file option, or drag and drop a JAR file to deploy your application.

  • Use the in-context menu in the Topology view, and then use the Upload JAR file option to upload your JAR file to deploy your application.

Use the following instructions to upload a JAR file in the Topology view to deploy a Java 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.

    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.

After the JAR file is uploaded and the application is deployed, you can see the deployment in the Topology view.

Using the Developer Catalog to add services or components to your application

You use the Developer Catalog to deploy applications and services based on Operator backed services such as Databases, Builder Images, and Helm Charts. The Developer Catalog contains a collection of application components, services, event sources, or source-to-image builders that you can add to your project. Cluster administrators can customize the content made available in the catalog.

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.

    odc devcatalog toplogy
    Figure 1. MariaDB in Topology

Additional resources