It’s no secret that ElasticBox performs deployments on your remote virtual machines using an agent. But what goes on behind the scenes? What makes the agent tick? Join me for a deep dive.
Though not visibly apparent, when you trigger deployments from the web or API, the agent is the software we install on every virtual machine you deploy from ElasticBox. Its sole purpose is to handle box deployments on the VM or service. It executes event scripts and runs lifecycle operations from the web or API calls. By itself the agent does not contain any other logic. It executes whatever ElasticBox tells it to do and sends back the logs of the output.
We built the agent based on three important principles of software architecture:
- To be platform interoperable, that is, work on any OS or platform.
- To be network interoperable, that is, communicate over any network configuration easily.
- To cover a small footprint, that is, consume the least amount of machine resources.
Platform interoperability is pretty important. The agent works across all platforms on any OS and runtime libraries. It works cross-platform because it’s written in Python, and doesn’t require any dependencies.
In recent times, we made vast changes to the agent.
Before, the agent used the AMQP (Advanced Message Queuing Protocol) to communicate with ElasticBox. The agent subscribed and listened to messages in the queue. When the messages came from ElasticBox, they first got in the queue. Then the agent as a subscriber got the message, executed it and sent the results back to ElasticBox in another queue that again followed the same publish and subscribe pattern to relay the message.
Now, the agent communicates directly and faster. ElasticBox uses an HTTP WebSocket interface over the API to install and talk to the agent. Since the WebSocket protocol communicates bidirectionally, messages route faster in a less complex fashion.
Benefits of the improved agent
I’ll go over how these changes benefit deployments. First, networks can readily talk to ElasticBox whether in the public or private datacenter cloud. AMQP as a lower level network protocol requires different ports to communicate. Earlier, you needed to open a firewall, which can pose constraints. Whereas now, the agent communicates securely over HTTP WebSockets port 443, which most networks are already configured to communicate with the Internet. If you have an HTTP proxy set up for Internet traffic, then your VMs talk to ElasticBox by default with no additional networking required.
Second, you get a uniform bootstrapping on any platform, any cloud provider. Bootstrapping helps prepare the machine for ElasticBox use. We installed the agent before differently on vSphere versus Amazon or MyServer. Now across every provider or infrastructure, you follow the same method, which is to run this single cURL command.
The command allows you to recover a previously offline agent. If the agent gets stuck for whatever reason, you can reinstall with that command and the agent will continue the deployment from where it stopped.
Third, you get better logging. Now that ElasticBox communicates directly over the API, we get a detailed record of all the logs in real-time. With real-time logs, the activity on an instance is pretty much information as it happens.
In short, we connect to the agent directly. What architecture changes does that mean for the future? One valuable result of this change is to be able to report the exact status of the instance and the agent anytime. For the most part, these changes are transparent to you, and that’s a good thing. As you continue to deploy with ElasticBox, you you can look forward to faster and more fail-proof deployments 100% of the time.