DEV Community

Philippe MARTIN
Philippe MARTIN

Posted on

Binding a service to a micro-service using odo

#kubernetes #development #odo #binding

In this article, we will see how to bind a service to a micro-service, using the odo development tool.

We will first see how the Service Binding Operator can be used to bind to a PostgreSQL instance started from a standalone Deployment, then to a PostgreSQL instance started from an Operator.

Next, we will see how to start the Operator backed PostgreSQL service from odo, and how to bind our micro-service to this PostgreSQL service using odo.

The Service Binding Operator

The Service Binding Operator is an operator that helps the developer get the values of the different parameters exposed by a service.

For example, when you have a PostgreSQL service deployed, you need to know its host, database name, user and password to work with the service. If the service provides which information are to be exposed, the Service Binding Operator is able to get the exposed values and provide them to your micro-service.

Installing the Service Binding Operator

You can install this operator with the help of the Operator Lifecycle Manager. For this, first install, if necessary, this manager with the command:

$ curl -sL https://github.com/operator-framework/operator-lifecycle-manager/releases/download/v0.18.3/install.sh | bash -s v0.18.3
Enter fullscreen mode Exit fullscreen mode

Then, install the Service Binding Operator with the command:

$ kubectl create -f https://operatorhub.io/install/service-binding-operator.yaml
Enter fullscreen mode Exit fullscreen mode

Deploying a standalone PostgreSQL instance

Let's deploy a single PostgreSQL instance using the official postgres image, available at https://hub.docker.com/_/postgres.

We can deploy an instance by defining our own database name, user and password with the following manifest:

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: postgres
  name: postgres
spec:
  replicas: 1
  selector:
    matchLabels:
      app: postgres
  template:
    metadata:
      labels:
        app: postgres
    spec:
      containers:
      - image: postgres
        name: postgres
        env:
        - name: POSTGRES_PASSWORD
          value: a-super-secret
        - name: POSTGRES_USER
          value: user1
        - name: POSTGRES_DB
          value: db1
        volumeMounts:
        - mountPath: /var/lib/postgresql/data
          name: pgdata
      volumes:
      - name: pgdata
        emptyDir: {}

---

apiVersion: v1
kind: Service
metadata:
  name: postgres-svc
spec:
  selector:
    app: postgres
  ports:
  - port: 5432
    targetPort: 5432
Enter fullscreen mode Exit fullscreen mode

When the service is running, you can run another container that will be ready to connect to it using psql, with the manifest:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: client
spec:
  selector:
    matchLabels:
      app: client
  template:
    metadata:
      labels:
        app: client
    spec:
      containers:
      - name: client
        image: postgres
        command: ["bash", "-c", "sleep $((10**10))"]
        env:
        - name: PGPASSWORD
          value: a-super-secret
        - name: PGHOST
          value: postgres-svc
        - name: PGDATABASE
          value: db1
        - name: PGUSER
          value: user1
Enter fullscreen mode Exit fullscreen mode

Note that we have defined the environment variables supported by psql to define the host, database name, username and password.

You finally can connect to the database with the command:

kubectl exec -it deployment/client psql
Enter fullscreen mode Exit fullscreen mode

The environment variables defined into the manifest for the container will be used by psql to connect to the desired service.

But with this method, the developer needs to know the values for these different parameters, when running the client. Let's see how these variables can be automatically injected into the pod, using the Service Binding Operator.

Annotating the service resource

The first step is to annotate the postgres Deployment, to indicate which parameters should be exposed:

apiVersion: apps/v1
kind: Deployment
metadata:
  annotations:
    service.binding/pguser: path={.spec.template.spec.containers[0].env[?(@.name=="POSTGRES_USER")].value}
    service.binding/pgpassword: path={.spec.template.spec.containers[0].env[?(@.name=="POSTGRES_PASSWORD")].value}
    service.binding/pgdatabase: path={.spec.template.spec.containers[0].env[?(@.name=="POSTGRES_DB")].value}
  labels:
    app: postgres
  name: postgres
spec:
  replicas: 1
  selector:
    matchLabels:
      app: postgres
  template:
    metadata:
      labels:
        app: postgres
    spec:
      containers:
      - image: postgres
        name: postgres
        env:
        - name: POSTGRES_PASSWORD
          value: a-super-secret
        - name: POSTGRES_USER
          value: user1
        - name: POSTGRES_DB
          value: db1
        volumeMounts:
          - mountPath: /var/lib/postgresql/data
            name: pgdata
      volumes:
      - name: pgdata
        emptyDir: {}

