Remocal

What is Remocal? How can this approach help enhance DX (developer experience)?

What is Remocal?

Remocal is "remote-to-local".

In the transition to microservices, containers, and cloud-native development, the technological landscape evolves, yet the imperative for swift feedback endures. Kubernetes serves as a pivotal tool for deploying and managing applications at scale. Nevertheless, whether in the process of coding or testing applications, the efficiency of completing tasks promptly is paramount. This necessitates a workflow that avoids the cumbersome task of locally provisioning all microservices and it dependencies, thus preventing undue strain on system resources. This new workflow is dubbed "remote-to-local".

If I run, everything Locally?

Quick feedback is ensured when resources are readily available locally. Leveraging automation tools such as Tilt, Skaffold, Draft and DevSpace further enhances this process. However, the capacity to manage resources locally is restricted, as running a limited number of them can quickly overwhelm your Kubernetes instance and strain your laptop.

If I run, everything Remotely?

Deploying infrastructure on the cloud offers streamlined setup processes, albeit at an added expense. This cost may vary depending on the management approach for developer clusters, whether shared or isolated. Furthermore, remote container debugging adds more challenges. Given the remote nature of the cluster, developers must adhere to a comprehensive workflow, encompassing tasks such as container image creation, registry uploads, and cluster deployment, to assess the implications of code modifications, inevitably leading to slower feedback.

What is the solution for this challenge?

There are a few tools available to handle this challenge, such as mirrord, Telepresence and Bridge to Kubernetes using Remocal approach. For further information, please visit the websites of the products.

Enough theory, show me the code?

For this exercise, I am using:

Before moving on to mirrord, ensure that you have successfully deployed your application on Rancher's Kubernetes cluster (Refer. below images for Pods, Ingress details), 'webfrontend' should be accessible via a browser. To access 'webfrontend' through a browser, you need to configure Ingress (traefik ingress comes with Rancher Desktop), which you can do via the Rancher Desktop UI.

Clicking on Target URL e.g., http://demo.localdev.me/, the web app opens as 

# This is for reference only. it is bit verbose as it is downloaded from Rancher Desktop UI.
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  creationTimestamp: "2024-05-27T06:38:34Z"
  generation: 2
  managedFields:
  - apiVersion: networking.k8s.io/v1
    fieldsType: FieldsV1
    fieldsV1:
      f:status:
        f:loadBalancer:
          f:ingress: {}
    manager: traefik
    operation: Update
    subresource: status
    time: "2024-05-27T06:38:34Z"
  - apiVersion: networking.k8s.io/v1
    fieldsType: FieldsV1
    fieldsV1:
      f:spec:
        f:defaultBackend:
          .: {}
          f:service:
            .: {}
            f:name: {}
            f:port:
              .: {}
              f:number: {}
        f:rules: {}
    manager: steve
    operation: Update
    time: "2024-05-27T06:41:31Z"
  name: mirrod-ingress
  namespace: default
  resourceVersion: "3870"
  uid: 7c327ab4-7f06-4ac2-afdf-15372ba389df
spec:
  defaultBackend:
    service:
      name: webfrontend
      port:
        number: 8080
  ingressClassName: traefik
  rules:
  - host: demo.localdev.me
    http:
      paths:
      - backend:
          service:
            name: webfrontend
            port:
              number: 8080
        path: /
        pathType: Prefix
status:
  loadBalancer:
    ingress:
    - ip: 192.168.5.15

What is mirrord and How does it work?

mirrord is an open-source tool that lets developers run local processes in the context of their Kubernetes environment for example, on local like Docker Desktop, Rancher Desktop, Kind and others or on cloud-provided environments. It makes it incredibly easy to test your code on a Kubernetes environment without actually going through the hassle of Dockerization, Continuous Integration (CI), or Continuous deployment (CD), and without disrupting the environment by deploying untested code.

The below diagram describes the internal working of mirrord.

mirrord runs in two places - in the memory of your local process (mirrord-layer), and as a pod in your Kubernetes environment (mirrord-agent).

When you start your local process with mirrord, it creates a pod in your Kubernetes environment, which listens in on the pod you’ve passed as an argument and mirrord-layer performs

  • Listen to incoming traffic from the agent, instead of local sockets.
  • Intercept outgoing traffic and send it out from the remote pod, instead of locally.
  • Read and write files to the remote file system.
  • Merge the process’ environment variables with those of the remote pod.

For more information, you can visit mirrord

Installation of mirrord?

brew install metalbear-co/mirrord/mirrord
# execute below command to check the mirrord installation
mirrord -h
 
# this is output, you will get
Run a local process in the context of a cloud environment
 
Usage: mirrord <COMMAND>
Commands:
  exec         Execute a binary using mirrord, mirror remote traffic to it, provide it access to remote resources (network, files) and environment variables
  completions  Generates shell completions for the provided shell. Supported shells: bash, elvish, fish, powershell, zsh
  operator     Operator commands eg. setup
  teams        Try out mirrord for Teams
  diagnose     Diagnostic commands
  help         Print this message or the help of the given subcommand(s)
 
Options:
  -h, --help     Print help (see more with '--help')
  -V, --version  Print version

Installation of mirrord Visual Studio Code Extension?

You can install the extension directly in the IDE (Extensions -> search for ‘mirrord’), or download it from the marketplace here

After successful installation of the extension, you can see mirrord is available on Visual Studio Code's status bar. By clicking, you can enable or disable mirrord extension. By hovering, it displays other options.

Lets start debugging with mirrord and see the magic

To start debugging, we can open our DEMO in Visual Studio Code and it should look similar to

NOTE: Make sure, you have enabled the mirrord option by clicking on the status bar. During the initial setup of the debugging session, Visual Studio will ask you to select a 'project' and a remote 'pod' (running on a Kubernetes cluster). Refer to the snapshots below for project and pod selection.

If you observe closely the Visual Studio Code status bar, you will find that the mirrord agent is getting prepared for the Kubernetes cluster. You can verify this by opening Rancher Desktop GUI. Refer to the snapshots below.

After completing the installation of the mirrord agent, your debug session will be active. Now you can step through codebase and see the impact of new code changes in context of Kubernetes Cluster.

NOTE: I have modified Range from (1,5) to (1,9).

You can find a launch URL for api application in the Debug Console e.g., http://0.0.0.0:8080. Alternatively, you can use the apiservice.http file to call the API and observe the impact of code change.

Finally, you can verify that the Kubernetes-hosted pod api is returning 5 rows, while the local api is returning 9 rows but utilizing other dependencies from the Kubernetes Cluster. If you click on the Weather menu from the WebApp hosted on Kubernetes, your local api debugging session will be triggered. This is actual strength of mirrord, "Develop Locally with Your Kubernetes Environment"..

Conclusion

  • mirrord looks very promising and genuinely improves the Inner Dev Loop.
  • Ease of use
  • Focused on DX (Developer Experience)

NOTE: In this exercise, we have only begun to explore the capabilities of mirrord. It offers a range of important functionalities beyond what we have covered here.

Happy Learning & Coding...