Chapter 2. Developer CLI (odo)


2.1. Understanding odo

odo is a CLI tool for creating applications on OpenShift Container Platform and Kubernetes. With odo, you can write, build, and debug applications on a cluster without the need to administer the cluster itself. Creating deployment configurations, build configurations, service routes and other OpenShift Container Platform or Kubernetes elements are all automated by odo.

Existing tools such as oc are operations-focused and require a deep understanding of Kubernetes and OpenShift Container Platform concepts. odo abstracts away complex Kubernetes and OpenShift Container Platform concepts allowing developers to focus on what is most important to them: code.

2.1.1. Key features

odo is designed to be simple and concise with the following key features:

  • Simple syntax and design centered around concepts familiar to developers, such as projects, applications, and components.
  • Completely client based. No additional server other than OpenShift Container Platform is required for deployment.
  • Official support for Node.js and Java components.
  • Partial compatibility with languages and frameworks such as Ruby, Perl, PHP, and Python.
  • Detects changes to local code and deploys it to the cluster automatically, giving instant feedback to validate changes in real time.
  • Lists all the available components and services from the cluster.

2.1.2. Core concepts

Project
A project is your source code, tests, and libraries organized in a separate single unit.
Application
An application is a program designed for end users. An application consists of multiple microservices or components that work individually to build the entire application. Examples of applications: a video game, a media player, a web browser.
Component
A component is a set of Kubernetes resources which host code or data. Each component can be run and deployed separately. Examples of components: Node.js, Perl, PHP, Python, Ruby.
Service
A service is software that your component links to or depends on. Examples of services: MariaDB, Jenkins, MySQL. In odo, services are provisioned from the OpenShift Service Catalog and must be enabled within your cluster.

2.1.2.1. Officially supported languages and corresponding container images

Table 2.1. Supported languages, container images, package managers, and platforms
LanguageContainer imagePackage managerPlatform

Node.js

rhscl/nodejs-10-rhel7

NPM

amd64, s390x, ppc64le

 

rhscl/nodejs-12-rhel7

NPM

amd64, s390x, ppc64le

Java

redhat-openjdk-18/openjdk18-openshift

Maven, Gradle

amd64, s390x, ppc64le

 

openjdk/openjdk-11-rhel8

Maven, Gradle

amd64, s390x, ppc64le

 

openjdk/openjdk-11-rhel7

Maven, Gradle

amd64, s390x, ppc64le

2.1.2.1.1. Listing available container images
Note

The list of available container images is sourced from the cluster’s internal container registry and external registries associated with the cluster.

To list the available components and associated container images for your cluster:

  1. Log in to the cluster with odo:

    $ odo login -u developer -p developer
  2. List the available odo supported and unsupported components and corresponding container images:

    $ odo catalog list components

    Example output

    Odo Devfile Components:
    NAME                 DESCRIPTION                            REGISTRY
    java-maven           Upstream Maven and OpenJDK 11          DefaultDevfileRegistry
    java-openliberty     Open Liberty microservice in Java      DefaultDevfileRegistry
    java-quarkus         Upstream Quarkus with Java+GraalVM     DefaultDevfileRegistry
    java-springboot      Spring Boot® using Java                DefaultDevfileRegistry
    nodejs               Stack with NodeJS 12                   DefaultDevfileRegistry
    
    Odo OpenShift Components:
    NAME        PROJECT       TAGS                                                                           SUPPORTED
    java        openshift     11,8,latest                                                                    YES
    dotnet      openshift     2.1,3.1,latest                                                                 NO
    golang      openshift     1.13.4-ubi7,1.13.4-ubi8,latest                                                 NO
    httpd       openshift     2.4-el7,2.4-el8,latest                                                         NO
    nginx       openshift     1.14-el7,1.14-el8,1.16-el7,1.16-el8,latest                                     NO
    nodejs      openshift     10-ubi7,10-ubi8,12-ubi7,12-ubi8,latest                                         NO
    perl        openshift     5.26-el7,5.26-ubi8,5.30-el7,latest                                             NO
    php         openshift     7.2-ubi7,7.2-ubi8,7.3-ubi7,7.3-ubi8,latest                                     NO
    python      openshift     2.7-ubi7,2.7-ubi8,3.6-ubi7,3.6-ubi8,3.8-ubi7,3.8-ubi8,latest                   NO
    ruby        openshift     2.5-ubi7,2.5-ubi8,2.6-ubi7,2.6-ubi8,2.7-ubi7,latest                            NO
    wildfly     openshift     10.0,10.1,11.0,12.0,13.0,14.0,15.0,16.0,17.0,18.0,19.0,20.0,8.1,9.0,latest     NO

    The TAGS column represents the available image versions, for example, 10 represents the rhoar-nodejs/nodejs-10 container image.

2.2. odo architecture

This section describes odo architecture and how odo manages resources on a cluster.

2.2.1. Developer setup

With odo you can create and deploy application on OpenShift Container Platform clusters from a terminal. Code editor plug-ins use odo which allows users to interact with OpenShift Container Platform clusters from their IDE terminals. Examples of plug-ins that use odo: VS Code OpenShift Connector, OpenShift Connector for Intellij, Codewind for Eclipse Che.

odo works on Windows, macOS, and Linux operating systems and from any terminal. odo provides autocompletion for bash and zsh command line shells.

odo supports Node.js and Java components.

2.2.2. OpenShift source-to-image

OpenShift Source-to-Image (S2I) is an open-source project which helps in building artifacts from source code and injecting these into container images. S2I produces ready-to-run images by building source code without the need of a Dockerfile. odo uses S2I builder image for executing developer source code inside a container.

2.2.3. OpenShift cluster objects

2.2.3.1. Init Containers

Init containers are specialized containers that run before the application container starts and configure the necessary environment for the application containers to run. Init containers can have files that application images do not have, for example setup scripts. Init containers always run to completion and the application container does not start if any of the init containers fails.

The pod created by odo executes two Init Containers:

  • The copy-supervisord Init container.
  • The copy-files-to-volume Init container.
2.2.3.1.1. copy-supervisord

The copy-supervisord Init container copies necessary files onto an emptyDir volume. The main application container utilizes these files from the emptyDir volume.

Files that are copied onto the emptyDir volume:

  • Binaries:

    • go-init is a minimal init system. It runs as the first process (PID 1) inside the application container. go-init starts the SupervisorD daemon which runs the developer code. go-init is required to handle orphaned processes.
    • SupervisorD is a process control system. It watches over configured processes and ensures that they are running. It also restarts services when necessary. For odo, SupervisorD executes and monitors the developer code.
  • Configuration files:

    • supervisor.conf is the configuration file necessary for the SupervisorD daemon to start.
  • Scripts:

    • assemble-and-restart is an OpenShift S2I concept to build and deploy user-source code. The assemble-and-restart script first assembles the user source code inside the application container and then restarts SupervisorD for user changes to take effect.
    • Run is an OpenShift S2I concept of executing the assembled source code. The run script executes the assembled code created by the assemble-and-restart script.
    • s2i-setup is a script that creates files and directories which are necessary for the assemble-and-restart and run scripts to execute successfully. The script is executed whenever the application container starts.
  • Directories:

    • language-scripts: OpenShift S2I allows custom assemble and run scripts. A few language specific custom scripts are present in the language-scripts directory. The custom scripts provide additional configuration to make odo debug work.

The emptyDir volume is mounted at the /opt/odo mount point for both the Init container and the application container.

2.2.3.1.2. copy-files-to-volume

The copy-files-to-volume Init container copies files that are in /opt/app-root in the S2I builder image onto the persistent volume. The volume is then mounted at the same location (/opt/app-root) in an application container.

Without the persistent volume on /opt/app-root the data in this directory is lost when the persistent volume claim is mounted at the same location.

The PVC is mounted at the /mnt mount point inside the Init container.

2.2.3.2. Application container

Application container is the main container inside of which the user-source code executes.

Application container is mounted with two volumes:

  • emptyDir volume mounted at /opt/odo
  • The persistent volume mounted at /opt/app-root

go-init is executed as the first process inside the application container. The go-init process then starts the SupervisorD daemon.

SupervisorD executes and monitors the user assembled source code. If the user process crashes, SupervisorD restarts it.

2.2.3.3. Persistent volumes and persistent volume claims

A persistent volume claim (PVC) is a volume type in Kubernetes which provisions a persistent volume. The life of a persistent volume is independent of a pod lifecycle. The data on the persistent volume persists across pod restarts.

The copy-files-to-volume Init container copies necessary files onto the persistent volume. The main application container utilizes these files at runtime for execution.

The naming convention of the persistent volume is <component_name>-s2idata.

ContainerPVC mounted at

copy-files-to-volume

/mnt

Application container

/opt/app-root

2.2.3.4. emptyDir volume

An emptyDir volume is created when a pod is assigned to a node, and exists as long as that pod is running on the node. If the container is restarted or moved, the content of the emptyDir is removed, Init container restores the data back to the emptyDir. emptyDir is initially empty.

The copy-supervisord Init container copies necessary files onto the emptyDir volume. These files are then utilized by the main application container at runtime for execution.

ContaineremptyDir volume mounted at

copy-supervisord

/opt/odo

Application container

/opt/odo

2.2.3.5. Service

A service is a Kubernetes concept of abstracting the way of communicating with a set of pods.

odo creates a service for every application pod to make it accessible for communication.

2.2.4. odo push workflow

This section describes odo push workflow. odo push deploys user code on an OpenShift Container Platform cluster with all the necessary OpenShift Container Platform resources.

  1. Creating resources

    If not already created, odo push creates the following OpenShift Container Platform resources:

    • DeploymentConfig object:

      • Two init containers are executed: copy-supervisord and copy-files-to-volume. The init containers copy files onto the emptyDir and the PersistentVolume type of volumes respectively.
      • The application container starts. The first process in the application container is the go-init process with PID=1.
      • go-init process starts the SupervisorD daemon.

        Note

        The user application code has not been copied into the application container yet, so the SupervisorD daemon does not execute the run script.

    • Service object
    • Secret objects
    • PersistentVolumeClaim object
  2. Indexing files

    • A file indexer indexes the files in the source code directory. The indexer traverses through the source code directories recursively and finds files which have been created, deleted, or renamed.
    • A file indexer maintains the indexed information in an odo index file inside the .odo directory.
    • If the odo index file is not present, it means that the file indexer is being executed for the first time, and creates a new odo index JSON file. The odo index JSON file contains a file map - the relative file paths of the traversed files and the absolute paths of the changed and deleted files.
  3. Pushing code

    Local code is copied into the application container, usually under /tmp/src.

  4. Executing assemble-and-restart

    On a successful copy of the source code, the assemble-and-restart script is executed inside the running application container.

