If you are interested in similar articles about the differences between OpenShift and vanilla Kubernetes you can read my previous post about GitOps and multi-cluster environments. In the current article, we will also discuss the odo tool. If you need more information about it go the following post.

Introduction

Eclipse Che is a Kubernetes-native IDE and developer collaboration platform. OpenShift Dev Spaces is built on top of Eclipse Che and allows you to run it easily on OpenShift. We can install Dev Spaces using an operator. After that, you will get a ready platform that automatically integrates with the OpenShift authorization mechanism.

In this article, I’ll show you step-by-step how to install Dev Spaces on the OpenShift platform. However, you can as well try a hosted option. By default, OpenShift Dev Spaces runs as part of the Developer Sandbox. Developer Sandbox gives you immediate access to the cloud-managed OpenShift cluster for 30 days. You don’t have to install and configure anything there. Since everything is ready for use, you will just access your Dev Spaces dashboard to start development in one of the available IDEs including Theia, IntelliJ, and Visual Studio.

The picture visible below shows the architecture of our solution. Let’s imagine there are many developers working with our instance of OpenShift. Firstly, they need to login into the OpenShift cluster. Once they do it they can access a dashboard of Dev Spaces. Dev Spaces automatically creates a namespace for a developer based on username. It also automatically starts a pod containing our IDE after we choose a git repository with the app source code. Then we can use OpenShift developer tools to easily build the app from the source code and deploy it in the current namespace.

Prerequisites

In order to do the whole exercise with me, you need to have a running instance of OpenShift. Of course, you can use a developer sandbox, but you may have only a single user there. There are various methods of running OpenShift instance including a local instance or cloud-managed instances on AWS or Azure. You can find a detailed information about all available installation methods here. For running on the local computer use OpenShift Local.

Install and Configure Dev Spaces on OpenShift

Once we have a running instance of OpenShift, we may proceed to the Dev Spaces installation. You need to go the “Operator Hub” in OpenShift Console and choose the Red Hat OpenShift Dev Spaces operator. You can install it using default settings. That operator will also automatically install another operator – DevWorkspace. After you install Dev Spaces you would have to create an instance of CheCluster. You can find a link in the “Provided APIs” section.

Then, you need to click the “Create CheCluster” button. You will be redirected into the creation form. You can also leave defaults there. I create my instance of CheCluster in the spaces namespace.

After creating CheCluster we will switch to the spaces namespace for a moment just to verify if everything works fine.

$ oc project spaces

You should have a similar list of pods as me:

$ oc get pod
NAME                                   READY   STATUS    RESTARTS   AGE
che-gateway-548fdd95b5-zhczp           4/4     Running   0          1m
devfile-registry-6cbbc6c87b-hzdcb      1/1     Running   0          1m
devspaces-86cfb5b664-bqs7l             1/1     Running   0          1m
devspaces-dashboard-56b68b4649-xlrgc   1/1     Running   0          1m
plugin-registry-89f7d7684-pw9wg        1/1     Running   0          1m
postgres-6cb6cb646f-6dvbq              1/1     Running   0          1m

You can easily access Dev Spaces dashboard through the DNS address using the OpenShift Route object.

Use Dev Spaces on OpenShift

I have already created three users on OpenShift: user1, user2 and user3. We can use a simple htpasswd authentication for that. At the beginning those users do not have access to any project (or namespace) on OpenShift. I also have the admin user for managing installation and viewing the status across all the namespaces.

Now, we will access Dev Spaces dashboard using each user one by one. Let’s see how it looks for the first user – user1. You can just put an address of the Git repository with the app source code and create a workspace. There are also some example repositories available, but you can use my repository containing some simple Quarkus apps.

By default, OpenShift Dev Spaces runs Theia as developer IDE. Since we would like to use IntelliJ, we need to customize a worspace creation command. We could pass the name of our IDE using the devfile.yaml file in the root directory of our repository. But we can as well pass it in the URL. The picture visible below illustrates the algorithm used for customizing workspace creation using URL. We just need to pass the repository URL and set the che-editor parameter with the che-incubator/che-idea/latest value.

Finally, we will start our new workspace. We need to wait a moment until the pod with our IDE starts.

