Este contenido no está disponible en el idioma seleccionado.

Chapter 3. Developer CLI (odo)

3.1. odo release notes
Copiar enlace

3.1.1. Notable changes and improvements in odo version 2.5.0
Copiar enlace

Creates unique routes for each component, using
```
adler32
```
hashing
Supports additional fields in the devfile for assigning resources:
- cpuRequest
- cpuLimit
- memoryRequest
- memoryLimit
Adds the
```
--deploy
```
flag to the
```
odo delete
```
command, to remove components deployed using the
```
odo deploy
```
command:
```
$ odo delete --deploy
```
Adds mapping support to the
```
odo link
```
command
Supports ephemeral volumes using the
```
ephemeral
```
field in
```
volume
```
components
Sets the default answer to
```
yes
```
when asking for telemetry opt-in
Improves metrics by sending additional telemetry data to the devfile registry

Updates the bootstrap image to

registry.access.redhat.com/ocp-tools-4/odo-init-container-rhel8:1.1.11

The upstream repository is available at https://github.com/redhat-developer/odo

3.1.2. Bug fixes
Copiar enlace

Previously,
```
odo deploy
```
would fail if the
```
.odo/env
```
file did not exist. The command now creates the
```
.odo/env
```
file if required.
Previously, interactive component creation using the
```
odo create
```
command would fail if disconnect from the cluster. This issue is fixed in the latest release.

3.1.3. Getting support
Copiar enlace

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 OpenShift Developer Tools and Services as a product type and odo as a component.

Provide as many details in the issue description as possible.

For Documentation

If you find an error or have suggestions for improving the documentation, file a Jira issue for the most relevant documentation component.

3.2. Understanding odo
Copiar enlace

Red Hat OpenShift Developer CLI (

odo

) is a tool for creating applications on OpenShift Container Platform and Kubernetes. With

odo

, you can develop, test, debug, and deploy microservices-based applications on a Kubernetes cluster without having a deep understanding of the platform.

odo

follows a create and push workflow. As a user, when you create, the information (or manifest) is stored in a configuration file. When you push, the corresponding resources are created on the Kubernetes cluster. All of this configuration is stored in the Kubernetes API for seamless accessibility and functionality.

odo

uses service and link commands to link components and services together.

odo

achieves this by creating and deploying services based on Kubernetes Operators in the cluster. Services can be created using any of the Operators available on the Operator Hub. After linking a service,

odo

injects the service configuration into the component. Your application can then use this configuration to communicate with the Operator-backed service.

3.2.1. odo key features
Copiar enlace

odo

is designed to be a developer-friendly interface to Kubernetes, with the ability to:

Quickly deploy applications on a Kubernetes cluster by creating a new manifest or using an existing one
Use commands to easily create and update the manifest, without the need to understand and maintain Kubernetes configuration files
Provide secure access to applications running on a Kubernetes cluster
Add and remove additional storage for applications on a Kubernetes cluster
Create Operator-backed services and link your application to them
Create a link between multiple microservices that are deployed as
```
odo
```
components
Remotely debug applications you deployed using
```
odo
```
in your IDE
Easily test applications deployed on Kubernetes using
```
odo
```

3.2.2. odo core concepts
Copiar enlace

odo

abstracts Kubernetes concepts into terminology that is familiar to developers:

Application

A typical application, developed with a cloud-native approach, that is used to perform a particular task.

Examples of applications include online video streaming, online shopping, and hotel reservation systems.

Component

A set of Kubernetes resources that can run and be deployed separately. A cloud-native application is a collection of small, independent, loosely coupled components.

Examples of components include an API back-end, a web interface, and a payment back-end.

Project

A single unit containing your source code, tests, and libraries.

Context

A directory that contains the source code, tests, libraries, and odo config files for a single component.

URL

A mechanism to expose a component for access from outside the cluster.

Storage

Persistent storage in the cluster. It persists the data across restarts and component rebuilds.

Service

An external application that provides additional functionality to a component.

Examples of services include PostgreSQL, MySQL, Redis, and RabbitMQ.

odo

, services are provisioned from the OpenShift Service Catalog and must be enabled within your cluster.

devfile

An open standard for defining containerized development environments that enables developer tools to simplify and accelerate workflows. For more information, see the documentation at https://devfile.io.

You can connect to publicly available devfile registries, or you can install a Secure Registry.

3.2.3. Listing components in odo
Copiar enlace

odo

uses the portable devfile format to describe components and their related URLs, storage, and services.

odo

can connect to various devfile registries to download devfiles for different languages and frameworks. See the documentation for the

odo registry

command for more information on how to manage the registries used by

odo

to retrieve devfile information.

You can list all the devfiles available of the different registries with the

odo catalog list components

command.

Procedure

odo

$ odo login -u developer -p developer

List the available

odo

components:

$ odo catalog list components

Example output

Odo Devfile Components:
NAME                             DESCRIPTION                                                         REGISTRY
dotnet50                         Stack with .NET 5.0                                                 DefaultDevfileRegistry
dotnet60                         Stack with .NET 6.0                                                 DefaultDevfileRegistry
dotnetcore31                     Stack with .NET Core 3.1                                            DefaultDevfileRegistry
go                               Stack with the latest Go version                                    DefaultDevfileRegistry
java-maven                       Upstream Maven and OpenJDK 11                                       DefaultDevfileRegistry
java-openliberty                 Java application Maven-built stack using the Open Liberty ru...     DefaultDevfileRegistry
java-openliberty-gradle          Java application Gradle-built stack using the Open Liberty r...     DefaultDevfileRegistry
java-quarkus                     Quarkus with Java                                                   DefaultDevfileRegistry
java-springboot                  Spring Boot® using Java                                             DefaultDevfileRegistry
java-vertx                       Upstream Vert.x using Java                                          DefaultDevfileRegistry
java-websphereliberty            Java application Maven-built stack using the WebSphere Liber...     DefaultDevfileRegistry
java-websphereliberty-gradle     Java application Gradle-built stack using the WebSphere Libe...     DefaultDevfileRegistry
java-wildfly                     Upstream WildFly                                                    DefaultDevfileRegistry
java-wildfly-bootable-jar        Java stack with WildFly in bootable Jar mode, OpenJDK 11 and...     DefaultDevfileRegistry
nodejs                           Stack with Node.js 14                                               DefaultDevfileRegistry
nodejs-angular                   Stack with Angular 12                                               DefaultDevfileRegistry
nodejs-nextjs                    Stack with Next.js 11                                               DefaultDevfileRegistry
nodejs-nuxtjs                    Stack with Nuxt.js 2                                                DefaultDevfileRegistry
nodejs-react                     Stack with React 17                                                 DefaultDevfileRegistry
nodejs-svelte                    Stack with Svelte 3                                                 DefaultDevfileRegistry
nodejs-vue                       Stack with Vue 3                                                    DefaultDevfileRegistry
php-laravel                      Stack with Laravel 8                                                DefaultDevfileRegistry
python                           Python Stack with Python 3.7                                        DefaultDevfileRegistry
python-django                    Python3.7 with Django                                               DefaultDevfileRegistry

3.2.4. Telemetry in odo
Copiar enlace

odo

collects information about how it is being used, including metrics on the operating system, RAM, CPU, number of cores,

odo

version, errors, success/failures, and how long

odo

commands take to complete.

You can modify your telemetry consent by using the

odo preference

command:

odo preference set ConsentTelemetry true

consents to telemetry.

```
odo preference unset ConsentTelemetry
```
disables telemetry.
```
odo preference view
```
shows the current preferences.

3.3. Installing odo
Copiar enlace

You can install the

odo

CLI on Linux, Windows, or macOS by downloading a binary. You can also install the OpenShift VS Code extension, which uses both the

odo

and the

oc

binaries to interact with your OpenShift Container Platform cluster. For Red Hat Enterprise Linux (RHEL), you can install the

odo

CLI as an RPM.

Note

Currently,

odo

does not support installation in a restricted network environment.

3.3.1. Installing odo on Linux
Copiar enlace

The

odo

CLI is available to download as a binary and as a tarball for multiple operating systems and architectures including:

Expand

Operating System	Binary	Tarball
Linux	odo-linux-amd64	odo-linux-amd64.tar.gz
Linux on IBM Power	odo-linux-ppc64le	odo-linux-ppc64le.tar.gz
Linux on IBM Z and LinuxONE	odo-linux-s390x	odo-linux-s390x.tar.gz

Procedure

Navigate to the content gateway and download the appropriate file for your operating system and architecture.

If you download the binary, rename it to

odo

$ curl -L https://developers.redhat.com/content-gateway/rest/mirror/pub/openshift-v4/clients/odo/latest/odo-linux-amd64 -o odo

If you download the tarball, extract the binary:

$ curl -L https://developers.redhat.com/content-gateway/rest/mirror/pub/openshift-v4/clients/odo/latest/odo-linux-amd64.tar.gz -o odo.tar.gz
$ tar xvzf odo.tar.gz