2.3. Installing odo

The following section describes how to install odo on different platforms using the CLI.

Note

Currently, odo does not support installation in a restricted network environment.

You can also find the URL to the latest binaries from the OpenShift Container Platform web console by clicking the ? icon in the upper-right corner and selecting Command Line Tools

2.3.1. Installing odo on Linux

2.3.1.1. Binary installation

Procedure

  1. Obtain the binary:

    # curl -L https://mirror.openshift.com/pub/openshift-v4/clients/odo/latest/odo-linux-amd64 -o /usr/local/bin/odo
  2. Change the permissions on the file:

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

2.3.1.2. Tarball installation

Procedure

  1. Obtain the tarball:

    # sh -c 'curl -L https://mirror.openshift.com/pub/openshift-v4/clients/odo/latest/odo-linux-amd64.tar.gz | gzip -d > /usr/local/bin/odo'
  2. Change the permissions on the file:

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

2.3.2. Installing odo on Linux on IBM Power

2.3.2.1. Binary installation

Procedure

  1. Obtain the binary:

    # curl -L https://mirror.openshift.com/pub/openshift-v4/clients/odo/latest/odo-linux-ppc64le -o /usr/local/bin/odo
  2. Change the permissions on the file:

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

2.3.2.2. Tarball installation

Procedure

  1. Obtain the tarball:

    # sh -c 'curl -L https://mirror.openshift.com/pub/openshift-v4/clients/odo/latest/odo-linux-ppc64le.tar.gz | gzip -d > /usr/local/bin/odo'
  2. Change the permissions on the file:

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

2.3.3. Installing odo on Linux on IBM Z and LinuxONE

2.3.3.1. Binary installation

Procedure

  1. Obtain the binary:

    # curl -L https://mirror.openshift.com/pub/openshift-v4/clients/odo/latest/odo-linux-s390x -o /usr/local/bin/odo
  2. Change the permissions on the file:

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

2.3.3.2. Tarball installation

Procedure

  1. Obtain the tarball:

    # sh -c 'curl -L https://mirror.openshift.com/pub/openshift-v4/clients/odo/latest/odo-linux-s390x.tar.gz | gzip -d > /usr/local/bin/odo'
  2. Change the permissions on the file:

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

2.3.4. Installing odo on Windows

2.3.4.1. Binary installation

  1. Download the latest odo.exe file.
  2. Add the location of your odo.exe to your GOPATH/bin directory.
Setting the PATH variable for Windows 7/8

The following example demonstrates how to set up a path variable. Your binaries can be located in any location, but this example uses C:\go-bin as the location.

  1. Create a folder at C:\go-bin.
  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 the Advanced systems settings and click the Environment Variables button at the bottom.
  5. Select Path from the Variable section and click Edit.
  6. Click New and type C:\go-bin into the field or click Browse and select the directory, and click OK.
Setting the PATH variable for Windows 10

Edit Environment Variables using search:

  1. Click Search and type env or environment.
  2. Select Edit environment variables for your account.
  3. Select Path from the Variable section and click Edit.
  4. Click New and type C:\go-bin into the field or click Browse and select the directory, and click OK.

2.3.5. Installing odo on macOS

2.3.5.1. Binary installation

Procedure

  1. Obtain the binary:

    # curl -L https://mirror.openshift.com/pub/openshift-v4/clients/odo/latest/odo-darwin-amd64 -o /usr/local/bin/odo
  2. Change the permissions on the file:

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

2.3.5.2. Tarball installation

Procedure

  1. Obtain the tarball:

    # sh -c 'curl -L https://mirror.openshift.com/pub/openshift-v4/clients/odo/latest/odo-darwin-amd64.tar.gz | gzip -d > /usr/local/bin/odo'
  2. Change the permissions on the file:

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

2.4. Using odo in a restricted environment

2.4.1. About odo in a restricted environment

To run odo in a disconnected cluster or a cluster provisioned in a restricted environment, you must ensure that a cluster administrator has created a cluster with a mirrored registry.

To start working in a disconnected cluster, you must first push the odo init image to the registry of the cluster and then overwrite the odo init image path using the ODO_BOOTSTRAPPER_IMAGE environment variable.

After you push the odo init image, you must mirror a supported builder image from the registry, overwrite a mirror registry and then create your application. A builder image is necessary to configure a runtime environment for your application and also contains the build tool needed to build your application, for example npm for Node.js or Maven for Java. A mirror registry contains all the necessary dependencies for your application.

2.4.2. Pushing the odo init image to the restricted cluster registry

Depending on the configuration of your cluster and your operating system you can either push the odo init image to a mirror registry or directly to an internal registry.

2.4.2.1. Prerequisites

  • Install oc on the client operating system.
  • Install odo on the client operating system.
  • Access to a restricted cluster with a configured internal registry or a mirror registry.

2.4.2.2. Pushing the odo init image to a mirror registry

Depending on your operating system, you can push the odo init image to a cluster with a mirror registry as follows:

2.4.2.2.1. Pushing the init image to a mirror registry on Linux

Procedure

  1. Use base64 to encode the root certification authority (CA) content of your mirror registry:

    $ echo <content_of_additional_ca> | base64 --decode > disconnect-ca.crt
  2. Copy the encoded root CA certificate to the appropriate location:

    $ sudo cp ./disconnect-ca.crt /etc/pki/ca-trust/source/anchors/<mirror-registry>.crt
  3. Trust a CA in your client platform and log into the OpenShift Container Platform mirror registry:

    $ sudo update-ca-trust enable && sudo systemctl daemon-reload && sudo systemctl restart / docker && docker login <mirror-registry>:5000 -u <username> -p <password>
  4. Mirror the odo init image:

    $ oc image mirror registry.access.redhat.com/openshiftdo/odo-init-image-rhel7:<tag> <mirror-registry>:5000/openshiftdo/odo-init-image-rhel7:<tag>
  5. Override the default odo init image path by setting the ODO_BOOTSTRAPPER_IMAGE environment variable:

    $ export ODO_BOOTSTRAPPER_IMAGE=<mirror-registry>:5000/openshiftdo/odo-init-image-rhel7:<tag>
2.4.2.2.2. Pushing the init image to a mirror registry on MacOS

Procedure

  1. Use base64 to encode the root certification authority (CA) content of your mirror registry:

    $ echo <content_of_additional_ca> | base64 --decode > disconnect-ca.crt
  2. Copy the encoded root CA certificate to the appropriate location:

    1. Restart Docker using the Docker UI.
    2. Run the following command:

      $ docker login <mirror-registry>:5000 -u <username> -p <password>
  3. Mirror the odo init image:

    $ oc image mirror registry.access.redhat.com/openshiftdo/odo-init-image-rhel7:<tag> <mirror-registry>:5000/openshiftdo/odo-init-image-rhel7:<tag>
  4. Override the default odo init image path by setting the ODO_BOOTSTRAPPER_IMAGE environment variable:

    $ export ODO_BOOTSTRAPPER_IMAGE=<mirror-registry>:5000/openshiftdo/odo-init-image-rhel7:<tag>
2.4.2.2.3. Pushing the init image to a mirror registry on Windows

Procedure

  1. Use base64 to encode the root certification authority (CA) content of your mirror registry:

    PS C:\> echo <content_of_additional_ca> | base64 --decode > disconnect-ca.crt
  2. As an administrator, copy the encoded root CA certificate to the appropriate location by executing the following command:

    PS C:\WINDOWS\system32> certutil -addstore -f "ROOT" disconnect-ca.crt
  3. Trust a CA in your client platform and log into the OpenShift Container Platform mirror registry:

    1. Restart Docker using the Docker UI.
    2. Run the following command:

      PS C:\WINDOWS\system32> docker login <mirror-registry>:5000 -u <username> -p <password>
  4. Mirror the odo init image:

    PS C:\> oc image mirror registry.access.redhat.com/openshiftdo/odo-init-image-rhel7:<tag> <mirror-registry>:5000/openshiftdo/odo-init-image-rhel7:<tag>
  5. Override the default odo init image path by setting the ODO_BOOTSTRAPPER_IMAGE environment variable:

    PS C:\> $env:ODO_BOOTSTRAPPER_IMAGE="<mirror-registry>:5000/openshiftdo/odo-init-image-rhel7:<tag>"

2.4.2.3. Pushing the odo init image to an internal registry directly

If your cluster allows images to be pushed to the internal registry directly, push the odo init image to the registry as follows:

2.4.2.3.1. Pushing the init image directly on Linux

Procedure

  1. Enable the default route:

    $ oc patch configs.imageregistry.operator.openshift.io cluster -p '{"spec":{"defaultRoute":true}}' --type='merge' -n openshift-image-registry
  2. Get a wildcard route CA:

    $ oc get secret router-certs-default -n openshift-ingress -o yaml

    Example output

    apiVersion: v1
    data:
      tls.crt: **************************
      tls.key: ##################
    kind: Secret
    metadata:
      [...]
    type: kubernetes.io/tls

  3. Use base64 to encode the root certification authority (CA) content of your mirror registry:

    $ echo <tls.crt> | base64 --decode > ca.crt
  4. Trust a CA in your client platform:

    $ sudo cp ca.crt  /etc/pki/ca-trust/source/anchors/externalroute.crt && sudo update-ca-trust enable && sudo systemctl daemon-reload && sudo systemctl restart docker
  5. Log into the internal registry:

    $ oc get route -n openshift-image-registry
    NAME       HOST/PORT    PATH   SERVICES     PORT  TERMINATION   WILDCARD
    default-route   <registry_path>          image-registry   <all>   reencrypt     None
    
    $ docker login <registry_path> -u kubeadmin -p $(oc whoami -t)
  6. Push the odo init image:

    $ docker pull registry.access.redhat.com/openshiftdo/odo-init-image-rhel7:<tag>
    
    $ docker tag registry.access.redhat.com/openshiftdo/odo-init-image-rhel7:<tag> <registry_path>/openshiftdo/odo-init-image-rhel7:<tag>
    
    $ docker push <registry_path>/openshiftdo/odo-init-image-rhel7:<tag>
  7. Override the default odo init image path by setting the ODO_BOOTSTRAPPER_IMAGE environment variable:

    $ export ODO_BOOTSTRAPPER_IMAGE=<registry_path>/openshiftdo/odo-init-image-rhel7:1.0.1
