Architecture and components
The information on this page is written for Vamp v0.9.2
Vamp and the Vamp Gateway Agent require specific elements in your architecture to handle orchestration, routing, persistence and metrics aggregation. There is no set architecture required for running Vamp and every use case or specific combination of tools and platforms can have its own set up.
The below diagram should be used more as an overview than required architecture. For example, in this diagram the Mesos/Marathon stack and Elasticsearch are included even though these are not a hard dependency. Vamp can be configured to run with other container schedulers, log-aggregators, key-value and event-stores.
Vamp consists of server- and client-side components that work together with elements in your architecture to handle orchetstration, routing, persistence and metrics aggregation.
The Vamp UI is a graphical web interface for managing Vamp in a web browser. It is packaged with Vamp.
The Vamp CLI is a command line interface for managing Vamp and providing integration with (shell) scripts. It’s currently not very well maintained but still can be useful if our REST API cannot be used for your integration requirements.
Vamp is the main API endpoint, business logic and service coordinator. Vamp talks to the configured container manager (Docker, Marathon, Kubernetes etc.) and synchronizes it with Vamp Gateway Agent (VGA) via ZooKeeper, etcd or Consul (distributed key-value stores). Vamp can use Elasticsearch for artifact persistence and to store events (e.g. changes in deployments). Typically, there should be one Vamp instance and one or more VGA instances. Vamp is not a realtime application and only updates deployments and routing when asked to (reactive) and thus doesn’t need to run with multiple instances in HA mode. If this is a hard requirement of your project please contact us for the Vamp Enterprise Edition.
Vamp Gateway Agent (VGA)
Vamp Gateway Agent (VGA) reads the HAProxy configuration from ZooKeeper, etcd or Consul and reloads HAProxy on each configuration change with as close to zero client request interruptions as possible. Typically, there should be one Vamp instance and one or more VGA instances.
Logs from HAProxy are read over socket and pushed to Logstash over UDP. VGA will handle and recover from ZooKeeper, etcd, Consul and Logstash outages without interrupting the HAProxy process and client requests.
- Read about the requirements to run Vamp
Last updated on October 2, 2017