Once it is ready for use, you will be redirected into the URL with your IDE. Now, you can start development

If you back for a moment to the Dev Spaces dashboard you will see the new workspace on the list of available workspaces for user1. You can do some actions on workspaces like restart or deletion.

Now, we will repeat exactly the same steps for user2 and user3. All these users will have their own instances of Dev Spaces in the separated namespaces <username>-devspaces. Let’s display a list of the DevWorkspaces objects across all the namespaces. They represent all the existing workspaces inside the whole OpenShift clusters. We can verify a status of the workspace (Running, Starting, Stopped) and URL.

$ oc get devworkspaces -A
NAMESPACE            NAME                          DEVWORKSPACE ID             PHASE      INFO
user1-devspaces      sample-quarkus-applications   workspace4b02dc6434b54a0e   Running    https://devspaces.apps.cluster-rh520e.gcp.redhatworkshops.io/workspace4b02dc6434b54a0e/idea-rhel8/8887/?backgroundColor=434343&wss
user2-devspaces      sample-quarkus-applications   workspaceadfbc8426d774988   Running    https://devspaces.apps.cluster-rh520e.gcp.redhatworkshops.io/workspaceadfbc8426d774988/idea-rhel8/8887/?backgroundColor=434343&wss
user3-devspaces      sample-quarkus-applications   workspace810c8d6cdb1a4c7d   Starting   Waiting for workspace deployment

Use IntelliJ on OpenShift

After running IntelliJ instance on OpenShift we can verify some settings. Of course, you can do everything the same as in standard IntelliJ on your computer. But what is important here, our development environment is preconfigured and ready for work. There are OpenJDK, Maven and oc client installed and configured. Moreover, there is also odo client, which is used to build and deploy the directly from local version of source code. The user is currently logged in into the OpenShift cluster. Since we are inside the cluster, we can act with it using internal networking. If we still need to install some additional components, we can prepare our own version of the devfile.yaml and put it e.g. in the Git repository root directory.

One of the most important thing here is that you are interacting with OpenShift cluster internally. That has a huge impact on deployment time when using inner-development loop tools like odo. That’s because you don’t have to upload the source code over the network. Let’s just try it. As I mentioned before odo is by default installed in your workspace. So now, the only thing you need to do is to choose one app from our sample Quarkus Git repository. For me, it is person-service.

$ cd person-service

In the first step, we need to create an app with odo. There are several components available depending on the language or even framework. You can list all of them by running the following command: odo catalog list components. Since our code is written in Quarkus we will choose the java-quarkus component.

$ odo create java-quarkus person

In order to build and deploy app on OpenShift just run the following command.

$ odo push

Let’s analyze what happened. Here is the output from the odo push command. It automatically creates a Route to expose app outside the cluster. After performing the Maven build it finally pushes the app with the name person to OpenShift.

To view the status of the cluster we can install the OpenShift Toolkit plugin in IntelliJ.

Let’s display a list of deployments in the user1-devspaces namespace. As you see our Quarkus app is deployed under the person-app name. I also had to deploy Postgresql (person-db) on OpenShift since the our apps connects to the database.

Finally, if you want want do have an inner-development loop with odo and Dev Spaces just run the command odo watch in the IntelliJ terminal.

Customize OpenShift Dev Spaces

We can customize the behaviour of Dev Spaces by modifying the CheCluster object. Here are the default settings. We can override e.g. :

• The namespace name template (1)
• The duration after which a workspace will be idled if there is no activity (2).
• The maximum duration a workspace runs (3).
• Storage option from per user into the mode where each workspace has its own individual PVC (4).

apiVersion: org.eclipse.che/v2
kind: CheCluster
metadata:
  name: devspaces
  namespace: spaces
spec:
  components:
    cheServer:
      debug: false
      logLevel: INFO
    database:
      credentialsSecretName: postgres-credentials
      externalDb: false
      postgresDb: dbche
      postgresHostName: postgres
      postgresPort: '5432'
      pvc:
        claimSize: 1Gi
    imagePuller:
      enable: false
    metrics:
      enable: true
  devEnvironments:
    defaultNamespace:
      template: <username>-devspaces # (1)
    secondsOfInactivityBeforeIdling: 1800 # (2)
    secondsOfRunBeforeIdling: -1 # (3)
    storage:
      pvcStrategy: per-user # (4)
  networking:
    auth:
      gateway:
        configLabels:
          app: che
          component: che-gateway-config