2.4.2.3.2. Pushing the init image directly on MacOS

Procedure

  1. Enable the default route:

    $ oc patch configs.imageregistry.operator.openshift.io cluster -p '{"spec":{"defaultRoute":true}}' --type='merge' -n openshift-image-registry
  2. Get a wildcard route CA:

    $ oc get secret router-certs-default -n openshift-ingress -o yaml

    Example output

    apiVersion: v1
    data:
      tls.crt: **************************
      tls.key: ##################
    kind: Secret
    metadata:
      [...]
    type: kubernetes.io/tls

  3. Use base64 to encode the root certification authority (CA) content of your mirror registry:

    $ echo <tls.crt> | base64 --decode > ca.crt
  4. Trust a CA in your client platform:

    $ sudo security add-trusted-cert -d -r trustRoot -k /Library/Keychains/System.keychain ca.crt
  5. Log into the internal registry:

    $ oc get route -n openshift-image-registry
    NAME       HOST/PORT    PATH   SERVICES     PORT  TERMINATION   WILDCARD
    default-route   <registry_path>          image-registry   <all>   reencrypt     None
    
    $ docker login <registry_path> -u kubeadmin -p $(oc whoami -t)
  6. Push the odo init image:

    $ docker pull registry.access.redhat.com/openshiftdo/odo-init-image-rhel7:<tag>
    
    $ docker tag registry.access.redhat.com/openshiftdo/odo-init-image-rhel7:<tag> <registry_path>/openshiftdo/odo-init-image-rhel7:<tag>
    
    $ docker push <registry_path>/openshiftdo/odo-init-image-rhel7:<tag>
  7. Override the default odo init image path by setting the ODO_BOOTSTRAPPER_IMAGE environment variable:

    $ export ODO_BOOTSTRAPPER_IMAGE=<registry_path>/openshiftdo/odo-init-image-rhel7:1.0.1
2.4.2.3.3. Pushing the init image directly on Windows

Procedure

  1. Enable the default route:

    PS C:\> oc patch configs.imageregistry.operator.openshift.io cluster -p '{"spec":{"defaultRoute":true}}' --type='merge' -n openshift-image-registry
  2. Get a wildcard route CA:

    PS C:\> oc get secret router-certs-default -n openshift-ingress -o yaml

    Example output

    apiVersion: v1
    data:
      tls.crt: **************************
      tls.key: ##################
    kind: Secret
    metadata:
      [...]
    type: kubernetes.io/tls

  3. Use base64 to encode the root certification authority (CA) content of your mirror registry:

    PS C:\> echo <tls.crt> | base64 --decode > ca.crt
  4. As an administrator, trust a CA in your client platform by executing the following command:

    PS C:\WINDOWS\system32> certutil -addstore -f "ROOT" ca.crt
  5. Log into the internal registry:

    PS C:\> oc get route -n openshift-image-registry
    NAME       HOST/PORT    PATH   SERVICES     PORT  TERMINATION   WILDCARD
    default-route   <registry_path>          image-registry   <all>   reencrypt     None
    
    PS C:\> docker login <registry_path> -u kubeadmin -p $(oc whoami -t)
  6. Push the odo init image:

    PS C:\> docker pull registry.access.redhat.com/openshiftdo/odo-init-image-rhel7:<tag>
    
    PS C:\> docker tag registry.access.redhat.com/openshiftdo/odo-init-image-rhel7:<tag> <registry_path>/openshiftdo/odo-init-image-rhel7:<tag>
    
    PS C:\> docker push <registry_path>/openshiftdo/odo-init-image-rhel7:<tag>
  7. Override the default odo init image path by setting the ODO_BOOTSTRAPPER_IMAGE environment variable:

    PS C:\> $env:ODO_BOOTSTRAPPER_IMAGE="<registry_path>/openshiftdo/odo-init-image-rhel7:<tag>"

2.4.3. Creating and deploying a component to the disconnected cluster

After you push the init image to a cluster with a mirrored registry, you must mirror a supported builder image for your application with the oc tool, overwrite the mirror registry using the environment variable, and then create your component.

2.4.3.1. Prerequisites

2.4.3.2. Mirroring a supported builder image

To use npm packages for Node.js dependencies and Maven packages for Java dependencies and configure a runtime environment for your application, you must mirror a respective builder image from the mirror registry.

Procedure

  1. Verify that the required images tag is not imported:

    $ oc describe is nodejs -n openshift

    Example output

    Name:                   nodejs
    Namespace:              openshift
    [...]
    
    10
      tagged from <mirror-registry>:<port>/rhoar-nodejs/nodejs-10
        prefer registry pullthrough when referencing this tag
    
      Build and run Node.js 10 applications on RHEL 7. For more information about using this builder image, including OpenShift considerations, see https://github.com/nodeshift/centos7-s2i-nodejs.
      Tags: builder, nodejs, hidden
      Example Repo: https://github.com/sclorg/nodejs-ex.git
    
      ! error: Import failed (NotFound): dockerimage.image.openshift.io "<mirror-registry>:<port>/rhoar-nodejs/nodejs-10:latest" not found
          About an hour ago
    
    10-SCL (latest)
      tagged from <mirror-registry>:<port>/rhscl/nodejs-10-rhel7
        prefer registry pullthrough when referencing this tag
    
      Build and run Node.js 10 applications on RHEL 7. For more information about using this builder image, including OpenShift considerations, see https://github.com/nodeshift/centos7-s2i-nodejs.
      Tags: builder, nodejs
      Example Repo: https://github.com/sclorg/nodejs-ex.git
    
      ! error: Import failed (NotFound): dockerimage.image.openshift.io "<mirror-registry>:<port>/rhscl/nodejs-10-rhel7:latest" not found
          About an hour ago
    
    [...]

  2. Mirror the supported image tag to the private registry:

    $ oc image mirror registry.access.redhat.com/rhscl/nodejs-10-rhel7:<tag> <private_registry>/rhscl/nodejs-10-rhel7:<tag>
  3. Import the image:

    $ oc tag <mirror-registry>:<port>/rhscl/nodejs-10-rhel7:<tag> nodejs-10-rhel7:latest --scheduled

    You must periodically re-import the image. The --scheduled flag enables automatic re-import of the image.

  4. Verify that the images with the given tag have been imported:

    $ oc describe is nodejs -n openshift

    Example output

    Name:                   nodejs
    [...]
    10-SCL (latest)
      tagged from <mirror-registry>:<port>/rhscl/nodejs-10-rhel7
        prefer registry pullthrough when referencing this tag
    
      Build and run Node.js 10 applications on RHEL 7. For more information about using this builder image, including OpenShift considerations, see https://github.com/nodeshift/centos7-s2i-nodejs.
      Tags: builder, nodejs
      Example Repo: https://github.com/sclorg/nodejs-ex.git
    
      * <mirror-registry>:<port>/rhscl/nodejs-10-rhel7@sha256:d669ecbc11ac88293de50219dae8619832c6a0f5b04883b480e073590fab7c54
          3 minutes ago
    
    [...]

2.4.3.3. Overwriting the mirror registry

To download npm packages for Node.js dependencies and Maven packages for Java dependencies from a private mirror registry, you must create and configure a mirror npm or Maven registry on the cluster. You can then overwrite the mirror registry on an existing component or when you create a new component.

Procedure

  • To overwrite the mirror registry on an existing component:

    $ odo config set --env NPM_MIRROR=<npm_mirror_registry>
  • To overwrite the mirror registry when creating a component:

    $ odo component create nodejs --env NPM_MIRROR=<npm_mirror_registry>

2.4.3.4. Creating a Node.js application with odo

To create a Node.js component, download the Node.js application and push the source code to your cluster with odo.

Procedure

  1. Change the current directory to the directory with your application:

    $ cd <directory_name>
  2. Add a component of the type Node.js to your application:

    $ odo create nodejs
    Note

    By default, the latest image is used. You can also explicitly specify an image version by using odo create openshift/nodejs:8.

  3. Push the initial source code to the component:

    $ odo push

    Your component is now deployed to OpenShift Container Platform.

  4. Create a URL and add an entry in the local configuration file as follows:

    $ odo url create --port 8080
  5. Push the changes. This creates a URL on the cluster.

    $ odo push
  6. List the URLs to check the desired URL for the component.

    $ odo url list
  7. View your deployed application using the generated URL.

    $ curl <url>

2.5. Creating a single-component application with odo

With odo, you can create and deploy applications on clusters.

2.5.1. Prerequisites

2.5.2. Creating a project

Create a project to keep your source code, tests, and libraries organized in a separate single unit.

Procedure

  1. Log in to an OpenShift Container Platform cluster:

    $ odo login -u developer -p developer
  2. Create a project:

    $ odo project create myproject

    Example output

     ✓  Project 'myproject' is ready for use
     ✓  New project created and now using project : myproject

2.5.3. Creating a Node.js application with odo

To create a Node.js component, download the Node.js application and push the source code to your cluster with odo.

Procedure

  1. Create a directory for your components:

    $ mkdir my_components && cd my_components
  2. Download the example Node.js application:

    $ git clone https://github.com/openshift/nodejs-ex
  3. Change the current directory to the directory with your application:

    $ cd <directory_name>
  4. Add a component of the type Node.js to your application:

    $ odo create nodejs
    Note

    By default, the latest image is used. You can also explicitly specify an image version by using odo create openshift/nodejs:8.

  5. Push the initial source code to the component:

    $ odo push

    Your component is now deployed to OpenShift Container Platform.

  6. Create a URL and add an entry in the local configuration file as follows:

    $ odo url create --port 8080
  7. Push the changes. This creates a URL on the cluster.

    $ odo push
  8. List the URLs to check the desired URL for the component.

    $ odo url list
  9. View your deployed application using the generated URL.

    $ curl <url>

2.5.4. Modifying your application code

You can modify your application code and have the changes applied to your application on OpenShift Container Platform.

  1. Edit one of the layout files within the Node.js directory with your preferred text editor.
  2. Update your component:

    $ odo push
  3. Refresh your application in the browser to see the changes.

2.5.5. Adding storage to the application components

Persistent storage keeps data available between restarts of odo. Use the odo storage command to add persistent data to your application. Examples of data that must persist include database files, dependencies, and build artifacts, such as a .m2 Maven directory.