Change the permissions on the binary:
```
$ chmod +x <filename>
```
Place the
```
odo
```
binary in a directory that is on your
```
PATH
```
.
To check your
```
PATH
```
, execute the following command:
```
$ echo $PATH
```
Verify that
```
odo
```
is now available on your system:
```
$ odo version
```

3.3.2. Installing odo on Windows
Copiar enlace

The

odo

CLI for Windows is available to download as a binary and as an archive.

Expand

Operating System	Binary	Tarball
Windows	odo-windows-amd64.exe	odo-windows-amd64.exe.zip

Procedure

Navigate to the content gateway and download the appropriate file:
- If you download the binary, rename it to
  odo.exe
  .
- If you download the archive, unzip the binary with a ZIP program and then rename it to
  odo.exe
  .
Move the
```
odo.exe
```
binary to a directory that is on your
```
PATH
```
.
To check your
```
PATH
```
, open the command prompt and execute the following command:
```
C:\> path
```
Verify that
```
odo
```
is now available on your system:
```
C:\> odo version
```

3.3.3. Installing odo on macOS
Copiar enlace

The

odo

CLI for macOS is available to download as a binary and as a tarball.

Expand

Operating System	Binary	Tarball
macOS	odo-darwin-amd64	odo-darwin-amd64.tar.gz

Procedure

Navigate to the content gateway and download the appropriate file:

If you download the binary, rename it to

odo

$ curl -L https://developers.redhat.com/content-gateway/rest/mirror/pub/openshift-v4/clients/odo/latest/odo-darwin-amd64 -o odo

If you download the tarball, extract the binary:

$ curl -L https://developers.redhat.com/content-gateway/rest/mirror/pub/openshift-v4/clients/odo/latest/odo-darwin-amd64.tar.gz -o odo.tar.gz
$ tar xvzf odo.tar.gz

Change the permissions on the binary:
```
# chmod +x odo
```
Place the
```
odo
```
binary in a directory that is on your
```
PATH
```
.
To check your
```
PATH
```
, execute the following command:
```
$ echo $PATH
```
Verify that
```
odo
```
is now available on your system:
```
$ odo version
```

3.3.4. Installing odo on VS Code
Copiar enlace

The OpenShift VS Code extension uses both

odo

and the

oc

binary to interact with your OpenShift Container Platform cluster. To work with these features, install the OpenShift VS Code extension on VS Code.

Prerequisites

You have installed VS Code.

Procedure

Open VS Code.
Launch VS Code Quick Open with
```
Ctrl
```
+
```
P
```
.

Enter the following command:

$ ext install redhat.vscode-openshift-connector

3.3.5. Installing odo on Red Hat Enterprise Linux (RHEL) using an RPM
Copiar enlace

For Red Hat Enterprise Linux (RHEL), you can install the

odo

CLI as an RPM.

Procedure

Register with Red Hat Subscription Manager:
```
# subscription-manager register
```
Pull the latest subscription data:
```
# subscription-manager refresh
```

List the available subscriptions:

# subscription-manager list --available --matches '*OpenShift Developer Tools and Services*'

In the output of the previous command, find the
```
Pool ID
```
field for your OpenShift Container Platform subscription and attach the subscription to the registered system:
```
# subscription-manager attach --pool=<pool_id>
```

Enable the repositories required by

odo

# subscription-manager repos --enable="ocp-tools-4.9-for-rhel-8-x86_64-rpms"

Install the
```
odo
```
package:
```
# yum install odo
```
Verify that
```
odo
```
is now available on your system:
```
$ odo version
```

3.4. Configuring the odo CLI
Copiar enlace

You can find the global settings for

odo

in the

preference.yaml

file which is located by default in your

$HOME/.odo

directory.

You can set a different location for the

preference.yaml

file by exporting the

GLOBALODOCONFIG

variable.

3.4.1. Viewing the current configuration
Copiar enlace

You can view the current

odo

CLI configuration by using the following command:

$ odo preference view

Example output

PARAMETER             CURRENT_VALUE
UpdateNotification
NamePrefix
Timeout
BuildTimeout
PushTimeout
Ephemeral
ConsentTelemetry      true

3.4.2. Setting a value
Copiar enlace

You can set a value for a preference key by using the following command:

$ odo preference set <key> <value>

Note

Preference keys are case-insensitive.

Example command

$ odo preference set updatenotification false

Example output

Global preference was successfully updated

3.4.3. Unsetting a value
Copiar enlace

You can unset a value for a preference key by using the following command:

$ odo preference unset <key>

Note

You can use the

-f

flag to skip the confirmation.

Example command

$ odo preference unset updatenotification
? Do you want to unset updatenotification in the preference (y/N) y

Example output

Global preference was successfully updated

3.4.4. Preference key table
Copiar enlace

The following table shows the available options for setting preference keys for the

odo

CLI:

Expand

Preference key	Description	Default value
`UpdateNotification`	Control whether a notification to update `odo` is shown.	True
`NamePrefix`	Set a default name prefix for an `odo` resource. For example, `component` or `storage` .	Current directory name
`Timeout`	Timeout for the Kubernetes server connection check.	1 second
`BuildTimeout`	Timeout for waiting for a build of the git component to complete.	300 seconds
`PushTimeout`	Timeout for waiting for a component to start.	240 seconds
`Ephemeral`	Controls whether `odo` should create an `emptyDir` volume to store source code.	True
`ConsentTelemetry`	Controls whether `odo` can collect telemetry for the user’s `odo` usage.	False

3.4.5. Ignoring files or patterns
Copiar enlace

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.

3.5. odo CLI reference
Copiar enlace

3.5.1. odo build-images
Copiar enlace

odo

can build container images based on Dockerfiles, and push these images to their registries.

When running the

odo build-images

command,

odo

searches for all components in the

devfile.yaml

with the

image

type, for example:

components:
- image:
    imageName: quay.io/myusername/myimage
    dockerfile:
      uri: ./Dockerfile


      buildContext: ${PROJECTS_ROOT}


  name: component-built-from-dockerfile

1: The uri field indicates the relative path of the Dockerfile to use, relative to the directory containing the devfile.yaml. The devfile specification indicates that uri could also be an HTTP URL, but this case is not supported by odo yet.
2: The buildContext indicates the directory used as build context. The default value is ${PROJECTS_ROOT}.

For each image component, odo executes either

podman

docker

(the first one found, in this order), to build the image with the specified Dockerfile, build context, and arguments.

If the

--push

flag is passed to the command, the images are pushed to their registries after they are built.

3.5.2. odo catalog
Copiar enlace

odo

uses different catalogs to deploy components and services.

3.5.2.1. Components
Copiar enlace

odo

uses the portable devfile format to describe the components. It can connect to various devfile registries to download devfiles for different languages and frameworks. See

odo registry

for more information.

3.5.2.1.1. Listing components
Copiar enlace

To list all the devfiles available on the different registries, run the command:

$ odo catalog list components

Example output

 NAME             DESCRIPTION                          REGISTRY
 go               Stack with the latest Go version     DefaultDevfileRegistry
 java-maven       Upstream Maven and OpenJDK 11        DefaultDevfileRegistry
 nodejs           Stack with Node.js 14                DefaultDevfileRegistry
 php-laravel      Stack with Laravel 8                 DefaultDevfileRegistry
 python           Python Stack with Python 3.7         DefaultDevfileRegistry
 [...]

3.5.2.1.2. Getting information about a component
Copiar enlace

To get more information about a specific component, run the command:

$ odo catalog describe component

For example, run the command:

$ odo catalog describe component nodejs

Example output

* Registry: DefaultDevfileRegistry



Starter Projects:


---
name: nodejs-starter
attributes: {}
description: ""
subdir: ""
projectsource:
  sourcetype: ""
  git:
    gitlikeprojectsource:
      commonprojectsource: {}
      checkoutfrom: null
      remotes:
        origin: https://github.com/odo-devfiles/nodejs-ex.git
  zip: null
  custom: null

1: Registry is the registry from which the devfile is retrieved.
2: Starter projects are sample projects in the same language and framework of the devfile, that can help you start a new project.

See

odo create

for more information on creating a project from a starter project.

3.5.2.2. Services
Copiar enlace

odo

can deploy services with the help of Operators.

Only Operators deployed with the help of the Operator Lifecycle Manager are supported by odo.

3.5.2.2.1. Listing services
Copiar enlace

To list the available Operators and their associated services, run the command:

$ odo catalog list services

Example output

 Services available through Operators
 NAME                                 CRDs
 postgresql-operator.v0.1.1           Backup, Database
 redis-operator.v0.8.0                RedisCluster, Redis

In this example, two Operators are installed in the cluster. The

postgresql-operator.v0.1.1

Operator deploys services related to PostgreSQL:

Backup

and

Database

. The

redis-operator.v0.8.0

