Developing distributed applications
Building a distributed application, such as bgp-ping
, can be a major undertaking. Unit testing and debugging can help spot and fix a lot of bugs, but these processes can be time-consuming. In certain cases, when an application has different components, developing your code iteratively may require some manual orchestration. Steps such as building binary files and container images, starting the software process, enabling logging, and triggering events are now something you need to synchronize and repeat for all the components that include your application.
The final developer experience tool that we will cover in this chapter was specifically designed to address the preceding issues. Tilt helps developers automate manual steps, and it has native integration with container and orchestration platforms, such as Kubernetes or Docker Compose. You let it know which files to monitor, and it will automatically rebuild your binaries, swap out container images, and restart existing processes, all while showing you the output logs of all applications on a single screen.
It works by reading a special Tiltfile
containing a set of instructions on what to build and how to do it. Here’s a snippet from a Tiltfile that automatically launches a bgp-ping
process inside one of the host containers and restarts it every time it detects a change to main.go
:
local_resource('host-1', serve_cmd='ip netns exec clab-netgo-host-1 go run main.go -id host-1 -nlri 100.64.0.0 -laddr 203.0.113.0 -raddr 203.0.113.1 -las 65003 -ras 65000 -p', deps=['./main.go'])
The full Tiltfile
has two more resources for the other two hosts in our lab network. You can bring up all three parts of the application with sudo
tilt up
:
Network-Automation-with-Go $ cd ch10/bgp-ping Network-Automation-with-Go/ch10/bgp-ping $ sudo tilt up Tilt started on http://localhost:10350/
Tilt has both a console (text) and a web UI that you can use to view the logs of all resources:
Figure 10.8 – Tilt
Any change to the source code of the bgp-ping
application would trigger a restart of all affected resources. By automating a lot of manual steps and aggregating the logs, this tool can simplify the development process of any distributed application.