So, if there is no activity Dev Spaces should automatically destroy the pod with your IDE after 30 minutes. Of course, you can change the value of that timeout. However, you can modify the YAML of each DevWorkspace object to shut it down manually. You just need to set the spec.started parameter value to false.

Let’s verify the status of DevWorkspace objects after disabling all of them manually.

$ oc get devworkspace -A
NAMESPACE            NAME                          DEVWORKSPACE ID             PHASE     INFO
user1-devspaces      sample-quarkus-applications   workspace4b02dc6434b54a0e   Stopped   Stopped
user2-devspaces      sample-quarkus-applications   workspaceadfbc8426d774988   Stopped   Stopped
user3-devspaces      sample-quarkus-applications   workspace810c8d6cdb1a4c7d   Stopped   Stopped

Final Thoughts

OpenShift Dev Spaces helps you to standardize development process across the whole organization on OpenShift. Thanks to that tool you can accelerate project and developer onboarding. As a zero-install development environment that runs in your browser, it makes it easy for anyone to join your team and contribute to a project. It may be especially useful for enabling fast inner-development loop with the remote Kubernetes or OpenShift clusters.

The post Development with OpenShift Dev Spaces appeared first on Piotr's TechBlog.

You can find a video version of every part of this tutorial on my YouTube channel. The first part is available here: Microservices on Kubernetes: Part 1 – IDE & Tools

In this section of this guide, I’ll be showing you tools, frameworks, and platforms that speed up the development of JVM microservices on Kubernetes. We are going to implement sample microservices-based architectures using Kotlin and then deploy and run them on different Kubernetes clusters.

Cloud Code IntelliJ Plugin

If you use IntelliJ as a development IDE and you prefer “clicking” over command-line tools, Cloud Code is something for you. There is also the Cloud Code plugin for Microsoft Visual Studio Code. Cloud Code comes with a set of tools to help you write, run, and debug cloud-native applications quickly and easily. It can be integrated with popular tools like Skaffold, Jib, kubectl, or kustomize.

With Google’s Cloud Code you can run and debug your application on Kubernetes the same as you would do it during local development without any third-party platform. You need to click Run or Debug button on the configuration built using template Cloud Code: Kubernetes as shown below.

With Cloud Code, you can easily explore all your Kubernetes clusters that are configured inside the local Kubernetes context. You can verify a list of workloads, services, ingresses, config maps, secrets, and others. You can easily stream logs, view detailed descriptions, and open terminal for selected pods. All information is exposed as a drop-down list box in the tree structure as you see in the picture below.

Finally, you can take advantage of editing support for Kubernetes manifests. You can use predefined templates for creating the most popular Kubernetes and Anthos manifests. You can use content assist for those manifests.

If you use IntelliJ Ultimate it is worth taking a look at JetBrains Kubernetes Plugin.

K9S

K9s is a mid-way solution between the GUI and the command-line tool. It is a terminal-based UI to interact with your Kubernetes clusters. This project aims to make it easier to navigate, observe, and manage your deployed applications. K9s continually watches Kubernetes for changes and offers subsequent commands to interact with your observed resources.
Here’s the default screen from K9s after startup. It prints the list of available pods. You can easily print the logs of the pod, delete it, edit its YAML manifest, and much else.

You can also easily switch between different resources just by typing “:”, and then provide the name of the required Kubernetes object. Let’s say you would like to see the list of Kubernetes Services — you just need to type :svc. We can also easily switch to all namespaces view just by typing “0”.

CLI

Of course, you can still use just a simple kubectl command to manage your cluster. A knowledge about kubectl commands is a useful skill. When using this simple CLI, you may still install some useful command-line plugins. One of them is kubectx. It allows you to easily switch between different kube contexts. To view a list of configured contexts you just need to execute command kubectx ls.

Octant

