At the heart of our transformation, Telepresence stands out as a better debugging method:
Telepresence allows you to test changes in your local development environment in isolation, eliminating the need for a full deployment cycle for each code adjustment.
With Telepresence, you can simulate the live environment and interact with services, making it easier to identify and resolve issues before they reach the production stage.
This dynamic testing approach speeds up the development process, minimizes bottlenecks, and enhances the overall quality of our Microservice applications.
For nearly two years, our development team has been using Jenkins as our go-to tool for handling builds, but it’s safe to say that the honeymoon period is over. The painstaking process of troubleshooting failed builds within Jenkins left us exhausted and frustrated. It became abundantly clear that we needed a new approach, and we had been contemplating a transition to a different deployment tool for quite some time.
Our current project is firmly rooted in the Microservice architecture, a landscape where frequent builds are the norm. However, the building process was far from ideal:
- Push the code to the repository.
- Build the code and deploy.
- Test.
And if any modifications were required, we found ourselves stuck in a never-ending cycle, repeating the same steps over and over again.
But it’s time for a paradigm shift. We’ve discovered an innovative solution in Telepresence, a tool that allows us to rethink our approach entirely. By flipping the traditional Build and Test cycle into a Test and Build cycle, we’ve brought a fresh and transformative edge to our Microservice Application’s testing and deployment.
Testing with Telepresence.
Telepresence allows you to test changes in your local development environment in isolation, eliminating the need for a full deployment cycle for each code adjustment.
With Telepresence, you can simulate the live environment and interact with services, making it easier to identify and resolve issues before they reach the production stage.
Simply install Telepresence on your local machine:
(Ubuntu):
# 1. Download the latest binary (~95 MB):
sudo curl -fL https://app.getambassador.io/download/tel2oss/releases/download/v2.16.1/telepresence-linux-amd64 -o /usr/local/bin/telepresence
# 2. Make the binary executable:
sudo chmod a+x /usr/local/bin/telepresence
(Windows):
Download the zip file: https://app.getambassador.io/download/tel2oss/releases/download/v2.16.1/telepresence-windows-amd64.zip
(macOS):
# Intel Macs
# 1. Download the latest binary (~105 MB):
sudo curl -fL https://app.getambassador.io/download/tel2oss/releases/download/v2.16.1/telepresence-darwin-amd64 -o /usr/local/bin/telepresence
# 2. Make the binary executable:
sudo chmod a+x /usr/local/bin/telepresence
# Apple silicon Macs
# 1. Download the latest binary (~101 MB):
sudo curl -fL https://app.getambassador.io/download/tel2oss/releases/download/v2.16.1/telepresence-darwin-arm64 -o /usr/local/bin/telepresence
# 2. Make the binary executable:
sudo chmod a+x /usr/local/bin/telepresence
Reference: https://www.telepresence.io/docs/latest/quick-start/
Once you have successfully installed Telepresence on your machine, it is time to install its dependencies on your Dev server.
Connect to your Dev server with Kubernetes.
Once you’re connected to your Dev-server, run the following command:
telepresence helm install.
It will install the traffic manager on your dev server in a new namespace “ambassador”. Which is basically going to manage all your traffic.
Now it’s time to connect telepresence with your dev server. Run the following command.
telepresence connect -n <your-namespace>
Once you’re connected to your server with telepresence. It’s time to simulate the live environment and interact with services.
telepresence list
The above command will list all the services/deployments (which contain ports) of your namespace that are ready to intercept.
In the provided list, there is a service called “cloned-stage-internal-api-server,” which is essentially a replica of the “stage-internal-api-server.” This duplicated service employs an Alpine image and does not contain the core functionality of the original “stage-internal-api-server.”
The purpose of this clone is to maintain the integrity of the system’s primary functionality while conducting interception or testing of other services. The cloned service has been configured with all the essential functionalities and environment variables (ENVs) that are shared across all our microservices.
Intercept the service.
telepresence intercept cloned-stage-internal-api-server –env-file /path-to-save/env-file
The above command will intercept your service and will also save the env variables to your local path. Now, you’re ready to access all the traffic running on your dev server with your local machine.
In our case, we are using celery task workers with RabbitMQ. Each celery worker is a microservice.
Let’s say I want to add a feature to my celery worker(Python application) and test it on my dev server before building and deploying it. As my local machine is connected to the dev server with telepresence I will be able to access all the traffic of the dev server. Now, I can run that single celery worker queue on my local machine and scale down the same worker on my dev server.
In the above image example, I am creating a new configuration file for running the single queue.
- I have added the script that contains the path to my celery command and in the parameters I have added the queue name followed by the rest parameters.
- I have set the working directory which contains my tasks.py file
- Copy all the environment variables that are available in the env file that you saved on your local machine while intercepting the service. Pass this copied ENV to the Environment variables section. Make sure to uncheck the “include system environment variables” flag before saving. Apply the changes.
- Run the config file. You will see that the queue is connected to your dev server.
Now, as you have scaled down the worker that is running on your dev environment. Since you have run the single queue on your local machine. You will now see that the traffic of your dev server is now passing through your local machine.
All the rest workers will consume traffic from your dev-server.
Once you intercept the service from your development server, you have the capability to test and implement code changes for any of your microservices that are accessible on your development server. This allows you to conduct testing and make necessary adjustments to your microservices while they are running in the development environment.
Since your testing is complete and your code is working fine. Release that intercepted service back to the dev server.
Since the code is fully developed and ready for deployment in the development environment. It’s time to utilize Argo workflows to create the necessary builds.