Procedure

  1. Add the storage to your component:

    $ odo storage create <storage_name> --path=<path_to_the_directory> --size=<size>
  2. Push the storage to the cluster:

    $ odo push
  3. Verify that the storage is now attached to your component by listing all storage in the component:

    $ odo storage list

    Example output

    The component 'nodejs' has the following storage attached:
    NAME           SIZE     PATH      STATE
    mystorage      1Gi      /data     Pushed

  4. Delete the storage from your component:

    $ odo storage delete <storage_name>
  5. List all storage to verify that the storage state is Locally Deleted:

    $ odo storage list

    Example output

    The component 'nodejs' has the following storage attached:
    NAME           SIZE     PATH      STATE
    mystorage      1Gi      /data     Locally Deleted

  6. Push the changes to the cluster:

    $ odo push

2.5.6. Adding a custom builder to specify a build image

With OpenShift Container Platform, you can add a custom image to bridge the gap between the creation of custom images.

The following example demonstrates the successful import and use of the redhat-openjdk-18 image:

Prerequisites

  • The OpenShift CLI (oc) is installed.

Procedure

  1. Import the image into OpenShift Container Platform:

    $ oc import-image openjdk18 \
    --from=registry.access.redhat.com/redhat-openjdk-18/openjdk18-openshift \
    --confirm
  2. Tag the image to make it accessible to odo:

    $ oc annotate istag/openjdk18:latest tags=builder
  3. Deploy the image with odo:

    $ odo create openjdk18 --git \
    https://github.com/openshift-evangelists/Wild-West-Backend

2.5.7. Connecting your application to multiple services using OpenShift Service Catalog

The OpenShift service catalog is an implementation of the Open Service Broker API (OSB API) for Kubernetes. You can use it to connect applications deployed in OpenShift Container Platform to a variety of services.

Prerequisites

  • You have a running OpenShift Container Platform cluster.
  • The service catalog is installed and enabled on your cluster.

Procedure

  • To list the services:

    $ odo catalog list services
  • To use service catalog-related operations:

    $ odo service <verb> <service_name>

2.5.8. Deleting an application

Important

Deleting an application will delete all components associated with the application.

Procedure

  1. List the applications in the current project:

    $ odo app list

    Example output

        The project '<project_name>' has the following applications:
        NAME
        app

  2. List the components associated with the applications. These components will be deleted with the application:

    $ odo component list

    Example output

        APP     NAME                      TYPE       SOURCE        STATE
        app     nodejs-nodejs-ex-elyf     nodejs     file://./     Pushed

  3. Delete the application:

    $ odo app delete <application_name>

    Example output

        ? Are you sure you want to delete the application: <application_name> from project: <project_name>

  4. Confirm the deletion with Y. You can suppress the confirmation prompt using the -f flag.

2.6. Creating a multicomponent application with odo

odo allows you to create a multicomponent application, modify it, and link its components in an easy and automated way.

This example describes how to deploy a multicomponent application - a shooter game. The application consists of a front-end Node.js component and a back-end Java component.

2.6.1. Prerequisites

  • odo is installed.
  • You have a running cluster. Developers can use CodeReady Containers (CRC) to deploy a local cluster quickly.
  • Maven is installed.

2.6.2. Creating a project

Create a project to keep your source code, tests, and libraries organized in a separate single unit.

Procedure

  1. Log in to an OpenShift Container Platform cluster:

    $ odo login -u developer -p developer
  2. Create a project:

    $ odo project create myproject

    Example output

     ✓  Project 'myproject' is ready for use
     ✓  New project created and now using project : myproject

2.6.3. Deploying the back-end component

To create a Java component, import the Java builder image, download the Java application and push the source code to your cluster with odo.

Procedure

  1. Import openjdk18 into the cluster:

    $ oc import-image openjdk18 \
    --from=registry.access.redhat.com/redhat-openjdk-18/openjdk18-openshift --confirm
  2. Tag the image as builder to make it accessible for odo:

    $ oc annotate istag/openjdk18:latest tags=builder
  3. Run odo catalog list components to see the created image:

    $ odo catalog list components

    Example output

    Odo Devfile Components:
    NAME                 DESCRIPTION                            REGISTRY
    java-maven           Upstream Maven and OpenJDK 11          DefaultDevfileRegistry
    java-openliberty     Open Liberty microservice in Java      DefaultDevfileRegistry
    java-quarkus         Upstream Quarkus with Java+GraalVM     DefaultDevfileRegistry
    java-springboot      Spring Boot® using Java                DefaultDevfileRegistry
    nodejs               Stack with NodeJS 12                   DefaultDevfileRegistry
    
    Odo OpenShift Components:
    NAME        PROJECT       TAGS                                                                           SUPPORTED
    java        openshift     11,8,latest                                                                    YES
    dotnet      openshift     2.1,3.1,latest                                                                 NO
    golang      openshift     1.13.4-ubi7,1.13.4-ubi8,latest                                                 NO
    httpd       openshift     2.4-el7,2.4-el8,latest                                                         NO
    nginx       openshift     1.14-el7,1.14-el8,1.16-el7,1.16-el8,latest                                     NO
    nodejs      openshift     10-ubi7,10-ubi8,12-ubi7,12-ubi8,latest                                         NO
    perl        openshift     5.26-el7,5.26-ubi8,5.30-el7,latest                                             NO
    php         openshift     7.2-ubi7,7.2-ubi8,7.3-ubi7,7.3-ubi8,latest                                     NO
    python      openshift     2.7-ubi7,2.7-ubi8,3.6-ubi7,3.6-ubi8,3.8-ubi7,3.8-ubi8,latest                   NO
    ruby        openshift     2.5-ubi7,2.5-ubi8,2.6-ubi7,2.6-ubi8,2.7-ubi7,latest                            NO
    wildfly     openshift     10.0,10.1,11.0,12.0,13.0,14.0,15.0,16.0,17.0,18.0,19.0,20.0,8.1,9.0,latest     NO

  4. Create a directory for your components:

    $ mkdir my_components && cd my_components
  5. Download the example back-end application:

    $ git clone https://github.com/openshift-evangelists/Wild-West-Backend backend
  6. Change to the back-end source directory:

    $ cd backend
  7. Check that you have the correct files in the directory:

    $ ls

    Example output

    debug.sh  pom.xml  src

  8. Build the back-end source files with Maven to create a JAR file:

    $ mvn package

    Example output

    ...
    [INFO] --------------------------------------
    [INFO] BUILD SUCCESS
    [INFO] --------------------------------------
    [INFO] Total time: 2.635 s
    [INFO] Finished at: 2019-09-30T16:11:11-04:00
    [INFO] Final Memory: 30M/91M
    [INFO] --------------------------------------

  9. Create a component configuration of Java component-type named backend:

    $ odo create openjdk18 backend --binary target/wildwest-1.0.jar

    Example output

     ✓  Validating component [1ms]
     Please use `odo push` command to create the component with source deployed

    Now the configuration file config.yaml is in the local directory of the back-end component that contains information about the component for deployment.

  10. Check the configuration settings of the back-end component in the config.yaml file using:

    $ odo config view

    Example output

    COMPONENT SETTINGS
    ------------------------------------------------
    PARAMETER         CURRENT_VALUE
    Type              openjdk18
    Application       app
    Project           myproject
    SourceType        binary
    Ref
    SourceLocation    target/wildwest-1.0.jar
    Ports             8080/TCP,8443/TCP,8778/TCP
    Name              backend
    MinMemory
    MaxMemory
    DebugPort
    Ignore
    MinCPU
    MaxCPU

  11. Push the component to the OpenShift Container Platform cluster.

    $ odo push

    Example output

    Validation
     ✓  Checking component [6ms]
    
    Configuration changes
     ✓  Initializing component
     ✓  Creating component [124ms]
    
    Pushing to component backend of type binary
     ✓  Checking files for pushing [1ms]
     ✓  Waiting for component to start [48s]
     ✓  Syncing files to the component [811ms]
     ✓  Building component [3s]

    Using odo push, OpenShift Container Platform creates a container to host the back-end component, deploys the container into a pod running on the OpenShift Container Platform cluster, and starts the backend component.

  12. Validate:

    • The status of the action in odo:

      $ odo log -f

      Example output

      2019-09-30 20:14:19.738  INFO 444 --- [           main] c.o.wildwest.WildWestApplication         : Starting WildWestApplication v1.0 onbackend-app-1-9tnhc with PID 444 (/deployments/wildwest-1.0.jar started by jboss in /deployments)

    • The status of the back-end component:

      $ odo list

      Example output

      APP     NAME        TYPE          SOURCE                             STATE
      app     backend     openjdk18     file://target/wildwest-1.0.jar     Pushed

2.6.4. Deploying the front-end component

To create and deploy a front-end component, download the Node.js application and push the source code to your cluster with odo.

Procedure

  1. Download the example front-end application:

    $ git clone https://github.com/openshift/nodejs-ex frontend
  2. Change the current directory to the front-end directory:

    $ cd frontend
  3. List the contents of the directory to see that the front end is a Node.js application.

    $ ls

    Example output

    README.md       openshift       server.js       views
    helm            package.json    tests

    Note

    The front-end component is written in an interpreted language (Node.js); it does not need to be built.

  4. Create a component configuration of Node.js component-type named frontend:

    $ odo create nodejs frontend

    Example output

     ✓  Validating component [5ms]
    Please use `odo push` command to create the component with source deployed

  5. Push the component to a running container.

    $ odo push

    Example output

    Validation
     ✓  Checking component [8ms]
    
    Configuration changes
     ✓  Initializing component
     ✓  Creating component [83ms]
    
    Pushing to component frontend of type local
     ✓  Checking files for pushing [2ms]
     ✓  Waiting for component to start [45s]
     ✓  Syncing files to the component [3s]
     ✓  Building component [18s]
     ✓  Changes successfully pushed to component

2.6.5. Linking both components

Components running on the cluster need to be connected in order to interact. OpenShift Container Platform provides linking mechanisms to publish communication bindings from a program to its clients.

Procedure

  1. List all the components that are running on the cluster:

    $ odo list

    Example output

    OpenShift Components:
    APP     NAME         PROJECT     TYPE          SOURCETYPE     STATE
    app     backend      testpro     openjdk18     binary         Pushed
    app     frontend     testpro     nodejs        local          Pushed

  2. Link the current front-end component to the back end:

    $ odo link backend --port 8080

    Example output

     ✓  Component backend has been successfully linked from the component frontend
    
    Following environment variables were added to frontend component:
    - COMPONENT_BACKEND_HOST
    - COMPONENT_BACKEND_PORT

    The configuration information of the back-end component is added to the front-end component and the front-end component restarts.