Operator deploys services related to Redis:

RedisCluster

and

Redis

Note

To get a list of all the available Operators,

odo

fetches the ClusterServiceVersion (CSV) resources of the current namespace that are in a Succeeded phase. For Operators that support cluster-wide access, when a new namespace is created, these resources are automatically added to it. However, it may take some time before they are in the Succeeded phase, and

odo

may return an empty list until the resources are ready.

3.5.2.2.2. Searching services
Copiar enlace

To search for a specific service by a keyword, run the command:

$ odo catalog search service

For example, to retrieve the PostgreSQL services, run the command:

$ odo catalog search service postgres

Example output

 Services available through Operators
 NAME                           CRDs
 postgresql-operator.v0.1.1     Backup, Database

You will see a list of Operators that contain the searched keyword in their name.

3.5.2.2.3. Getting information about a service
Copiar enlace

To get more information about a specific service, run the command:

$ odo catalog describe service

For example:

$ odo catalog describe service postgresql-operator.v0.1.1/Database

Example output

KIND:    Database
VERSION: v1alpha1

DESCRIPTION:
     Database is the Schema for the the Database Database API

FIELDS:
   awsAccessKeyId (string)
     AWS S3 accessKey/token ID

     Key ID of AWS S3 storage. Default Value: nil Required to create the Secret
     with the data to allow send the backup files to AWS S3 storage.
[...]

A service is represented in the cluster by a CustomResourceDefinition (CRD) resource. The previous command displays the details about the CRD such as

kind

version

, and the list of fields available to define an instance of this custom resource.

The list of fields is extracted from the OpenAPI schema included in the CRD. This information is optional in a CRD, and if it is not present, it is extracted from the ClusterServiceVersion (CSV) resource representing the service instead.

It is also possible to request the description of an Operator-backed service, without providing CRD type information. To describe the Redis Operator on a cluster, without CRD, run the following command:

$ odo catalog describe service redis-operator.v0.8.0

Example output

NAME:	redis-operator.v0.8.0
DESCRIPTION:

	A Golang based redis operator that will make/oversee Redis
	standalone/cluster mode setup on top of the Kubernetes. It can create a
	redis cluster setup with best practices on Cloud as well as the Bare metal
	environment. Also, it provides an in-built monitoring capability using