---

apiVersion: v1
kind: Service
metadata:
  name: postgres-svc
spec:
  selector:
    app: postgres
  ports:
  - port: 5432
    targetPort: 5432
Enter fullscreen mode Exit fullscreen mode

Linking to the annotated service

Then, you can create a client2 deployment, which does not define the database name, user and password:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: client2
spec:
  selector:
    matchLabels:
      app: client2
  template:
    metadata:
      labels:
        app: client2
    spec:
      containers:
      - name: client2
        image: postgres
        command: ["bash", "-c", "sleep $((10**10))"]
        env:
        - name: PGHOST
          value: postgres-svc
Enter fullscreen mode Exit fullscreen mode

Finally, you can create a servicebinding resource, to define a link between the Postgres service and the client2 deployment:

apiVersion: binding.operators.coreos.com/v1alpha1
kind: ServiceBinding
metadata:
  name: binding-request
spec:
  bindAsFiles: false
  namingStrategy: '{{ .name | upper }}'
  application:
    name: client2
    group: apps
    version: v1
    resource: deployments
  services:
  - group: apps
    version: v1
    kind: Deployment
    name: postgres
Enter fullscreen mode Exit fullscreen mode

By applying this manifest, the client2 pod will be restarted, and environment variables will be injected through a secretRef, by the Service Binding Operator:

$ kubectl get deployment client2 -o yaml
[...]
spec:
  containers:
  - command:
    - bash
    - -c
    - sleep $((10**10))
    env:
    - name: PGHOST
      value: postgres-svc
    envFrom:
    - secretRef:
        name: binding-request-703eda68

$ kubectl get secret binding-request-703eda68 -o yaml
apiVersion: v1
kind: Secret
metadata:
  name: binding-request-703eda68
data:
  PGDATABASE: ZGIx
  PGPASSWORD: YS1zdXBlci1zZWNyZXQ=
  PGUSER: dXNlcjE=
type: Opaque
Enter fullscreen mode Exit fullscreen mode

Now, you can connect to the service from the client2 deployment, without the need to know the credentials.

Deploying an Operator backed PostgreSQL service

Operator backed services are services managed by a Kubernetes operator.

You can find such Operator backed services on https://operatorhub.io/. For this example, we won't use operatorhub, but deploy manually the operator found at https://github.com/operator-backing-service-samples/postgresql-operator.

To deploy the PostgreSQL operator using the OLM framework, we first need to declare the catalog containing the Operator, then subscribe to this specific Operator:

kubectl apply -f - << EOD
--------
apiVersion: operators.coreos.com/v1alpha1
kind: CatalogSource
metadata:
    name: sample-db-operators
    namespace: olm
spec:
    sourceType: grpc
    image: quay.io/redhat-developer/sample-db-operators-olm:v1
    displayName: Sample DB Operators

--------

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: pg
  namespace: operators
spec:
  channel: stable
  name: db-operators
  source: sample-db-operators
  sourceNamespace: olm
  installPlanApproval: Automatic
EOD
Enter fullscreen mode Exit fullscreen mode

Examining the annotations on the Database custom resource

The PostgreSQL operator comes with a custom resource definition (CRD): Database. Let's examine the definition of this resource with the command:

$ kubectl get crd databases.postgresql.baiju.dev -o yaml
apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: databases.postgresql.baiju.dev
  annotations:
    service.binding/db.host: path={.status.dbConfigMap},objectType=ConfigMap
    service.binding/db.name: path={.status.dbConfigMap},objectType=ConfigMap
    service.binding/db.password: path={.status.dbConfigMap},objectType=ConfigMap
    service.binding/db.port: path={.status.dbConfigMap},objectType=ConfigMap
    service.binding/db.user: path={.status.dbConfigMap},objectType=ConfigMap
    service.binding/dbConnectionIP: path={.status.dbConnectionIP}
    service.binding/dbConnectionPort: path={.status.dbConnectionPort}
    service.binding/dbName: path={.spec.dbName}
    service.binding/password: path={.status.dbCredentials},objectType=Secret
    service.binding/user: path={.status.dbCredentials},objectType=Secret
[...]
Enter fullscreen mode Exit fullscreen mode

We can find that the CRD get a list of service.binding annotations, that will be used by the Service Binding Operator to bind instances of this resource to micro-services.