The last tool discussed in this article is Octant. Octant is a typical web-based UI tool. It runs locally on your machine and connects with the currently set Kubernetes context. After installation, you can run it just by using command octant. If you would like to select context on startup, just set parameter –context.

Octant provides many more features than a standard Kubernetes Dashboard, which is deployed directly on your cluster. By default, it is available on http://localhost:7777. You can easily view all the most important Kubernetes components, filter them by labels, or switch between namespaces.

You can also go to the details of the selected object like pod or deployment. Then you may for example stream the logs, edit YAML, open terminal, or just delete the current object.

You may also display additional resources like Istio components using Custom Resources view.

Conclusion

Before starting development it is worth spending some time discovering useful tools for managing the Kubernetes cluster. As you see there is a wide selection of such Kubernetes development tools, starting from simple command-line solutions to more advanced GUI or web-based interfaces. Once we have selected such tools we may proceed to the second phase – a setup of local or remote Kubernetes cluster for development.

The post Development on Kubernetes: IDE & Tools appeared first on Piotr's TechBlog.

I have already described another useful tool for deploying applications on Kubernetes – Skaffold. If you are interested in more details you may refer to the following article Local Java Development on Kubernetes.

Example

The source code of the sample Spring Boot application that connects to MongoDB is as usual available in my GitHub repository: https://github.com/piomin/sample-spring-boot-on-kubernetes.git.

Getting started with Okteto

You should start from downloading Okteto CLI. The same as other similar solutions it is available as a single executable file that needs to be placed in your PATH. After that you should execute command okteto login that downloads and adds your Okteto’s account credentials to kubeconfig file, and sets it as a current context. Now you can use kubectl to interact with your new remote Kubernetes cluster.

Okteto configuration

In fact, to start development with Okteto you just need to add file okteto.yml with required configuration to the root directory of your application. You have pretty configuration options, but you should add the name of your application and an image used for development. What is very important here – it is not the Docker image just with your application. When Okteto development mode is initialized for your application, it replaces your application container with a development container that contains development tools (e.g. maven and jdk, or npm, python, go compiler, debuggers, etc). In that case we are using a special Docker image dedicated for maven okteto/maven. We are also setting Maven command for starting our Spring Boot application, some environment variables with MongoDB credentials and database name, and port forwarding option.

name: employee-service
image: okteto/maven
command: ["mvn", "spring-boot:run" ]
workdir: /app
environment:
- MONGO_USERNAME=okteto
- MONGO_DATABASE=okteto
- MONGO_PASSWORD=okteto
forward:
- 8080:8080

Now, all you need to do is to execute command okteto up in the root directory of your application. Okteto is able to automatically create Deployment, perform Maven build and deploy your Spring Boot application on a remote Kubernetes cluster.

Spring Boot development

Spring Boot application has been started on Okteto Cloud by executing Maven goal spring-boot:run. Before that it runs the full Maven build. Okteto is listening for changes in the code and synchronizes it to your remote development environment. Of course such change should not trigger Maven build once again – like for example in Skaffold. To enable that feature the only thing we need to do is to add Spring Boot Devtools to the project dependencies.

<dependency>
   <groupId>org.springframework.boot</groupId>
   <artifactId>spring-boot-devtools</artifactId>
</dependency>

Applications that use spring-boot-devtools will automatically restart whenever files on the classpath change. With Okteto the change in the local file system will trigger the restart of the application running on your remote development environment. It is also important to enable the automatic rebuilding of an application on file change in your local development IDE. If you are using IntelliJ IDEA you should enable the option Build project automatically inside Compiler section and also enable some additional registry keys. Here’s the article with a detailed description of all required steps:
https://mkyong.com/spring-boot/intellij-idea-spring-boot-template-reload-is-not-working/.

Implementation of Spring Boot for Okteto

We are building a simple application that uses Mongo as a backend store and exposes REST endpoints outside. Here’s the list of required Maven dependencies.

<dependency>
   <groupId>org.springframework.boot</groupId>
   <artifactId>spring-boot-starter-web</artifactId>
</dependency>
<dependency>
   <groupId>org.springframework.boot</groupId>
   <artifactId>spring-boot-starter-actuator</artifactId>
