mirror of
https://github.com/openshift/openshift-docs.git
synced 2026-02-05 12:46:18 +01:00
78 lines
5.0 KiB
Plaintext
78 lines
5.0 KiB
Plaintext
// Module included in the following assemblies:
|
|
//
|
|
// applications/application_life_cycle_management/odc-creating-applications-using-developer-perspective.adoc
|
|
|
|
[id="odc-importing-codebase-from-git-to-create-application_{context}"]
|
|
= Importing a codebase from Git to create an application
|
|
|
|
The following procedure walks you through the *Import from Git* option in the *Developer* perspective to create an application.
|
|
|
|
Create, build, and deploy an application on {product-title} using an existing codebase in GitHub as follows:
|
|
|
|
.Procedure
|
|
|
|
. In the *Add* view, click *From Git* to see the *Import from git* form.
|
|
+
|
|
image::odc_import_from_git.png[Import from Git]
|
|
|
|
. 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.
|
|
. Optionally, 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.
|
|
|
|
. 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 required, you can change the version using the *Builder Image Version* drop-down list.
|
|
. In the *General* section:
|
|
.. 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.
|
|
.. The *Name* field to identify the resources created for this application is automatically populated based on the Git repository URL.
|
|
+
|
|
[NOTE]
|
|
====
|
|
The resource name must be unique in a namespace. Modify the resource name if you get an error.
|
|
====
|
|
|
|
. 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.
|
|
|
|
+
|
|
[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.
|
|
====
|
|
|
|
. 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.
|
|
. Optionally, you can use the following advanced options to further customize your application:
|
|
|
|
Routing::
|
|
Click the *Routing* link to:
|
|
* 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.
|
|
|
|
Build and Deployment Configuration::
|
|
Click the *Build Configuration* and *Deployment Configuration* links to see the respective configuration options. Some of the options are selected by default; you can customize them further by adding the necessary triggers and environment variables. For serverless applications, the *Deployment Configuration* 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.
|
|
+
|
|
For serverless applications, you can:
|
|
|
|
* 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.
|
|
|
|
. Click *Create* to create the application and see its build status in the *Topology* view.
|