... (cut short for beverity)

	Logging Operator is licensed under [Apache License, Version
	2.0](https://github.com/OT-CONTAINER-KIT/redis-operator/blob/master/LICENSE)


CRDs:
	NAME           DESCRIPTION
	RedisCluster   Redis Cluster
	Redis          Redis

3.5.3. odo create
Copiar enlace

odo

uses a devfile to store the configuration of a component and to describe the component’s resources such as storage and services. The odo create command generates this file.

3.5.3.1. Creating a component
Copiar enlace

To create a devfile for an existing project, run the

odo create

command with the name and type of your component (for example,

nodejs

go

odo create nodejs mynodejs

In the example,

nodejs

is the type of the component and

mynodejs

is the name of the component that

odo

creates for you.

Note

For a list of all the supported component types, run the command

odo catalog list components

If your source code exists outside the current directory, the

--context

flag can be used to specify the path. For example, if the source for the nodejs component is in a folder called

node-backend

relative to the current working directory, run the command:

odo create nodejs mynodejs --context ./node-backend

The

--context

flag supports relative and absolute paths.

To specify the project or app where your component will be deployed, use the

--project

and

--app

flags. For example, to create a component that is part of the

myapp

app inside the

backend

project, run the command:

odo create nodejs --app myapp --project backend

Note

If these flags are not specified, they will default to the active app and project.

3.5.3.2. Starter projects
Copiar enlace

Use the starter projects if you do not have existing source code but want to get up and running quickly to experiment with devfiles and components. To use a starter project, add the

--starter

flag to the

odo create

command.

To get a list of available starter projects for a component type, run the

odo catalog describe component

command. For example, to get all available starter projects for the nodejs component type, run the command:

odo catalog describe component nodejs

Then specify the desired project using the

--starter

flag on the

odo create

command:

odo create nodejs --starter nodejs-starter

This will download the example template corresponding to the chosen component type, in this instance,

nodejs

. The template is downloaded to your current directory, or to the location specified by the

--context

flag. If a starter project has its own devfile, then this devfile will be preserved.

3.5.3.3. Using an existing devfile
Copiar enlace

If you want to create a new component from an existing devfile, you can do so by specifying the path to the devfile using the

--devfile

flag. For example, to create a component called

mynodejs

, based on a devfile from GitHub, use the following command:

odo create mynodejs --devfile https://raw.githubusercontent.com/odo-devfiles/registry/master/devfiles/nodejs/devfile.yaml

3.5.3.4. Interactive creation
Copiar enlace

You can also run the

odo create

command interactively, to guide you through the steps needed to create a component:

$ odo create

? Which devfile component type do you wish to create go
? What do you wish to name the new devfile component go-api
? What project do you want the devfile component to be created in default
Devfile Object Validation
 ✓  Checking devfile existence [164258ns]
 ✓  Creating a devfile component from registry: DefaultDevfileRegistry [246051ns]
Validation
 ✓  Validating if devfile name is correct [92255ns]
? Do you want to download a starter project Yes

Starter Project
 ✓  Downloading starter project go-starter from https://github.com/devfile-samples/devfile-stack-go.git [429ms]

Please use odo push command to create the component with source deployed

You are prompted to choose the component type, name, and the project for the component. You can also choose whether or not to download a starter project. Once finished, a new

devfile.yaml

file is created in the working directory.

To deploy these resources to your cluster, run the command

odo push

3.5.4. odo delete
Copiar enlace

The

odo delete

command is useful for deleting resources that are managed by

odo

3.5.4.1. Deleting a component
Copiar enlace

To delete a devfile component, run the

odo delete

command:

$ odo delete

If the component has been pushed to the cluster, the component is deleted from the cluster, along with its dependent storage, URL, secrets, and other resources. If the component has not been pushed, the command exits with an error stating that it could not find the resources on the cluster.

Use the

-f

--force

flag to avoid the confirmation questions.

3.5.4.2. Undeploying devfile Kubernetes components
Copiar enlace

To undeploy the devfile Kubernetes components, that have been deployed with

odo deploy

, execute the

odo delete

command with the

--deploy

flag:

$ odo delete --deploy

Use the

-f

--force

flag to avoid the confirmation questions.

3.5.4.3. Delete all
Copiar enlace

To delete all artifacts including the following items, run the

odo delete

command with the

--all

flag :

devfile component
Devfile Kubernetes component that was deployed using the
```
odo deploy
```
command
Devfile
Local configuration

$ odo delete --all

3.5.4.4. Available flags
Copiar enlace

-f, --force: Use this flag to avoid the confirmation questions.
-w, --wait: Use this flag to wait for component deletion and any dependencies. This flag does not work when undeploying.

The documentation on Common Flags provides more information on the flags available for commands.

3.5.5. odo deploy
Copiar enlace

odo

can be used to deploy components in a manner similar to how they would be deployed using a CI/CD system. First,

odo

builds the container images, and then it deploys the Kubernetes resources required to deploy the components.

When running the command

odo deploy

odo

searches for the default command of kind

deploy

in the devfile, and executes this command. The kind

deploy

is supported by the devfile format starting from version 2.2.0.

The

deploy

command is typically a composite command, composed of several apply commands:

A command referencing an
```
image
```
component that, when applied, will build the image of the container to deploy, and then push it to its registry.
A command referencing a Kubernetes component that, when applied, will create a Kubernetes resource in the cluster.

With the following example

devfile.yaml

file, a container image is built using the

Dockerfile

present in the directory. The image is pushed to its registry and then a Kubernetes Deployment resource is created in the cluster, using this freshly built image.

schemaVersion: 2.2.0
[...]
variables:
  CONTAINER_IMAGE: quay.io/phmartin/myimage
commands:
  - id: build-image
    apply:
      component: outerloop-build
  - id: deployk8s
    apply:
      component: outerloop-deploy
  - id: deploy
    composite:
      commands:
        - build-image
        - deployk8s
      group:
        kind: deploy
        isDefault: true
components:
  - name: outerloop-build
    image:
      imageName: "{{CONTAINER_IMAGE}}"
      dockerfile:
        uri: ./Dockerfile
        buildContext: ${PROJECTS_ROOT}
  - name: outerloop-deploy
    kubernetes:
      inlined: |
        kind: Deployment
        apiVersion: apps/v1
        metadata:
          name: my-component
        spec:
          replicas: 1
          selector:
            matchLabels:
              app: node-app
          template:
            metadata:
              labels:
                app: node-app
            spec:
              containers:
                - name: main
                  image: {{CONTAINER_IMAGE}}

3.5.6. odo link
Copiar enlace

The

odo link

command helps link an

odo

component to an Operator-backed service or another

odo

component. It does this by using the Service Binding Operator. Currently,

odo

makes use of the Service Binding library and not the Operator itself to achieve the desired functionality.

3.5.6.1. Various linking options
Copiar enlace

odo

provides various options for linking a component with an Operator-backed service or another

odo

component. All these options (or flags) can be used whether you are linking a component to a service or to another component.

3.5.6.1.1. Default behavior
Copiar enlace

By default, the

odo link

command creates a directory named

kubernetes/

in your component directory and stores the information (YAML manifests) about services and links there. When you use

odo push

odo

compares these manifests with the state of the resources on the Kubernetes cluster and decides whether it needs to create, modify or destroy resources to match what is specified by the user.

3.5.6.1.2. The --inlined flag
Copiar enlace

If you specify the

--inlined

flag to the

odo link

command,

odo

stores the link information inline in the

devfile.yaml

in the component directory, instead of creating a file under the

kubernetes/

directory. The behavior of the

--inlined

flag is similar in both the

odo link

and

odo service create

commands. This flag is helpful if you want everything stored in a single

devfile.yaml

. You have to remember to use

--inlined

flag with each

odo link

and

odo service create

command that you execute for the component.

3.5.6.1.3. The --map flag
Copiar enlace

Sometimes, you might want to add more binding information to the component, in addition to what is available by default. For example, if you are linking the component with a service and would like to bind some information from the service’s spec (short for specification), you could use the

--map

flag. Note that

odo

does not do any validation against the spec of the service or component being linked. Using this flag is only recommended if you are comfortable using the Kubernetes YAML manifests.

3.5.6.1.4. The --bind-as-files flag
Copiar enlace

For all the linking options discussed so far,

odo

injects the binding information into the component as environment variables. If you would like to mount this information as files instead, you can use the

--bind-as-files

flag. This will make

odo

inject the binding information as files into the

/bindings

location within your component’s Pod. Compared to the environment variables scenario, when you use

--bind-as-files

, the files are named after the keys and the value of these keys is stored as the contents of these files.

3.5.6.2. Examples
Copiar enlace

3.5.6.2.1. Default odo link
Copiar enlace

In the following example, the backend component is linked with the PostgreSQL service using the default

odo link

command. For the backend component, make sure that your component and service are pushed to the cluster:

$ odo list

Sample output

APP     NAME        PROJECT       TYPE       STATE      MANAGED BY ODO
app     backend     myproject     spring     Pushed     Yes

$ odo service list

Sample output

NAME                      MANAGED BY ODO     STATE      AGE
PostgresCluster/hippo     Yes (backend)      Pushed     59m41s

Now, run

odo link

to link the backend component with the PostgreSQL service:

$ odo link PostgresCluster/hippo

Example output

 ✓  Successfully created link between component "backend" and service "PostgresCluster/hippo"

To apply the link, please use `odo push`

And then run

odo push

to actually create the link on the Kubernetes cluster.

After a successful

odo push

, you will see a few outcomes:

When you open the URL for the application deployed by backend component, it shows a list of
```
todo
```
items in the database. For example, in the output for the
```
odo url list
```
command, the path where
```
todos
```
are listed is included:
```
$ odo url list
```
Sample output
```
Found the following URLs for component backend
NAME         STATE      URL                                       PORT     SECURE     KIND
8080-tcp     Pushed     http://8080-tcp.192.168.39.112.nip.io     8080     false      ingress
```
The correct path for the URL would be http://8080-tcp.192.168.39.112.nip.io/api/v1/todos. The exact URL depends on your setup. Also note that there are no
```
todos
```
in the database unless you add some, so the URL might just show an empty JSON object.

You can see binding information related to the Postgres service injected into the backend component. This binding information is injected, by default, as environment variables. You can check it using the

odo describe

command from the backend component’s directory:

$  odo describe

Example output:

Component Name: backend
Type: spring
Environment Variables:
  · PROJECTS_ROOT=/projects
  · PROJECT_SOURCE=/projects
  · DEBUG_PORT=5858
Storage:
  · m2 of size 3Gi mounted to /home/user/.m2
URLs:
  · http://8080-tcp.192.168.39.112.nip.io exposed via 8080
Linked Services:
  · PostgresCluster/hippo
    Environment Variables:
    · POSTGRESCLUSTER_PGBOUNCER-EMPTY
    · POSTGRESCLUSTER_PGBOUNCER.INI
    · POSTGRESCLUSTER_ROOT.CRT
    · POSTGRESCLUSTER_VERIFIER
    · POSTGRESCLUSTER_ID_ECDSA
    · POSTGRESCLUSTER_PGBOUNCER-VERIFIER
    · POSTGRESCLUSTER_TLS.CRT
    · POSTGRESCLUSTER_PGBOUNCER-URI
    · POSTGRESCLUSTER_PATRONI.CRT-COMBINED
    · POSTGRESCLUSTER_USER
    · pgImage
    · pgVersion
    · POSTGRESCLUSTER_CLUSTERIP
    · POSTGRESCLUSTER_HOST
    · POSTGRESCLUSTER_PGBACKREST_REPO.CONF
    · POSTGRESCLUSTER_PGBOUNCER-USERS.TXT
    · POSTGRESCLUSTER_SSH_CONFIG
    · POSTGRESCLUSTER_TLS.KEY
    · POSTGRESCLUSTER_CONFIG-HASH
    · POSTGRESCLUSTER_PASSWORD
    · POSTGRESCLUSTER_PATRONI.CA-ROOTS
    · POSTGRESCLUSTER_DBNAME
    · POSTGRESCLUSTER_PGBOUNCER-PASSWORD
    · POSTGRESCLUSTER_SSHD_CONFIG
    · POSTGRESCLUSTER_PGBOUNCER-FRONTEND.KEY
    · POSTGRESCLUSTER_PGBACKREST_INSTANCE.CONF
    · POSTGRESCLUSTER_PGBOUNCER-FRONTEND.CA-ROOTS
    · POSTGRESCLUSTER_PGBOUNCER-HOST
    · POSTGRESCLUSTER_PORT
    · POSTGRESCLUSTER_ROOT.KEY
    · POSTGRESCLUSTER_SSH_KNOWN_HOSTS
    · POSTGRESCLUSTER_URI
    · POSTGRESCLUSTER_PATRONI.YAML
    · POSTGRESCLUSTER_DNS.CRT
    · POSTGRESCLUSTER_DNS.KEY
    · POSTGRESCLUSTER_ID_ECDSA.PUB
    · POSTGRESCLUSTER_PGBOUNCER-FRONTEND.CRT
    · POSTGRESCLUSTER_PGBOUNCER-PORT
    · POSTGRESCLUSTER_CA.CRT

Some of these variables are used in the backend component’s

src/main/resources/application.properties

file so that the Java Spring Boot application can connect to the PostgreSQL database service.

Lastly,
```
odo
```
has created a directory called
```
kubernetes/
```
in your backend component’s directory that contains the following files:
```
$ ls kubernetes
odo-service-backend-postgrescluster-hippo.yaml  odo-service-hippo.yaml
```
These files contain the information (YAML manifests) for two resources:
1. odo-service-hippo.yaml
  - the Postgres service created using
  odo service create --from-file ../postgrescluster.yaml
  command.
2. odo-service-backend-postgrescluster-hippo.yaml
  - the link created using
  odo link
  command.

3.5.6.2.2. Using odo link with the --inlined flag
Copiar enlace

Using the

--inlined

flag with the

odo link

command has the same effect as an

odo link

command without the flag, in that it injects binding information. However, the subtle difference is that in the above case, there are two manifest files under

kubernetes/

directory, one for the Postgres service and another for the link between the backend component and this service. However, when you pass the

--inlined

flag,

odo

does not create a file under the

kubernetes/

directory to store the YAML manifest, but rather stores it inline in the

devfile.yaml

file.

To see this, unlink the component from the PostgreSQL service first:

$ odo unlink PostgresCluster/hippo

Example output:

 ✓  Successfully unlinked component "backend" from service "PostgresCluster/hippo"

To apply the changes, please use `odo push`

To unlink them on the cluster, run

odo push

. Now if you inspect the

kubernetes/

directory, you see only one file:

$ ls kubernetes
odo-service-hippo.yaml

Next, use the

--inlined

flag to create a link:

$ odo link PostgresCluster/hippo --inlined

Example output:

 ✓  Successfully created link between component "backend" and service "PostgresCluster/hippo"

To apply the link, please use `odo push`

You need to run

odo push

for the link to get created on the cluster, like the procedure that omits the

--inlined

flag.

odo

stores the configuration in

devfile.yaml

. In this file, you can see an entry like the following:

 kubernetes:
    inlined: |
      apiVersion: binding.operators.coreos.com/v1alpha1
      kind: ServiceBinding
      metadata:
        creationTimestamp: null
        name: backend-postgrescluster-hippo
      spec:
        application:
          group: apps
          name: backend-app
          resource: deployments
          version: v1
        bindAsFiles: false
        detectBindingResources: true
        services:
        - group: postgres-operator.crunchydata.com
          id: hippo
          kind: PostgresCluster
          name: hippo
          version: v1beta1
      status:
        secret: ""
  name: backend-postgrescluster-hippo

Now if you were to run

odo unlink PostgresCluster/hippo

odo

would first remove the link information from the

devfile.yaml

, and then a subsequent

odo push

would delete the link from the cluster.

3.5.6.2.3. Custom bindings
Copiar enlace

odo link

accepts the flag

--map

which can inject custom binding information into the component. Such binding information will be fetched from the manifest of the resource that you are linking to your component. For example, in the context of the backend component and PostgreSQL service, you can inject information from the PostgreSQL service’s manifest

postgrescluster.yaml

file into the backend component.

If the name of your

PostgresCluster

service is

hippo

(or the output of

odo service list

, if your PostgresCluster service is named differently), when you want to inject the value of

postgresVersion

from that YAML definition into your backend component, run the command:

$ odo link PostgresCluster/hippo --map pgVersion='{{ .hippo.spec.postgresVersion }}'

Note that, if the name of your Postgres service is different from

hippo

, you will have to specify that in the above command in the place of

.hippo

in the value for

pgVersion

After a link operation, run

odo push

as usual. Upon successful completion of the push operation, you can run the following command from your backend component directory, to validate if the custom mapping got injected properly:

$ odo exec -- env | grep pgVersion

Example output:

pgVersion=13

Since you might want to inject more than just one piece of custom binding information,

odo link

accepts multiple key-value pairs of mappings. The only constraint is that these should be specified as

--map <key>=<value>

. For example, if you want to also inject PostgreSQL image information along with the version, you could run:

$ odo link PostgresCluster/hippo --map pgVersion='{{ .hippo.spec.postgresVersion }}' --map pgImage='{{ .hippo.spec.image }}'

and then run

odo push

. To validate if both the mappings got injected correctly, run the following command:

$ odo exec -- env | grep -e "pgVersion\|pgImage"

Example output:

pgVersion=13
pgImage=registry.developers.crunchydata.com/crunchydata/crunchy-postgres-ha:centos8-13.4-0

3.5.6.2.3.1. To inline or not?
Copiar enlace

You can accept the default behavior where

odo link

generate a manifests file for the link under

kubernetes/

directory. Alternatively, you can use the

--inlined

flag if you prefer to store everything in a single

devfile.yaml

file.

3.5.6.3. Binding as files
Copiar enlace

Another helpful flag that

odo link

provides is

--bind-as-files

. When this flag is passed, the binding information is not injected into the component’s Pod as environment variables but is mounted as a filesystem.

Ensure that there are no existing links between the backend component and the PostgreSQL service. You could do this by running

odo describe

in the backend component’s directory and check if you see output similar to the following:

Linked Services:
 · PostgresCluster/hippo

Unlink the service from the component using:

$ odo unlink PostgresCluster/hippo
$ odo push

3.5.6.4. --bind-as-files examples
Copiar enlace

3.5.6.4.1. Using the default odo link
Copiar enlace

By default,

odo

creates the manifest file under the

kubernetes/

directory, for storing the link information. Link the backend component and PostgreSQL service using:

$ odo link PostgresCluster/hippo --bind-as-files
$ odo push

Example odo describe output:

$ odo describe

Component Name: backend
Type: spring
Environment Variables:
 · PROJECTS_ROOT=/projects
 · PROJECT_SOURCE=/projects
 · DEBUG_PORT=5858
 · SERVICE_BINDING_ROOT=/bindings
 · SERVICE_BINDING_ROOT=/bindings
Storage:
 · m2 of size 3Gi mounted to /home/user/.m2
URLs:
 · http://8080-tcp.192.168.39.112.nip.io exposed via 8080
Linked Services:
 · PostgresCluster/hippo
   Files:
    · /bindings/backend-postgrescluster-hippo/pgbackrest_instance.conf
    · /bindings/backend-postgrescluster-hippo/user
    · /bindings/backend-postgrescluster-hippo/ssh_known_hosts
    · /bindings/backend-postgrescluster-hippo/clusterIP
    · /bindings/backend-postgrescluster-hippo/password
    · /bindings/backend-postgrescluster-hippo/patroni.yaml
    · /bindings/backend-postgrescluster-hippo/pgbouncer-frontend.crt
    · /bindings/backend-postgrescluster-hippo/pgbouncer-host
    · /bindings/backend-postgrescluster-hippo/root.key
    · /bindings/backend-postgrescluster-hippo/pgbouncer-frontend.key
    · /bindings/backend-postgrescluster-hippo/pgbouncer.ini
    · /bindings/backend-postgrescluster-hippo/uri
    · /bindings/backend-postgrescluster-hippo/config-hash
    · /bindings/backend-postgrescluster-hippo/pgbouncer-empty
    · /bindings/backend-postgrescluster-hippo/port
    · /bindings/backend-postgrescluster-hippo/dns.crt
    · /bindings/backend-postgrescluster-hippo/pgbouncer-uri
    · /bindings/backend-postgrescluster-hippo/root.crt
    · /bindings/backend-postgrescluster-hippo/ssh_config
    · /bindings/backend-postgrescluster-hippo/dns.key
    · /bindings/backend-postgrescluster-hippo/host
    · /bindings/backend-postgrescluster-hippo/patroni.crt-combined
    · /bindings/backend-postgrescluster-hippo/pgbouncer-frontend.ca-roots
    · /bindings/backend-postgrescluster-hippo/tls.key
    · /bindings/backend-postgrescluster-hippo/verifier
    · /bindings/backend-postgrescluster-hippo/ca.crt
    · /bindings/backend-postgrescluster-hippo/dbname
    · /bindings/backend-postgrescluster-hippo/patroni.ca-roots
    · /bindings/backend-postgrescluster-hippo/pgbackrest_repo.conf
    · /bindings/backend-postgrescluster-hippo/pgbouncer-port
    · /bindings/backend-postgrescluster-hippo/pgbouncer-verifier
    · /bindings/backend-postgrescluster-hippo/id_ecdsa
    · /bindings/backend-postgrescluster-hippo/id_ecdsa.pub
    · /bindings/backend-postgrescluster-hippo/pgbouncer-password
    · /bindings/backend-postgrescluster-hippo/pgbouncer-users.txt
    · /bindings/backend-postgrescluster-hippo/sshd_config
    · /bindings/backend-postgrescluster-hippo/tls.crt

Everything that was an environment variable in the

key=value

format in the earlier

odo describe

output is now mounted as a file. Use the

cat

command to view the contents of some of these files:

Example command:

$ odo exec -- cat /bindings/backend-postgrescluster-hippo/password

Example output:

q({JC:jn^mm/Bw}eu+j.GX{k

Example command:

$ odo exec -- cat /bindings/backend-postgrescluster-hippo/user

Example output:

hippo

Example command:

$ odo exec -- cat /bindings/backend-postgrescluster-hippo/clusterIP

Example output:

10.101.78.56

3.5.6.4.2. Using --inlined
Copiar enlace

The result of using

--bind-as-files

and

--inlined

together is similar to using

odo link --inlined

. The manifest of the link gets stored in the

devfile.yaml

, instead of being stored in a separate file under

kubernetes/

directory. Other than that, the

odo describe

output would be the same as earlier.

3.5.6.4.3. Custom bindings
Copiar enlace

When you pass custom bindings while linking the backend component with the PostgreSQL service, these custom bindings are injected not as environment variables but are mounted as files. For example:

$ odo link PostgresCluster/hippo --map pgVersion='{{ .hippo.spec.postgresVersion }}' --map pgImage='{{ .hippo.spec.image }}' --bind-as-files
$ odo push

These custom bindings get mounted as files instead of being injected as environment variables. To validate that this worked, run the following command:

Example command:

$ odo exec -- cat /bindings/backend-postgrescluster-hippo/pgVersion

Example output:

Example command:

$ odo exec -- cat /bindings/backend-postgrescluster-hippo/pgImage

Example output:

registry.developers.crunchydata.com/crunchydata/crunchy-postgres-ha:centos8-13.4-0

3.5.7. odo registry
Copiar enlace

odo

uses the portable devfile format to describe the components.

odo

can connect to various devfile registries, to download devfiles for different languages and frameworks.

You can connect to publicly available devfile registries, or you can install your own Secure Registry.

You can use the

odo registry

command to manage the registries that are used by

odo

to retrieve devfile information.

3.5.7.1. Listing the registries
Copiar enlace

To list the registries currently contacted by

odo

, run the command:

$ odo registry list

Example output:

NAME                       URL                             SECURE
DefaultDevfileRegistry     https://registry.devfile.io     No

DefaultDevfileRegistry

is the default registry used by odo; it is provided by the devfile.io project.

3.5.7.2. Adding a registry
Copiar enlace

To add a registry, run the command:

$ odo registry add

Example output:

$ odo registry add StageRegistry https://registry.stage.devfile.io
New registry successfully added

If you are deploying your own Secure Registry, you can specify the personal access token to authenticate to the secure registry with the

--token

flag:

$ odo registry add MyRegistry https://myregistry.example.com --token <access_token>
New registry successfully added

3.5.7.3. Deleting a registry
Copiar enlace

To delete a registry, run the command:

$ odo registry delete

Example output:

$ odo registry delete StageRegistry
? Are you sure you want to delete registry "StageRegistry" Yes
Successfully deleted registry

Use the

--force

(or

-f

) flag to force the deletion of the registry without confirmation.

3.5.7.4. Updating a registry
Copiar enlace

To update the URL or the personal access token of a registry already registered, run the command:

$ odo registry update

Example output:

 $ odo registry update MyRegistry https://otherregistry.example.com --token <other_access_token>
 ? Are you sure you want to update registry "MyRegistry" Yes
 Successfully updated registry

Use the

--force

(or

-f

) flag to force the update of the registry without confirmation.

3.5.8. odo service
Copiar enlace

odo

can deploy services with the help of Operators.

The list of available Operators and services available for installation can be found using the

odo catalog

command.

Services are created in the context of a component, so run the

odo create

command before you deploy services.

A service is deployed using two steps:

Define the service and store its definition in the devfile.
Deploy the defined service to the cluster, using the
```
odo push
```
command.

3.5.8.1. Creating a new service
Copiar enlace

To create a new service, run the command:

$ odo service create

For example, to create an instance of a Redis service named

my-redis-service

, you can run the following command:

Example output

$ odo catalog list services
Services available through Operators
NAME                      CRDs
redis-operator.v0.8.0     RedisCluster, Redis

$ odo service create redis-operator.v0.8.0/Redis my-redis-service
Successfully added service to the configuration; do 'odo push' to create service on the cluster

This command creates a Kubernetes manifest in the

kubernetes/

directory, containing the definition of the service, and this file is referenced from the

devfile.yaml

file.

$ cat kubernetes/odo-service-my-redis-service.yaml

Example output

 apiVersion: redis.redis.opstreelabs.in/v1beta1
 kind: Redis
 metadata:
   name: my-redis-service
 spec:
   kubernetesConfig:
     image: quay.io/opstree/redis:v6.2.5
     imagePullPolicy: IfNotPresent
     resources:
       limits:
         cpu: 101m
         memory: 128Mi
       requests:
         cpu: 101m
         memory: 128Mi
     serviceType: ClusterIP
   redisExporter:
     enabled: false
     image: quay.io/opstree/redis-exporter:1.0
   storage:
     volumeClaimTemplate:
       spec:
         accessModes:
         - ReadWriteOnce
         resources:
           requests:
             storage: 1Gi

Example command

$ cat devfile.yaml

Example output

[...]
components:
- kubernetes:
    uri: kubernetes/odo-service-my-redis-service.yaml
  name: my-redis-service
[...]

Note that the name of the created instance is optional. If you do not provide a name, it will be the lowercase name of the service. For example, the following command creates an instance of a Redis service named

redis

$ odo service create redis-operator.v0.8.0/Redis

3.5.8.1.1. Inlining the manifest
Copiar enlace

By default, a new manifest is created in the

kubernetes/

directory, referenced from the

devfile.yaml

file. It is possible to inline the manifest inside the

devfile.yaml

file using the

--inlined

flag:

$ odo service create redis-operator.v0.8.0/Redis my-redis-service --inlined
Successfully added service to the configuration; do 'odo push' to create service on the cluster

Example command

$ cat devfile.yaml

Example output

[...]
components:
- kubernetes:
    inlined: |
      apiVersion: redis.redis.opstreelabs.in/v1beta1
      kind: Redis
      metadata:
        name: my-redis-service
      spec:
        kubernetesConfig:
          image: quay.io/opstree/redis:v6.2.5
          imagePullPolicy: IfNotPresent
          resources:
            limits:
              cpu: 101m
              memory: 128Mi
            requests:
              cpu: 101m
              memory: 128Mi
          serviceType: ClusterIP
        redisExporter:
          enabled: false
          image: quay.io/opstree/redis-exporter:1.0
        storage:
          volumeClaimTemplate:
            spec:
              accessModes:
              - ReadWriteOnce
              resources:
                requests:
                  storage: 1Gi
  name: my-redis-service
[...]

3.5.8.1.2. Configuring the service
Copiar enlace

Without specific customization, the service will be created with a default configuration. You can use either command-line arguments or a file to specify your own configuration.

3.5.8.1.2.1. Using command-line arguments
Copiar enlace

Use the

--parameters

(or

-p

) flag to specify your own configuration.

The following example configures the Redis service with three parameters:

$ odo service create redis-operator.v0.8.0/Redis my-redis-service \
    -p kubernetesConfig.image=quay.io/opstree/redis:v6.2.5 \
    -p kubernetesConfig.serviceType=ClusterIP \
    -p redisExporter.image=quay.io/opstree/redis-exporter:1.0
Successfully added service to the configuration; do 'odo push' to create service on the cluster

Example command

$ cat kubernetes/odo-service-my-redis-service.yaml

Example output

apiVersion: redis.redis.opstreelabs.in/v1beta1
kind: Redis
metadata:
  name: my-redis-service
spec:
  kubernetesConfig:
    image: quay.io/opstree/redis:v6.2.5
    serviceType: ClusterIP
  redisExporter:
    image: quay.io/opstree/redis-exporter:1.0

You can obtain the possible parameters for a specific service using the

odo catalog describe service

command.

3.5.8.1.2.2. Using a file
Copiar enlace

Use a YAML manifest to configure your own specification. In the following example, the Redis service is configured with three parameters.

Create a manifest:

$ cat > my-redis.yaml <<EOF
apiVersion: redis.redis.opstreelabs.in/v1beta1
kind: Redis
metadata:
  name: my-redis-service
spec:
  kubernetesConfig:
    image: quay.io/opstree/redis:v6.2.5
    serviceType: ClusterIP
  redisExporter:
    image: quay.io/opstree/redis-exporter:1.0
EOF

Create the service from the manifest:

$ odo service create --from-file my-redis.yaml
Successfully added service to the configuration; do 'odo push' to create service on the cluster

3.5.8.2. Deleting a service
Copiar enlace

To delete a service, run the command:

$ odo service delete

Example output

$ odo service list
NAME                       MANAGED BY ODO     STATE               AGE
Redis/my-redis-service     Yes (api)          Deleted locally     5m39s

$ odo service delete Redis/my-redis-service
? Are you sure you want to delete Redis/my-redis-service Yes
Service "Redis/my-redis-service" has been successfully deleted; do 'odo push' to delete service from the cluster

Use the

--force

(or

-f

) flag to force the deletion of the service without confirmation.

3.5.8.3. Listing services
Copiar enlace

To list the services created for your component, run the command:

$ odo service list

Example output

$ odo service list
NAME                       MANAGED BY ODO     STATE             AGE
Redis/my-redis-service-1   Yes (api)          Not pushed
Redis/my-redis-service-2   Yes (api)          Pushed            52s
Redis/my-redis-service-3   Yes (api)          Deleted locally   1m22s

For each service,

STATE

indicates if the service has been pushed to the cluster using the

odo push

command, or if the service is still running on the cluster but removed from the devfile locally using the

odo service delete

command.

3.5.8.4. Getting information about a service
Copiar enlace

To get details of a service such as its kind, version, name, and list of configured parameters, run the command:

$ odo service describe

Example output

$ odo service describe Redis/my-redis-service
Version: redis.redis.opstreelabs.in/v1beta1
Kind: Redis
Name: my-redis-service
Parameters:
NAME                           VALUE
kubernetesConfig.image         quay.io/opstree/redis:v6.2.5
kubernetesConfig.serviceType   ClusterIP
redisExporter.image            quay.io/opstree/redis-exporter:1.0

3.5.9. odo storage
Copiar enlace

odo

lets users manage storage volumes that are attached to the components. A storage volume can be either an ephemeral volume using an

emptyDir

Kubernetes volume, or a Persistent Volume Claim (PVC). A PVC allows users to claim a persistent volume (such as a GCE PersistentDisk or an iSCSI volume) without understanding the details of the particular cloud environment. The persistent storage volume can be used to persist data across restarts and rebuilds of the component.

3.5.9.1. Adding a storage volume
Copiar enlace

To add a storage volume to the cluster, run the command:

$ odo storage create

Example output:

$ odo storage create store --path /data --size 1Gi
✓  Added storage store to nodejs-project-ufyy

$ odo storage create tempdir --path /tmp --size 2Gi --ephemeral
✓  Added storage tempdir to nodejs-project-ufyy

Please use `odo push` command to make the storage accessible to the component

In the above example, the first storage volume has been mounted to the

/data

path and has a size of

1Gi

, and the second volume has been mounted to

/tmp

and is ephemeral.

3.5.9.2. Listing the storage volumes
Copiar enlace

To check the storage volumes currently used by the component, run the command:

$ odo storage list

Example output:

$ odo storage list
The component 'nodejs-project-ufyy' has the following storage attached:
NAME      SIZE     PATH      STATE
store     1Gi      /data     Not Pushed
tempdir   2Gi      /tmp      Not Pushed

3.5.9.3. Deleting a storage volume
Copiar enlace

To delete a storage volume, run the command:

$ odo storage delete

Example output:

$ odo storage delete store -f
Deleted storage store from nodejs-project-ufyy

Please use `odo push` command to delete the storage from the cluster

In the above example, using the

-f

flag force deletes the storage without asking user permission.

3.5.9.4. Adding storage to specific container
Copiar enlace

If your devfile has multiple containers, you can specify which container you want the storage to attach to, using the

--container

flag in the

odo storage create

command.

The following example is an excerpt from a devfile with multiple containers :

components:
  - name: nodejs1
    container:
      image: registry.access.redhat.com/ubi8/nodejs-12:1-36
      memoryLimit: 1024Mi
      endpoints:
        - name: "3000-tcp"
          targetPort: 3000
      mountSources: true
  - name: nodejs2
    container:
      image: registry.access.redhat.com/ubi8/nodejs-12:1-36
      memoryLimit: 1024Mi

In the example, there are two containers,

nodejs1

and

nodejs2

. To attach storage to the

nodejs2

container, use the following command:

$ odo storage create --container

Example output:

$ odo storage create store --path /data --size 1Gi --container nodejs2
✓  Added storage store to nodejs-testing-xnfg

Please use `odo push` command to make the storage accessible to the component

You can list the storage resources, using the

odo storage list

command:

$ odo storage list

Example output:

The component 'nodejs-testing-xnfg' has the following storage attached:
NAME      SIZE     PATH      CONTAINER     STATE
store     1Gi      /data     nodejs2       Not Pushed

3.5.10. Common flags
Copiar enlace

The following flags are available with most

odo

commands:

Expand

Table 3.1. odo flags
Command	Description
`--context`	Set the context directory where the component is defined.
`--project`	Set the project for the component. Defaults to the project defined in the local configuration. If none is available, then current project on the cluster.
`--app`	Set the application of the component. Defaults to the application defined in the local configuration. If none is available, then app.
`--kubeconfig`	Set the path to the `kubeconfig` value if not using the default configuration.
`--show-log`	Use this flag to see the logs.
`-f` , `--force`	Use this flag to tell the command not to prompt the user for confirmation.
`-v` , `--v`	Set the verbosity level. See Logging in odo for more information.
`-h` , `--help`	Output the help for a command.

Note

Some flags might not be available for some commands. Run the command with the

--help

flag to get a list of all the available flags.

3.5.11. JSON output
Copiar enlace

The

odo

commands that output content generally accept a

-o json

flag to output this content in JSON format, suitable for other programs to parse this output more easily.

The output structure is similar to Kubernetes resources, with the

kind

apiVersion

metadata

spec

, and

status

fields.

List commands return a

List

resource, containing an

items

(or similar) field listing the items of the list, with each item also being similar to Kubernetes resources.

Delete commands return a

Status

resource; see the Status Kubernetes resource.

Other commands return a resource associated with the command, for example,

Application

Storage

URL

, and so on.

The full list of commands currently accepting the

-o json

flag is:

Expand

Commands	Kind (version)	Kind (version) of list items	Complete content?
odo application describe	Application (odo.dev/v1alpha1)	n/a	no
odo application list	List (odo.dev/v1alpha1)	Application (odo.dev/v1alpha1)	?
odo catalog list components	List (odo.dev/v1alpha1)	missing	yes
odo catalog list services	List (odo.dev/v1alpha1)	ClusterServiceVersion (operators.coreos.com/v1alpha1)	?
odo catalog describe component	missing	n/a	yes
odo catalog describe service	CRDDescription (odo.dev/v1alpha1)	n/a	yes
odo component create	Component (odo.dev/v1alpha1)	n/a	yes
odo component describe	Component (odo.dev/v1alpha1)	n/a	yes
odo component list	List (odo.dev/v1alpha1)	Component (odo.dev/v1alpha1)	yes
odo config view	DevfileConfiguration (odo.dev/v1alpha1)	n/a	yes
odo debug info	OdoDebugInfo (odo.dev/v1alpha1)	n/a	yes
odo env view	EnvInfo (odo.dev/v1alpha1)	n/a	yes
odo preference view	PreferenceList (odo.dev/v1alpha1)	n/a	yes
odo project create	Project (odo.dev/v1alpha1)	n/a	yes
odo project delete	Status (v1)	n/a	yes
odo project get	Project (odo.dev/v1alpha1)	n/a	yes
odo project list	List (odo.dev/v1alpha1)	Project (odo.dev/v1alpha1)	yes
odo registry list	List (odo.dev/v1alpha1)	missing	yes
odo service create	Service	n/a	yes
odo service describe	Service	n/a	yes
odo service list	List (odo.dev/v1alpha1)	Service	yes
odo storage create	Storage (odo.dev/v1alpha1)	n/a	yes
odo storage delete	Status (v1)	n/a	yes
odo storage list	List (odo.dev/v1alpha1)	Storage (odo.dev/v1alpha1)	yes
odo url list	List (odo.dev/v1alpha1)	URL (odo.dev/v1alpha1)	yes

Este contenido no está disponible en el idioma seleccionado.

Chapter 3. Developer CLI (odo)

3.1. odo release notesCopiar enlaceEnlace copiado en el portapapeles!

3.1.1. Notable changes and improvements in odo version 2.5.0Copiar enlaceEnlace copiado en el portapapeles!

3.1.2. Bug fixesCopiar enlaceEnlace copiado en el portapapeles!

3.1.3. Getting supportCopiar enlaceEnlace copiado en el portapapeles!

3.2. Understanding odoCopiar enlaceEnlace copiado en el portapapeles!

3.2.1. odo key featuresCopiar enlaceEnlace copiado en el portapapeles!

3.2.2. odo core conceptsCopiar enlaceEnlace copiado en el portapapeles!

3.2.3. Listing components in odoCopiar enlaceEnlace copiado en el portapapeles!

3.2.4. Telemetry in odoCopiar enlaceEnlace copiado en el portapapeles!

3.3. Installing odoCopiar enlaceEnlace copiado en el portapapeles!

3.3.1. Installing odo on LinuxCopiar enlaceEnlace copiado en el portapapeles!

3.3.2. Installing odo on WindowsCopiar enlaceEnlace copiado en el portapapeles!

3.3.3. Installing odo on macOSCopiar enlaceEnlace copiado en el portapapeles!

3.3.4. Installing odo on VS CodeCopiar enlaceEnlace copiado en el portapapeles!

3.3.5. Installing odo on Red Hat Enterprise Linux (RHEL) using an RPMCopiar enlaceEnlace copiado en el portapapeles!

3.4. Configuring the odo CLICopiar enlaceEnlace copiado en el portapapeles!

3.4.1. Viewing the current configurationCopiar enlaceEnlace copiado en el portapapeles!

3.4.2. Setting a valueCopiar enlaceEnlace copiado en el portapapeles!

3.4.3. Unsetting a valueCopiar enlaceEnlace copiado en el portapapeles!

3.4.4. Preference key tableCopiar enlaceEnlace copiado en el portapapeles!

3.4.5. Ignoring files or patternsCopiar enlaceEnlace copiado en el portapapeles!

3.5. odo CLI referenceCopiar enlaceEnlace copiado en el portapapeles!

3.5.1. odo build-imagesCopiar enlaceEnlace copiado en el portapapeles!

3.5.2. odo catalogCopiar enlaceEnlace copiado en el portapapeles!

3.5.2.1. ComponentsCopiar enlaceEnlace copiado en el portapapeles!

3.5.2.1.1. Listing componentsCopiar enlaceEnlace copiado en el portapapeles!

3.5.2.1.2. Getting information about a componentCopiar enlaceEnlace copiado en el portapapeles!

3.5.2.2. ServicesCopiar enlaceEnlace copiado en el portapapeles!

3.5.2.2.1. Listing servicesCopiar enlaceEnlace copiado en el portapapeles!

3.5.2.2.2. Searching servicesCopiar enlaceEnlace copiado en el portapapeles!

3.5.2.2.3. Getting information about a serviceCopiar enlaceEnlace copiado en el portapapeles!

3.5.3. odo createCopiar enlaceEnlace copiado en el portapapeles!

3.5.3.1. Creating a componentCopiar enlaceEnlace copiado en el portapapeles!

3.5.3.2. Starter projectsCopiar enlaceEnlace copiado en el portapapeles!

3.5.3.3. Using an existing devfileCopiar enlaceEnlace copiado en el portapapeles!

3.5.3.4. Interactive creationCopiar enlaceEnlace copiado en el portapapeles!

3.5.4. odo deleteCopiar enlaceEnlace copiado en el portapapeles!

3.5.4.1. Deleting a componentCopiar enlaceEnlace copiado en el portapapeles!

3.5.4.2. Undeploying devfile Kubernetes componentsCopiar enlaceEnlace copiado en el portapapeles!

3.5.4.3. Delete allCopiar enlaceEnlace copiado en el portapapeles!

3.5.4.4. Available flagsCopiar enlaceEnlace copiado en el portapapeles!

3.5.5. odo deployCopiar enlaceEnlace copiado en el portapapeles!

3.5.6. odo linkCopiar enlaceEnlace copiado en el portapapeles!

3.5.6.1. Various linking optionsCopiar enlaceEnlace copiado en el portapapeles!

3.5.6.1.1. Default behaviorCopiar enlaceEnlace copiado en el portapapeles!

3.5.6.1.2. The --inlined flagCopiar enlaceEnlace copiado en el portapapeles!

3.5.6.1.3. The --map flagCopiar enlaceEnlace copiado en el portapapeles!

3.5.6.1.4. The --bind-as-files flagCopiar enlaceEnlace copiado en el portapapeles!

3.5.6.2. ExamplesCopiar enlaceEnlace copiado en el portapapeles!

3.5.6.2.1. Default odo linkCopiar enlaceEnlace copiado en el portapapeles!

3.5.6.2.2. Using odo link with the --inlined flagCopiar enlaceEnlace copiado en el portapapeles!

3.5.6.2.3. Custom bindingsCopiar enlaceEnlace copiado en el portapapeles!

3.5.6.2.3.1. To inline or not?Copiar enlaceEnlace copiado en el portapapeles!

3.5.6.3. Binding as filesCopiar enlaceEnlace copiado en el portapapeles!

3.5.6.4. --bind-as-files examplesCopiar enlaceEnlace copiado en el portapapeles!

3.5.6.4.1. Using the default odo linkCopiar enlaceEnlace copiado en el portapapeles!

3.5.6.4.2. Using --inlinedCopiar enlaceEnlace copiado en el portapapeles!

3.5.6.4.3. Custom bindingsCopiar enlaceEnlace copiado en el portapapeles!

3.5.7. odo registryCopiar enlaceEnlace copiado en el portapapeles!

3.5.7.1. Listing the registriesCopiar enlaceEnlace copiado en el portapapeles!

3.5.7.2. Adding a registryCopiar enlaceEnlace copiado en el portapapeles!

3.5.7.3. Deleting a registryCopiar enlaceEnlace copiado en el portapapeles!

3.5.7.4. Updating a registryCopiar enlaceEnlace copiado en el portapapeles!

3.5.8. odo serviceCopiar enlaceEnlace copiado en el portapapeles!

3.5.8.1. Creating a new serviceCopiar enlaceEnlace copiado en el portapapeles!

3.5.8.1.1. Inlining the manifestCopiar enlaceEnlace copiado en el portapapeles!

3.5.8.1.2. Configuring the serviceCopiar enlaceEnlace copiado en el portapapeles!

3.5.8.1.2.1. Using command-line argumentsCopiar enlaceEnlace copiado en el portapapeles!

3.5.8.1.2.2. Using a fileCopiar enlaceEnlace copiado en el portapapeles!

3.5.8.2. Deleting a serviceCopiar enlaceEnlace copiado en el portapapeles!

3.5.8.3. Listing servicesCopiar enlaceEnlace copiado en el portapapeles!

3.5.8.4. Getting information about a serviceCopiar enlaceEnlace copiado en el portapapeles!

3.5.9. odo storageCopiar enlaceEnlace copiado en el portapapeles!

3.5.9.1. Adding a storage volumeCopiar enlaceEnlace copiado en el portapapeles!

3.5.9.2. Listing the storage volumesCopiar enlaceEnlace copiado en el portapapeles!

3.5.9.3. Deleting a storage volumeCopiar enlaceEnlace copiado en el portapapeles!

3.5.9.4. Adding storage to specific containerCopiar enlaceEnlace copiado en el portapapeles!

3.5.10. Common flagsCopiar enlaceEnlace copiado en el portapapeles!

3.1. odo release notes
Copiar enlace

3.1.1. Notable changes and improvements in odo version 2.5.0
Copiar enlace

3.1.2. Bug fixes
Copiar enlace

3.1.3. Getting support
Copiar enlace

3.2. Understanding odo
Copiar enlace

3.2.1. odo key features
Copiar enlace

3.2.2. odo core concepts
Copiar enlace

3.2.3. Listing components in odo
Copiar enlace

3.2.4. Telemetry in odo
Copiar enlace

3.3. Installing odo
Copiar enlace

3.3.1. Installing odo on Linux
Copiar enlace

3.3.2. Installing odo on Windows
Copiar enlace

3.3.3. Installing odo on macOS
Copiar enlace

3.3.4. Installing odo on VS Code
Copiar enlace

3.3.5. Installing odo on Red Hat Enterprise Linux (RHEL) using an RPM
Copiar enlace

3.4. Configuring the odo CLI
Copiar enlace

3.4.1. Viewing the current configuration
Copiar enlace

3.4.2. Setting a value
Copiar enlace

3.4.3. Unsetting a value
Copiar enlace

3.4.4. Preference key table
Copiar enlace

3.4.5. Ignoring files or patterns
Copiar enlace

3.5. odo CLI reference
Copiar enlace

3.5.1. odo build-images
Copiar enlace

3.5.2. odo catalog
Copiar enlace

3.5.2.1. Components
Copiar enlace

3.5.2.1.1. Listing components
Copiar enlace

3.5.2.1.2. Getting information about a component
Copiar enlace

3.5.2.2. Services
Copiar enlace

3.5.2.2.1. Listing services
Copiar enlace

3.5.2.2.2. Searching services
Copiar enlace

3.5.2.2.3. Getting information about a service
Copiar enlace

3.5.3. odo create
Copiar enlace

3.5.3.1. Creating a component
Copiar enlace

3.5.3.2. Starter projects
Copiar enlace

3.5.3.3. Using an existing devfile
Copiar enlace

3.5.3.4. Interactive creation
Copiar enlace

3.5.4. odo delete
Copiar enlace

3.5.4.1. Deleting a component
Copiar enlace

3.5.4.2. Undeploying devfile Kubernetes components
Copiar enlace

3.5.4.3. Delete all
Copiar enlace

3.5.4.4. Available flags
Copiar enlace

3.5.5. odo deploy
Copiar enlace

3.5.6. odo link
Copiar enlace

3.5.6.1. Various linking options
Copiar enlace

3.5.6.1.1. Default behavior
Copiar enlace

3.5.6.1.2. The --inlined flag
Copiar enlace

3.5.6.1.3. The --map flag
Copiar enlace

3.5.6.1.4. The --bind-as-files flag
Copiar enlace

3.5.6.2. Examples
Copiar enlace

3.5.6.2.1. Default odo link
Copiar enlace

3.5.6.2.2. Using odo link with the --inlined flag
Copiar enlace

3.5.6.2.3. Custom bindings
Copiar enlace

3.5.6.2.3.1. To inline or not?
Copiar enlace

3.5.6.3. Binding as files
Copiar enlace

3.5.6.4. --bind-as-files examples
Copiar enlace

3.5.6.4.1. Using the default odo link
Copiar enlace

3.5.6.4.2. Using --inlined
Copiar enlace

3.5.6.4.3. Custom bindings
Copiar enlace

3.5.7. odo registry
Copiar enlace

3.5.7.1. Listing the registries
Copiar enlace

3.5.7.2. Adding a registry
Copiar enlace

3.5.7.3. Deleting a registry
Copiar enlace

3.5.7.4. Updating a registry
Copiar enlace

3.5.8. odo service
Copiar enlace

3.5.8.1. Creating a new service
Copiar enlace

3.5.8.1.1. Inlining the manifest
Copiar enlace

3.5.8.1.2. Configuring the service
Copiar enlace

3.5.8.1.2.1. Using command-line arguments
Copiar enlace

3.5.8.1.2.2. Using a file
Copiar enlace

3.5.8.2. Deleting a service
Copiar enlace

3.5.8.3. Listing services
Copiar enlace

3.5.8.4. Getting information about a service
Copiar enlace

3.5.9. odo storage
Copiar enlace

3.5.9.1. Adding a storage volume
Copiar enlace

3.5.9.2. Listing the storage volumes
Copiar enlace

3.5.9.3. Deleting a storage volume
Copiar enlace

3.5.9.4. Adding storage to specific container
Copiar enlace

3.5.10. Common flags
Copiar enlace

3.5.11. JSON output
Copiar enlace