2.6.6. Exposing components to the public

Procedure

  1. Navigate to the frontend directory:

    $ cd frontend
  2. Create an external URL for the application:

    $ odo url create frontend --port 8080

    Example output

     ✓  URL frontend created for component: frontend
    
    To create URL on the OpenShift  cluster, use `odo push`

  3. Apply the changes:

    $ odo push

    Example output

    Validation
     ✓  Checking component [21ms]
    
    Configuration changes
     ✓  Retrieving component data [35ms]
     ✓  Applying configuration [29ms]
    
    Applying URL changes
     ✓  URL frontend: http://frontend-app-myproject.192.168.42.79.nip.io created
    
    Pushing to component frontend of type local
     ✓  Checking file changes for pushing [1ms]
     ✓  No file changes detected, skipping build. Use the '-f' flag to force the build.

  4. Open the URL in a browser to view the application.
Note

If an application requires permissions to the active service account to access the OpenShift Container Platform namespace and delete active pods, the following error may occur when looking at odo log from the back-end component:

Message: Forbidden!Configured service account doesn’t have access. Service account may have been revoked

To resolve this error, add permissions for the service account role:

$ oc policy add-role-to-group view system:serviceaccounts -n <project>
$ oc policy add-role-to-group edit system:serviceaccounts -n <project>

Do not do this on a production cluster.

2.6.7. Modifying the running application

Procedure

  1. Change the local directory to the front-end directory:

    $ cd frontend
  2. Monitor the changes on the file system using:

    $ odo watch
  3. Edit the index.html file to change the displayed name for the game.

    Note

    A slight delay is possible before odo recognizes the change.

    odo pushes the changes to the front-end component and prints its status to the terminal:

    File /root/frontend/index.html changed
    File  changed
    Pushing files...
     ✓  Waiting for component to start
     ✓  Copying files to component
     ✓  Building component
  4. Refresh the application page in the web browser. The new name is now displayed.

2.6.8. Deleting an application

Important

Deleting an application will delete all components associated with the application.

Procedure

  1. List the applications in the current project:

    $ odo app list

    Example output

        The project '<project_name>' has the following applications:
        NAME
        app

  2. List the components associated with the applications. These components will be deleted with the application:

    $ odo component list

    Example output

        APP     NAME                      TYPE       SOURCE        STATE
        app     nodejs-nodejs-ex-elyf     nodejs     file://./     Pushed

  3. Delete the application:

    $ odo app delete <application_name>

    Example output

        ? Are you sure you want to delete the application: <application_name> from project: <project_name>

  4. Confirm the deletion with Y. You can suppress the confirmation prompt using the -f flag.

2.7. Creating an application with a database

This example describes how to deploy and connect a database to a front-end application.

2.7.1. Prerequisites

  • odo is installed.
  • oc client is installed.
  • You have a running cluster. Developers can use CodeReady Containers (CRC) to deploy a local cluster quickly.
  • The Service Catalog is installed and enabled on your cluster.

    Note

    Service Catalog is deprecated on OpenShift Container Platform 4 and later.

2.7.2. Creating a project

Create a project to keep your source code, tests, and libraries organized in a separate single unit.

Procedure

  1. Log in to an OpenShift Container Platform cluster:

    $ odo login -u developer -p developer
  2. Create a project:

    $ odo project create myproject

    Example output

     ✓  Project 'myproject' is ready for use
     ✓  New project created and now using project : myproject

2.7.3. Deploying the front-end component

To create and deploy a front-end component, download the Node.js application and push the source code to your cluster with odo.

Procedure

  1. Download the example front-end application:

    $ git clone https://github.com/openshift/nodejs-ex frontend
  2. Change the current directory to the front-end directory:

    $ cd frontend
  3. List the contents of the directory to see that the front end is a Node.js application.

    $ ls

    Example output

    README.md       openshift       server.js       views
    helm            package.json    tests

    Note

    The front-end component is written in an interpreted language (Node.js); it does not need to be built.

  4. Create a component configuration of Node.js component-type named frontend:

    $ odo create nodejs frontend

    Example output

     ✓  Validating component [5ms]
    Please use `odo push` command to create the component with source deployed

  5. Create a URL to access the frontend interface.

    $ odo url create myurl

    Example output

     ✓  URL myurl created for component: nodejs-nodejs-ex-pmdp

  6. Push the component to the OpenShift Container Platform cluster.

    $ odo push

    Example output

    Validation
     ✓  Checking component [7ms]
    
     Configuration changes
     ✓  Initializing component
     ✓  Creating component [134ms]
    
     Applying URL changes
     ✓  URL myurl: http://myurl-app-myproject.192.168.42.79.nip.io created
    
     Pushing to component nodejs-nodejs-ex-mhbb of type local
     ✓  Checking files for pushing [657850ns]
     ✓  Waiting for component to start [6s]
     ✓  Syncing files to the component [408ms]
     ✓  Building component [7s]
     ✓  Changes successfully pushed to component

2.7.4. Deploying a database in interactive mode

odo provides a command-line interactive mode which simplifies deployment.

Procedure

  • Run the interactive mode and answer the prompts:

    $ odo service create

    Example output

    ? Which kind of service do you wish to create database
    ? Which database service class should we use mongodb-persistent
    ? Enter a value for string property DATABASE_SERVICE_NAME (Database Service Name): mongodb
    ? Enter a value for string property MEMORY_LIMIT (Memory Limit): 512Mi
    ? Enter a value for string property MONGODB_DATABASE (MongoDB Database Name): sampledb
    ? Enter a value for string property MONGODB_VERSION (Version of MongoDB Image): 3.2
    ? Enter a value for string property VOLUME_CAPACITY (Volume Capacity): 1Gi
    ? Provide values for non-required properties No
    ? How should we name your service  mongodb-persistent
    ? Output the non-interactive version of the selected options No
    ? Wait for the service to be ready No
     ✓  Creating service [32ms]
     ✓  Service 'mongodb-persistent' was created
    Progress of the provisioning will not be reported and might take a long time.
    You can see the current status by executing 'odo service list'

Note

Your password or username will be passed to the front-end application as environment variables.

2.7.5. Deploying a database manually

  1. List the available services:

    $ odo catalog list services

    Example output

    NAME                         PLANS
    django-psql-persistent       default
    jenkins-ephemeral            default
    jenkins-pipeline-example     default
    mariadb-persistent           default
    mongodb-persistent           default
    mysql-persistent             default
    nodejs-mongo-persistent      default
    postgresql-persistent        default
    rails-pgsql-persistent       default

  2. Choose the mongodb-persistent type of service and see the required parameters:

    $ odo catalog describe service mongodb-persistent

    Example output

      ***********************        | *****************************************************
      Name                           | default
      -----------------              | -----------------
      Display Name                   |
      -----------------              | -----------------
      Short Description              | Default plan
      -----------------              | -----------------
      Required Params without a      |
      default value                  |
      -----------------              | -----------------
      Required Params with a default | DATABASE_SERVICE_NAME
      value                          | (default: 'mongodb'),
                                     | MEMORY_LIMIT (default:
                                     | '512Mi'), MONGODB_VERSION
                                     | (default: '3.2'),
                                     | MONGODB_DATABASE (default:
                                     | 'sampledb'), VOLUME_CAPACITY
                                     | (default: '1Gi')
      -----------------              | -----------------
      Optional Params                | MONGODB_ADMIN_PASSWORD,
                                     | NAMESPACE, MONGODB_PASSWORD,
                                     | MONGODB_USER

  3. Pass the required parameters as flags and wait for the deployment of the database:

    $ odo service create mongodb-persistent --plan default --wait -p DATABASE_SERVICE_NAME=mongodb -p MEMORY_LIMIT=512Mi -p MONGODB_DATABASE=sampledb -p VOLUME_CAPACITY=1Gi

2.7.6. Connecting the database to the front-end application

  1. Link the database to the front-end service:

    $ odo link mongodb-persistent

    Example output

     ✓  Service mongodb-persistent has been successfully linked from the component nodejs-nodejs-ex-mhbb
    
    Following environment variables were added to nodejs-nodejs-ex-mhbb component:
    - database_name
    - password
    - uri
    - username
    - admin_password

  2. See the environment variables of the application and the database in the pod:

    1. Get the pod name:

      $ oc get pods

      Example output

      NAME                                READY     STATUS    RESTARTS   AGE
      mongodb-1-gsznc                     1/1       Running   0          28m
      nodejs-nodejs-ex-mhbb-app-4-vkn9l   1/1       Running   0          1m

    2. Connect to the pod:

      $ oc rsh nodejs-nodejs-ex-mhbb-app-4-vkn9l
    3. Check the environment variables:

      sh-4.2$ env

      Example output

      uri=mongodb://172.30.126.3:27017
      password=dHIOpYneSkX3rTLn
      database_name=sampledb
      username=user43U
      admin_password=NCn41tqmx7RIqmfv

  3. Open the URL in the browser and notice the database configuration in the bottom right:

    $ odo url list

    Example output

    Request information
    Page view count: 24
    
    DB Connection Info:
    Type:	MongoDB
    URL:	mongodb://172.30.126.3:27017/sampledb

2.7.7. Deleting an application

Important

Deleting an application will delete all components associated with the application.

Procedure

  1. List the applications in the current project:

    $ odo app list

    Example output

        The project '<project_name>' has the following applications:
        NAME
        app

  2. List the components associated with the applications. These components will be deleted with the application:

    $ odo component list

    Example output

        APP     NAME                      TYPE       SOURCE        STATE
        app     nodejs-nodejs-ex-elyf     nodejs     file://./     Pushed

  3. Delete the application:

    $ odo app delete <application_name>

    Example output

        ? Are you sure you want to delete the application: <application_name> from project: <project_name>

  4. Confirm the deletion with Y. You can suppress the confirmation prompt using the -f flag.

2.8. Using devfiles in odo

Important

Creating applications by using devfiles with `odo` is a Technology Preview feature only. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process.

For more information about the support scope of Red Hat Technology Preview features, see https://access.redhat.com/support/offerings/techpreview/.

2.8.1. About the devfile in odo

The devfile is a portable file that describes your development environment. With the devfile, you can define a portable developmental environment without the need for reconfiguration.

With the devfile, you can describe your development environment, such as the source code, IDE tools, application runtimes, and predefined commands. To learn more about the devfile, see the devfile documentation.