Note that, earlier in this article, annotations were placed in the Deployment instance itself; annotations are now placed in the definition of the Database resource (if you are an object-oriented developer, think about Classes and Instances in place of Definition and Instance).

Creating a Database instance with odo

The odo tool can create instances of Operator backend services.

You can get the list of available Operators on your cluster with the command:

$ odo catalog list services
Services available through Operators
NAME                                CRDs
postgresql-operator.v0.0.9          Database
service-binding-operator.v0.9.1     ServiceBinding, ServiceBinding
Enter fullscreen mode Exit fullscreen mode

Note that this command displays the list of ClusterServiceVersions resources contained in the current namespace in the Succeeded phase. The Succeeded phase can take a few minutes to appear, please be patient; you can check with the command:

$ kubectl get csv 
NAME                              DISPLAY                    VERSION   REPLACES                          PHASE
postgresql-operator.v0.0.9        PostgreSQL Database        0.0.9                                       Succeeded
service-binding-operator.v0.9.1   Service Binding Operator   0.9.1     service-binding-operator.v0.9.0   Succeeded
Enter fullscreen mode Exit fullscreen mode

With odo, services are attached to components; before to deploy a service, you need to create a component. You can follow this article to create your component, and get an example of sources in the repository https://github.com/feloy/nest-odo-example.

Now, you can create an instance of a PostgreSQL database with:

$ odo service create postgresql-operator.v0.0.9/Database db1
Successfully added service to the configuration; do 'odo push' to create service on the cluster
Enter fullscreen mode Exit fullscreen mode

This will create an instance with the default parameters. If you want to use a specific configuration, you can get the possible parameters with the command:

$ odo catalog describe service postgresql-operator.v0.0.9/Database
Kind: Database
Version: v1alpha1
Description: Describes how an application component is built and deployed.
Parameters:

 PATH       DISPLAYNAME                     DESCRIPTION                    

 image      PostgreSQL database image       PostgreSQL database image      
 imageName  PostgreSQL database image name  PostgreSQL database image name 
 dbName     DB name                         Desired database name. If      
                                            not provided, default value    
                                            'postgres' will be used.
Enter fullscreen mode Exit fullscreen mode

You can now create an instance with a specific database name with the command:

$ odo service create postgresql-operator.v0.0.9/Database db1 -p dbName=mydb -p imageName=postgresql -p image=postgres
Enter fullscreen mode Exit fullscreen mode

Finally, you can deploy the service into the Kubernetes cluster:

odo push
Enter fullscreen mode Exit fullscreen mode

Binding the service with odo

This odo command will create the Service Binding resource necessary to bind the PostgreSQL service to your micro-service:

$ odo link Database/db1 --name dblink
 ✓  Successfully created link between component "nodejs-prj1-api-hjtd" and service "Database/db1"

$ odo push

$ kubectl get sbr dblink -o yaml 
kind: ServiceBinding
metadata:
  name: dblink
  [...]
spec:
  application:
    group: apps
    name: nodejs-prj1-api-hjtd-app
    resource: deployments
    version: v1
  bindAsFiles: false
  detectBindingResources: true
  services:
  - group: postgresql.baiju.dev
    kind: Database
    name: db1
    version: v1alpha1
[...]
Enter fullscreen mode Exit fullscreen mode

You can examine that the environment variables have been defined into your micro-service:

$ odo exec -- bash -c export | grep DATABASE_
declare -x DATABASE_CLUSTERIP="10.107.65.179"
declare -x DATABASE_DBCONNECTIONIP="10.107.65.179"
declare -x DATABASE_DBCONNECTIONPORT="5432"
declare -x DATABASE_DBNAME="mydb"
declare -x DATABASE_PASSWORD="password"
declare -x DATABASE_USER="postgres"
Enter fullscreen mode Exit fullscreen mode

The developer can now use these variables into the code of the micro-service, and does not need to declare the values for these variables when deploying the micro-service, as the injection of the environment variables will be managed by the Service Binding Operator.

Top comments (0)

Read next

nvahalik profile image

Clarifying "Coding Convention"

Nick Vahalik -

tingwei628 profile image

Deploying Traefik Proxy with Cloudflare Origin CA Certificate on k0s

Tingwei -

rafaeljcamara profile image

Downstream Resiliency: The Timeout, Retry, and Circuit-Breaker Patterns

Rafael Câmara -

mrshimpi17 profile image

Resolving the "Request Entity Too Large" Error in Helm Deployments: Effective Strategies and Solutions

Manohar Shimpi -