</dependency>
<dependency>
   <groupId>org.springframework.boot</groupId>
   <artifactId>spring-boot-starter-data-mongodb</artifactId>
</dependency>
<dependency>
   <groupId>org.projectlombok</groupId>
   <artifactId>lombok</artifactId>
</dependency>

We are using Spring Data Repository pattern for integration with Mongo. We are adding some custom find methods to the inherited list of methods defined for CrudRepository in Spring Data Mongo.

public interface PersonRepository extends CrudRepository<Person, String> {

   Set<Person> findByFirstNameAndLastName(String firstName, String lastName);
   Set<Person> findByAge(int age);
   Set<Person> findByAgeGreaterThan(int age);

}

Database connection settings are configured in application.yml. We are using environment variables injected to the container and set in okteto.yml configuration file.

spring:
  application:
    name: sample-spring-boot-on-kubernetes
  data:
    mongodb:
      uri: mongodb://${MONGO_USERNAME}:${MONGO_PASSWORD}@mongodb/${MONGO_DATABASE}
management:
  endpoints:
    web:
      exposure:
        include: "*"
  endpoint:
    health:
      show-details: ALWAYS

We are injecting the repository into the controller and implementing simple CRUD methods exposed as HTTP endpoints.

@RestController
@RequestMapping("/persons")
public class PersonController {

   private PersonRepository repository;

   PersonController(PersonRepository repository) {
      this.repository = repository;
   }

   @PostMapping
   public Person add(@RequestBody Person person) {
      return repository.save(person);
   }

   @PutMapping
   public Person update(@RequestBody Person person) {
      return repository.save(person);
   }

   @DeleteMapping("/{id}")
   public void delete(@PathVariable("id") String id) {
      repository.deleteById(id);
   }

   @GetMapping
   public Iterable<Person> findAll() {
      return repository.findAll();
   }

   @GetMapping("/{id}")
   public Optional<Person> findById(@PathVariable("id") String id) {
      return repository.findById(id);
   }

   @GetMapping("/first-name/{firstName}/last-name/{lastName}")
   public Set<Person> findByFirstNameAndLastName(@PathVariable("firstName") String firstName,
         @PathVariable("lastName") String lastName) {
      return repository.findByFirstNameAndLastName(firstName, lastName);
   }

   @GetMapping("/age-greater-than/{age}")
   public Set<Person> findByAgeGreaterThan(@PathVariable("age") int age) {
      return repository.findByAgeGreaterThan(age);
   }

   @GetMapping("/age/{age}")
   public Set<Person> findByAge(@PathVariable("age") int age) {
      return repository.findByAge(age);
   }

}

Deploy Spring Boot on Okteto

Before deploying our example application on Okteto we will initialize MongoDB there. Okteto provides a web-based management console. Besides managing currently developed applications, we may easily deploy some predefined software, like databases or message brokers. As you may easily run MongoDB in a single click.

Of course, in the background Okteto is creating Deployment and required Secrets.

Now, we can finally initialize our remote development environment on Okteto Cloud. The command code>okteto up is able to create new Deployment if it does not exist. Then it is enabling port forwarding on localhost:8080 and starting Maven build as shown below.

After running command okteto up we have two the Deployment object and two running pods.

We can verify the status of the environment using Okteto Web UI.

Our application is exposing some Actuator and /persons endpoints outside. We can easily access them at the address https://sample-spring-boot-on-kubernetes-piomin.cloud.okteto.net. Since we have already enabled port forwarding, we can also just call it using a localhost address.

Now, we are ready to send some test requests. Let’s add two persons using POST /persons endpoint.

Finally let’s call GET /persons method to verify if two Persons has been succesfully saved in Mongo.

Conclusion

With Okteto you don’t have Docker or Kubernetes installed on your machine. You can focus just on development in your favorite programming IDE, the same as you would do without using any cloud platform. By defining a single Okteto configuration file and then by running a single command using Okteto CLI you are able to prepare your remote development environment. In fact, you don’t have to know much about Kubernetes to start your development with Okteto, but in case you need it you may still take advantage of all Kubernetes features and special resources.

The post Development on Kubernetes with Okteto and Spring Boot appeared first on Piotr's TechBlog.