With odo, you can create components from the devfiles. When creating a component by using a devfile, odo transforms the devfile into a workspace consisting of multiple containers that run on OpenShift Container Platform, Kubernetes, or Docker. odo automatically uses the default devfile registry but users can add their own registries.

2.8.2. Creating a Java application by using a devfile

2.8.3. Prerequisites

  • You have installed odo.
  • You must know your ingress domain cluster name. Contact your cluster administrator if you do not know it. For example, apps-crc.testing is the cluster domain name for Red Hat CodeReady Containers.
  • You have enabled Experimental Mode in odo.

    • To enable Experimental Mode in odo preferences, run odo preference set Experimental true or use the environment variable odo config set --env ODO_EXPERIMENTAL=true

2.8.3.1. Creating a project

Create a project to keep your source code, tests, and libraries organized in a separate single unit.

Procedure

  1. Log in to an OpenShift Container Platform cluster:

    $ odo login -u developer -p developer
  2. Create a project:

    $ odo project create myproject

    Example output

     ✓  Project 'myproject' is ready for use
     ✓  New project created and now using project : myproject

2.8.3.2. Listing available devfile components

With odo, you can display all the components that are available for you on the cluster. Components that are available depend on the configuration of your cluster.

Procedure

  1. To list available devfile components on your cluster, run:

    $ odo catalog list components

    The output lists the available odo components:

    Odo Devfile Components:
    NAME                 DESCRIPTION                            REGISTRY
    java-maven           Upstream Maven and OpenJDK 11          DefaultDevfileRegistry
    java-openliberty     Open Liberty microservice in Java      DefaultDevfileRegistry
    java-quarkus         Upstream Quarkus with Java+GraalVM     DefaultDevfileRegistry
    java-springboot      Spring Boot® using Java                DefaultDevfileRegistry
    nodejs               Stack with NodeJS 12                   DefaultDevfileRegistry
    
    Odo OpenShift Components:
    NAME        PROJECT       TAGS                                                                           SUPPORTED
    java        openshift     11,8,latest                                                                    YES
    dotnet      openshift     2.1,3.1,latest                                                                 NO
    golang      openshift     1.13.4-ubi7,1.13.4-ubi8,latest                                                 NO
    httpd       openshift     2.4-el7,2.4-el8,latest                                                         NO
    nginx       openshift     1.14-el7,1.14-el8,1.16-el7,1.16-el8,latest                                     NO
    nodejs      openshift     10-ubi7,10-ubi8,12-ubi7,12-ubi8,latest                                         NO
    perl        openshift     5.26-el7,5.26-ubi8,5.30-el7,latest                                             NO
    php         openshift     7.2-ubi7,7.2-ubi8,7.3-ubi7,7.3-ubi8,latest                                     NO
    python      openshift     2.7-ubi7,2.7-ubi8,3.6-ubi7,3.6-ubi8,3.8-ubi7,3.8-ubi8,latest                   NO
    ruby        openshift     2.5-ubi7,2.5-ubi8,2.6-ubi7,2.6-ubi8,2.7-ubi7,latest                            NO
    wildfly     openshift     10.0,10.1,11.0,12.0,13.0,14.0,15.0,16.0,17.0,18.0,19.0,20.0,8.1,9.0,latest     NO

2.8.3.3. Deploying a Java application using a devfile

In this section, you will learn how to deploy a sample Java project that uses Maven and Java 8 JDK using a devfile.

Procedure

  1. Create a directory to store the source code of your component:

    $ mkdir <directory-name>
  2. Create a component configuration of Spring Boot component type named myspring and download its sample project:

    $ odo create java-spring-boot myspring --starter

    The previous command produces the following output:

    Experimental mode is enabled, use at your own risk
    
    Validation
    ✓  Checking devfile compatibility [195728ns]
    ✓  Creating a devfile component from registry: DefaultDevfileRegistry [170275ns]
    ✓  Validating devfile component [281940ns]
    
    Please use `odo push` command to create the component with source deployed

    The odo create command downloads the associated devfile.yaml file from the recorded devfile registries.

  3. List the contents of the directory to confirm that the devfile and the sample Java application were downloaded:

    $ ls

    The previous command produces the following output:

    README.md    devfile.yaml    pom.xml        src
  4. Create a URL to access the deployed component:

    $ odo url create --host apps-crc.testing

    The previous command produces the following output:

    ✓  URL myspring-8080.apps-crc.testing created for component: myspring
    
    To apply the URL configuration changes, please use odo push
    Note

    You must use your cluster host domain name when creating the URL.

  5. Push the component to the cluster:

    $ odo push

    The previous command produces the following output:

    Validation
     ✓  Validating the devfile [81808ns]
    
    Creating Kubernetes resources for component myspring
     ✓  Waiting for component to start [5s]
    
    Applying URL changes
     ✓  URL myspring-8080: http://myspring-8080.apps-crc.testing created
    
    Syncing to component myspring
     ✓  Checking files for pushing [2ms]
     ✓  Syncing files to the component [1s]
    
    Executing devfile commands for component myspring
     ✓  Executing devbuild command "/artifacts/bin/build-container-full.sh" [1m]
     ✓  Executing devrun command "/artifacts/bin/start-server.sh" [2s]
    
    Pushing devfile component myspring
     ✓  Changes successfully pushed to component
  6. List the URLs of the component to verify that the component was pushed successfully:

    $ odo url list

    The previous command produces the following output:

    Found the following URLs for component myspring
    NAME              URL                                       PORT     SECURE
    myspring-8080     http://myspring-8080.apps-crc.testing     8080     false
  7. View your deployed application by using the generated URL:

    $ curl http://myspring-8080.apps-crc.testing

2.8.4. Converting an S2I component into a devfile component

With odo, you can create both Source-to-Image (S2I) and devfile components. If you have an existing S2I component, you can convert it into a devfile component using the odo utils command.

Procedure

Run all the commands from the S2I component directory.

  1. Run the odo utils convert-to-devfile command, which creates devfile.yaml and env.yaml based on your component:

    $ odo utils convert-to-devfile
  2. Push the component to your cluster:

    $ odo push
    Note

    If the devfile component deployment failed, delete it by running: odo delete -a

  3. Verify that the devfile component deployed successfully:

    $ odo list
  4. Delete the S2I component:

    $ odo delete --s2i

2.9. Using sample applications

odo offers partial compatibility with any language or runtime listed within the OpenShift catalog of component types. For example:

NAME        PROJECT       TAGS
dotnet      openshift     2.0,latest
httpd       openshift     2.4,latest
java        openshift     8,latest
nginx       openshift     1.10,1.12,1.8,latest
nodejs      openshift     0.10,4,6,8,latest
perl        openshift     5.16,5.20,5.24,latest
php         openshift     5.5,5.6,7.0,7.1,latest
python      openshift     2.7,3.3,3.4,3.5,3.6,latest
ruby        openshift     2.0,2.2,2.3,2.4,latest
wildfly     openshift     10.0,10.1,8.1,9.0,latest
Note

For odo Java and Node.js are the officially supported component types. Run odo catalog list components to verify the officially supported component types.

In order to access the component over the web, create a URL using odo url create.

2.9.1. Examples from Git repositories

2.9.1.1. httpd

This example helps build and serve static content using httpd on CentOS 7. For more information about using this builder image, including OpenShift Container Platform considerations, see the Apache HTTP Server container image repository.

$ odo create httpd --git https://github.com/openshift/httpd-ex.git

2.9.1.2. java

This example helps build and run fat JAR Java applications on CentOS 7. For more information about using this builder image, including OpenShift Container Platform considerations, see the Java S2I Builder image.

$ odo create java --git https://github.com/spring-projects/spring-petclinic.git

2.9.1.3. nodejs

Build and run Node.js applications on CentOS 7. For more information about using this builder image, including OpenShift Container Platform considerations, see the Node.js 8 container image.

$ odo create nodejs --git https://github.com/openshift/nodejs-ex.git

2.9.1.4. perl

This example helps build and run Perl applications on CentOS 7. For more information about using this builder image, including OpenShift Container Platform considerations, see the Perl 5.26 container image.

$ odo create perl --git https://github.com/openshift/dancer-ex.git

2.9.1.5. php

This example helps build and run PHP applications on CentOS 7. For more information about using this builder image, including OpenShift Container Platform considerations, see the PHP 7.1 Docker image.

$ odo create php --git https://github.com/openshift/cakephp-ex.git

2.9.1.6. python

This example helps build and run Python applications on CentOS 7. For more information about using this builder image, including OpenShift Container Platform considerations, see the Python 3.6 container image.

$ odo create python --git https://github.com/openshift/django-ex.git

2.9.1.7. ruby

This example helps build and run Ruby applications on CentOS 7. For more information about using this builder image, including OpenShift Container Platform considerations, see Ruby 2.5 container image.

$ odo create ruby --git https://github.com/openshift/ruby-ex.git

2.9.1.8. wildfly

This example helps build and run WildFly applications on CentOS 7. For more information about using this builder image, including OpenShift Container Platform considerations, see the Wildfly - CentOS Docker images for OpenShift.

$ odo create wildfly --git https://github.com/openshift/openshift-jee-sample.git

2.9.2. Binary examples

2.9.2.1. java

Java can be used to deploy a binary artifact as follows:

$ git clone https://github.com/spring-projects/spring-petclinic.git
$ cd spring-petclinic
$ mvn package
$ odo create java test3 --binary target/*.jar
$ odo push

2.9.2.2. wildfly

WildFly can be used to deploy a binary application as follows:

$ git clone https://github.com/openshiftdemos/os-sample-java-web.git
$ cd os-sample-java-web
$ mvn package
$ cd ..
$ mkdir example && cd example
$ mv ../os-sample-java-web/target/ROOT.war example.war
$ odo create wildfly --binary example.war

2.10. Creating instances of services managed by Operators

Important

Creating instances of services managed by Operators in `odo` is a Technology Preview feature only. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process.

For more information about the support scope of Red Hat Technology Preview features, see https://access.redhat.com/support/offerings/techpreview/.

Operators are a method of packaging, deploying, and managing Kubernetes services. With odo, you can create instances of services from the custom resource definitions (CRDs) provided by the Operators. You can then use these instances in your projects and link them to your components.

To create services from an Operator, you must ensure that the Operator has valid values defined in its metadata to start the requested service. odo uses the metadata.annotations.alm-examples YAML file of an Operator to start the service. If this YAML has placeholder values or sample values, a service cannot start. You can modify the YAML file and start the service with the modified values. To learn how to modify YAML files and start services from it, see Creating services from YAML files.

2.10.1. Prerequisites

  • Install the oc CLI and log into the cluster.

    • Note that the configuration of the cluster determines the services available to you. To access the Operator services, a cluster administrator must install the respective Operator on the cluster first. To learn more, see Adding Operators to the cluster.
  • Install the odo CLI.
  • Enable experimental mode. To enable experimental mode in odo, run: odo preference set Experimental true or use the environment variable odo config set --env ODO_EXPERIMENTAL=true

2.10.2. Creating a project

Create a project to keep your source code, tests, and libraries organized in a separate single unit.

Procedure

  1. Log in to an OpenShift Container Platform cluster:

    $ odo login -u developer -p developer
  2. Create a project:

    $ odo project create myproject

    Example output

     ✓  Project 'myproject' is ready for use
     ✓  New project created and now using project : myproject

2.10.3. Listing available services from the Operators installed on the cluster

With odo, you can display the list of the Operators installed on your cluster, and the services they provide.

  • To list the Operators installed in current project, run:

    $ odo catalog list services

    The command lists Operators and the CRDs. The output of the command shows the Operators installed on your cluster. For example:

    Operators available in the cluster
    NAME                          CRDs
    etcdoperator.v0.9.4           EtcdCluster, EtcdBackup, EtcdRestore
    mongodb-enterprise.v1.4.5     MongoDB, MongoDBUser, MongoDBOpsManager

    etcdoperator.v0.9.4 is the Operator, EtcdCluster, EtcdBackup and EtcdRestore are the CRDs provided by the Operator.

2.10.4. Creating a service from an Operator

If an Operator has valid values defined in its metadata to start the requested service, you can use the service with odo service create.

  1. Print the YAML of the service as a file on your local drive:

    $ oc get csv/etcdoperator.v0.9.4 -o yaml
  2. Verify that the values of the service are valid:

    apiVersion: etcd.database.coreos.com/v1beta2
    kind: EtcdCluster
    metadata:
      name: example
    spec:
      size: 3
      version: 3.2.13
  3. Start an EtcdCluster service from the etcdoperator.v0.9.4 Operator:

    $ odo service create etcdoperator.v0.9.4 EtcdCluster
  4. Verify that a service has started:

    $ oc get EtcdCluster

2.10.5. Creating services from YAML files

If the YAML definition of the service or custom resource (CR) has invalid or placeholder data, you can use the --dry-run flag to get the YAML definition, specify the correct values, and start the service using the corrected YAML definition. Printing and modifying the YAML used to start a service odo provides the feature to print the YAML definition of the service or CR provided by the Operator before starting a service.

  1. To display the YAML of the service, run:

    $ odo service create <operator-name> --dry-run

    For example, to print YAML definition of EtcdCluster provided by the etcdoperator.v0.9.4 Operator, run:

    $ odo service create etcdoperator.v0.9.4 --dry-run

    The YAML is saved as the etcd.yaml file.

  2. Modify the etcd.yaml file:

    apiVersion: etcd.database.coreos.com/v1beta2
    kind: EtcdCluster
    metadata:
      name: my-etcd-cluster 1
    spec:
      size: 1 2
      version: 3.2.13
    1
    Change the name from example to my-etcd-cluster
    2
    Reduce the size from 3 to 1
  3. Start a service from the YAML file:

    $ odo service create --from-file etcd.yaml
  4. Verify that the EtcdCluster service has started with one pod instead of the pre-configured three pods:

    $ oc get pods | grep my-etcd-cluster

2.11. Debugging applications in odo

With odo, you can attach a debugger to remotely debug your application. This feature is only supported for NodeJS and Java components.

Components created with odo run in the debug mode by default. A debugger agent runs on the component, on a specific port. To start debugging your application, you must start port forwarding and attach the local debugger bundled in your Integrated development environment (IDE).

2.11.1. Debugging an application

You can debug your application on in odo with the odo debug command.

Procedure

  1. After an application is deployed, start the port forwarding for your component to debug the application:

    $ odo debug port-forward
  2. Attach the debugger bundled in your IDE to the component. Instructions vary depending on your IDE.

2.11.2. Configuring debugging parameters

You can specify a remote port with odo config command and a local port with the odo debug command.

Procedure

  • To set a remote port on which the debugging agent should run, run:

    $ odo config set DebugPort 9292
    Note

    You must redeploy your component for this value to be reflected on the component.

  • To set a local port to port forward, run:

    $ odo debug port-forward --local-port 9292
    Note

    The local port value does not persist. You must provide it every time you need to change the port.

2.12. Managing environment variables

odo stores component-specific configurations and environment variables in the config file. You can use the odo config command to set, unset, and list environment variables for components without the need to modify the config file.

2.12.1. Setting and unsetting environment variables

Procedure

  • To set an environment variable in a component:

    $ odo config set --env <variable>=<value>
  • To unset an environment variable in a component:

    $ odo config unset --env <variable>
  • To list all environment variables in a component:

    $ odo config view

2.13. Configuring the odo CLI

2.13.1. Using command completion

Note

Currently command completion is only supported for bash, zsh, and fish shells.

odo provides a smart completion of command parameters based on user input. For this to work, odo needs to integrate with the executing shell.

Procedure

  • To install command completion automatically:

    1. Run:

      $ odo --complete
    2. Press y when prompted to install the completion hook.
  • To install the completion hook manually, add complete -o nospace -C <full_path_to_your_odo_binary> odo to your shell configuration file. After any modification to your shell configuration file, restart your shell.
  • To disable completion:

    1. Run:

      $ odo --uncomplete
    2. Press y when prompted to uninstall the completion hook.
Note

Re-enable command completion if you either rename the odo executable or move it to a different directory.

2.13.2. Ignoring files or patterns

You can configure a list of files or patterns to ignore by modifying the .odoignore file in the root directory of your application. This applies to both odo push and odo watch.

If the .odoignore file does not exist, the .gitignore file is used instead for ignoring specific files and folders.

To ignore .git files, any files with the .js extension, and the folder tests, add the following to either the .odoignore or the .gitignore file:

.git
*.js
tests/

The .odoignore file allows any glob expressions.

2.14. odo CLI reference

2.14.1. Basic odo CLI commands

2.14.1.1. app

Perform application operations related to your OpenShift Container Platform project.

Example using app

  # Delete the application
  odo app delete myapp

  # Describe 'webapp' application,
  odo app describe webapp

  # List all applications in the current project
  odo app list

  # List all applications in the specified project
  odo app list --project myproject

2.14.1.2. catalog

Perform catalog-related operations.

Example using catalog

  # Get the supported components
  odo catalog list components

  # Get the supported services from service catalog
  odo catalog list services

  # Search for a component
  odo catalog search component python

  # Search for a service
  odo catalog search service mysql

  # Describe a service
  odo catalog describe service mysql-persistent

2.14.1.3. component

Manage components of an application.

Example using component

# Create a new component
odo component create

# Create a local configuration and create all objects on the cluster
odo component create --now

2.14.1.4. config

Modify odo specific settings within the config file.

Example using config

  # For viewing the current local configuration
  odo config view

  # Set a configuration value in the local configuration
  odo config set Type java
  odo config set Name test
  odo config set MinMemory 50M
  odo config set MaxMemory 500M
  odo config set Memory 250M
  odo config set Ignore false
  odo config set MinCPU 0.5
  odo config set MaxCPU 2
  odo config set CPU 1

  # Set an environment variable in the local configuration
  odo config set --env KAFKA_HOST=kafka --env KAFKA_PORT=6639

  # Create a local configuration and apply the changes to the cluster immediately
  odo config set --now

  # Unset a configuration value in the local config
  odo config unset Type
  odo config unset Name
  odo config unset MinMemory
  odo config unset MaxMemory
  odo config unset Memory
  odo config unset Ignore
  odo config unset MinCPU
  odo config unset MaxCPU
  odo config unset CPU

  # Unset an env variable in the local config
  odo config unset --env KAFKA_HOST --env KAFKA_PORT

Application

Application is the name of application the component needs to be part of

CPU

The minimum and maximum CPU a component can consume

Ignore

Consider the .odoignore file for push and watch

Table 2.2. Available Local Parameters:

Application

The name of application that the component needs to be part of

CPU

The minimum and maximum CPU a component can consume

Ignore

Whether to consider the .odoignore file for push and watch

MaxCPU

The maximum CPU a component can consume

MaxMemory

The maximum memory a component can consume

Memory

The minimum and maximum memory a component can consume

MinCPU

The minimum CPU a component can consume

MinMemory

The minimum memory a component is provided

Name

The name of the component

Ports

Ports to be opened in the component

Project

The name of the project that the component is part of

Ref

Git ref to use for creating component from git source

SourceLocation

The path indicates the location of binary file or git source

SourceType

Type of component source - git/binary/local

Storage

Storage of the component

Type

The type of component

Url

The URL to access the component

2.14.1.5. create

Create a configuration describing a component to be deployed on OpenShift Container Platform. If a component name is not provided, it is autogenerated.

By default, builder images are used from the current namespace. To explicitly supply a namespace, use: odo create namespace/name:version. If a version is not specified, the version defaults to latest.

Use odo catalog list to see a full list of component types that can be deployed.

Example using create

  # Create new Node.js component with the source in current directory.
  odo create nodejs

  # Create new Node.js component and push it to the cluster immediately.
  odo create nodejs --now

  # A specific image version may also be specified
  odo create nodejs:latest

  # Create new Node.js component named 'frontend' with the source in './frontend' directory
  odo create nodejs frontend --context ./frontend

  # Create a new Node.js component of version 6 from the 'openshift' namespace
  odo create openshift/nodejs:6 --context /nodejs-ex

  # Create new Wildfly component with binary named sample.war in './downloads' directory
  odo create wildfly wildfly --binary ./downloads/sample.war

  # Create new Node.js component with source from remote git repository
  odo create nodejs --git https://github.com/openshift/nodejs-ex.git

  # Create new Node.js git component while specifying a branch, tag or commit ref
  odo create nodejs --git https://github.com/openshift/nodejs-ex.git --ref master

  # Create new Node.js git component while specifying a tag
  odo create nodejs --git https://github.com/openshift/nodejs-ex.git --ref v1.0.1

  # Create new Node.js component with the source in current directory and ports 8080-tcp,8100-tcp and 9100-udp exposed
  odo create nodejs --port 8080,8100/tcp,9100/udp

  # Create new Node.js component with the source in current directory and env variables key=value and key1=value1 exposed
  odo create nodejs --env key=value,key1=value1

  # Create a new Python component with the source in a Git repository
  odo create python --git https://github.com/openshift/django-ex.git

  # Passing memory limits
  odo create nodejs --memory 150Mi
  odo create nodejs --min-memory 150Mi --max-memory 300 Mi

  # Passing cpu limits
  odo create nodejs --cpu 2
  odo create nodejs --min-cpu 200m --max-cpu 2

2.14.1.6. debug

Debug a component.

Example using debug

# Displaying information about the state of debugging
odo debug info

# Starting the port forwarding for a component to debug the application
odo debug port-forward

# Setting a local port to port forward
odo debug port-forward --local-port 9292

2.14.1.7. delete

Delete an existing component.

Example using delete

  # Delete component named 'frontend'.
  odo delete frontend
  odo delete frontend --all-apps

2.14.1.8. describe

Describe the given component.

Example using describe

  # Describe nodejs component
  odo describe nodejs

2.14.1.10. list

List all the components in the current application and the states of the components.

The states of the components

Pushed
A component is pushed to the cluster.
Not Pushed
A component is not pushed to the cluster.
Unknown
odo is disconnected from the cluster.

Example using list

  # List all components in the application
  odo list

  # List all the components in a given path
  odo list --path <path_to_your_component>

2.14.1.11. log

Retrieve the log for the given component.

Example using log

  # Get the logs for the nodejs component
  odo log nodejs

2.14.1.12. login

Log in to the cluster.

Example using login

  # Log in interactively
  odo login

  # Log in to the given server with the given certificate authority file
  odo login localhost:8443 --certificate-authority=/path/to/cert.crt

  # Log in to the given server with the given credentials (basic auth)
  odo login localhost:8443 --username=myuser --password=mypass

  # Log in to the given server with the given credentials (token)
  odo login localhost:8443 --token=xxxxxxxxxxxxxxxxxxxxxxx

2.14.1.13. logout

Log out of the current OpenShift Container Platform session.

Example using logout

  # Log out
  odo logout

2.14.1.14. preference

Modify odo specific configuration settings within the global preference file.

Example using preference

  # For viewing the current preferences
  odo preference view

  # Set a preference value in the global preference
  odo preference set UpdateNotification false
  odo preference set NamePrefix "app"
  odo preference set Timeout 20

  # Enable experimental mode
  odo preference set experimental true

  # Unset a preference value in the global preference
  odo preference unset  UpdateNotification
  odo preference unset  NamePrefix
  odo preference unset  Timeout

  # Disable experimental mode
  odo preference set experimental false

Note

By default, the path to the global preference file is ~/.odo/preferece.yaml and it is stored in the environment variable GLOBALODOCONFIG. You can set up a custom path by setting the value of the environment variable to a new preference path, for example GLOBALODOCONFIG="new_path/preference.yaml"

Table 2.3. Available Parameters:

NamePrefix

The default prefix is the current directory name. Use this value to set a default name prefix.

Timeout

The timeout (in seconds) for OpenShift Container Platform server connection checks.

UpdateNotification

Controls whether an update notification is shown.

2.14.1.15. project

Perform project operations.

Example using project

  # Set the active project
  odo project set

  # Create a new project
  odo project create myproject

  # List all the projects
  odo project list

  # Delete a project
  odo project delete myproject

  # Get the active project
  odo project get

2.14.1.16. push

Push source code to a component.

Example using push

  # Push source code to the current component
  odo push

  # Push data to the current component from the original source.
  odo push

  # Push source code in ~/mycode to component called my-component
  odo push my-component --context ~/mycode

  # Push source code and display event notifications in JSON format.
  odo push -o json

2.14.1.17. registry

Create and modify custom registries.

Example using registry

# Add a registry to the registry list
odo registry add <registry name> <registry URL>

# List a registry in the registry list
odo registry list

# Delete a registry from the registry list
odo registry delete <registry name>

# Update a registry in the registry list
odo registry update <registry name> <registry URL>

# List a component with a corresponding registry
odo catalog list components

# Create a component that is hosted by a specific registry
odo create <component type> --registry <registry name>

2.14.1.18. service

Perform service catalog operations.

Example using service

  # Create new postgresql service from service catalog using dev plan and name my-postgresql-db.
  odo service create dh-postgresql-apb my-postgresql-db --plan dev -p postgresql_user=luke -p postgresql_password=secret

  # Delete the service named 'mysql-persistent'
  odo service delete mysql-persistent

  # List all services in the application
  odo service list

2.14.1.19. storage

Perform storage operations.

Example using storage

  # Create storage of size 1Gb to a component
  odo storage create mystorage --path=/opt/app-root/src/storage/ --size=1Gi

  # Delete storage mystorage from the currently active component
  odo storage delete mystorage

  # List all storage attached or mounted to the current component and
  # all unattached or unmounted storage in the current application
  odo storage list

  # Set the `-o json` flag to get a JSON formatted output
  odo storage list -o json

2.14.1.21. update

Update the source code path of a component

Example using update

  # Change the source code path of a currently active component to local (use the current directory as a source)
  odo update --local

  # Change the source code path of the frontend component to local with source in ./frontend directory
  odo update frontend --local ./frontend

  # Change the source code path of a currently active component to git
  odo update --git https://github.com/openshift/nodejs-ex.git

  # Change the source code path of the component named node-ex to git
  odo update node-ex --git https://github.com/openshift/nodejs-ex.git

  # Change the source code path of the component named wildfly to a binary named sample.war in ./downloads directory
  odo update wildfly --binary ./downloads/sample.war

2.14.1.22. url

Expose a component to the outside world.

Example using url

  # Create a URL for the current component with a specific port
  odo url create --port 8080

  # Create a URL with a specific name and port
  odo url create example --port 8080

  # Create a URL with a specific name by automatic detection of port (only for components which expose only one service port)
  odo url create example

  # Create a URL with a specific name and port for component frontend
  odo url create example --port 8080 --component frontend

  # Delete a URL to a component
  odo url delete myurl

  # List the available URLs
  odo url list

  # Create a URL in the configuration and apply the changes to the cluster
  odo url create --now

  # Create an HTTPS URL
  odo url create --secure

The URLs that are generated using this command can be used to access the deployed components from outside the cluster.

2.14.1.23. utils

Utilities for terminal commands and modifying odo configurations.

Example using utils

  # Bash terminal PS1 support
  source <(odo utils terminal bash)

  # Zsh terminal PS1 support
  source <(odo utils terminal zsh)

2.14.1.24. version

Print the client version information.

Example using version

  # Print the client version of odo
  odo version

2.14.1.25. watch

odo starts watching for changes and updates the component upon a change automatically.

Example using watch

  # Watch for changes in directory for current component
  odo watch

  # Watch for changes in directory for component called frontend
  odo watch frontend

2.15. odo release notes

2.15.1. Notable changes and improvements in odo

  • The --devfile flag is added to odo create. Run odo create <component name> --devfile <devfile path> to specify your devfile location. This flag is only available in the Experimental Mode. See Technology Preview features to learn how to enable it.
  • Dynamic registry support. Now you can configure your own registries with the following commands:

    # Add a registry to the registry list
    odo registry add <registry name> <registry URL>
    
    # List a registry in the registry list
    odo registry list
    
    # Delete a registry from the registry list
    odo registry delete <registry name>
    
    # Update a registry in the registry list
    odo registry update <registry name> <registry URL>
    
    # List a component with a corresponding registry
    odo catalog list components
    
    # Create a component that is hosted by a specific registry
    odo create <component type> --registry <registry name>
  • The --starter flag is added to odo create. Run odo create nodejs --starter <project-name> to download the source code of a project specified in the devfile. If no project name is specified, odo downloads the first one.
  • The --context flag is added to odo push. With --context, you can trigger odo push from outside the source code directory. Run odo push --devfile <path to the devfile> --context <directory with your component> to specify the directory of your component.
  • Performance improvement for odo catalog list components when using the devfiles.
  • The --now flag is added for odo url delete when using the devfiles.
  • odo url delete --now now works with the devfiles.
  • The --debug flag now works with the devfiles.
  • Added machine-readable output for listing Operator-backed services. Run odo catalog list services -o json to display information about Operators and services in JSON format.
  • Added machine-readable output for debugging. Run odo debug info -o json to display the debugging information in JSON format.
  • Added machine-readable output for odo push. Run odo push -o json to display event notifications in JSON format.

2.15.2. Getting support

For Documentation

If you find an error or have suggestions for improving the documentation, file an issue in Bugzilla. Choose the OpenShift Container Platform product type and the Documentation component type.

For Product

If you find an error, encounter a bug, or have suggestions for improving the functionality of odo, file an issue in Bugzilla. Choose the Red Hat odo for OpenShift Container Platform product type.

Provide as many details in the issue description as possible.

2.15.3. Known issues

  • Bug 1760574 A deleted namespace is listed in the odo project get command.
  • Bug 1760586 The odo delete command starts an infinite loop after a project is deleted and a component name is set.
  • Bug 1760588 The odo service create command crashes when run in Cygwin.
  • Bug 1760590 In Git BASH for Windows, the odo login -u developer command does not hide a typed password when requested.
  • Bug 1783188 In a disconnected cluster, the odo component create command throws an error …​tag not found…​ despite the component being listed in the catalog list.
  • Bug 1761440 It is not possible to create two Services of the same type in one project.
  • Bug 1821643 odo push does not work on the .NET component tag 2.1+.

    Workaround: specify your .NET project file by running:

    $ odo config set --env DOTNET_STARTUP_PROJECT=<path to your project file>

2.15.4. Technology Preview features odo

  • odo debug is a feature that allows users to attach a local debugger to a component running in the Pod. To learn more, see Debugging applications in odo.
Important

odo debug is a Technology Preview feature only. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process.

For more information about the support scope of Red Hat Technology Preview features, see https://access.redhat.com/support/offerings/techpreview/.

  • Devfile support. With odo, you can create and deploy your applications using the devfiles. To learn more, see Creating applications by using devfiles. To access this feature, you must enable Experimental Mode with odo preference set experimental true.

    To see the list of currently supported devfile components, run odo catalog list components.

Important

Devfile support is a Technology Preview feature only. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process.

For more information about the support scope of Red Hat Technology Preview features, see https://access.redhat.com/support/offerings/techpreview/.

Important

Operators support is a Technology Preview feature only. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process.

For more information about the support scope of Red Hat Technology Preview features, see https://access.redhat.com/support/offerings/techpreview/.

Red Hat logoGithubRedditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

© 2024 Red Hat, Inc.