ESP Architecture and Services
ESP API Architecture (Backend)
ESP Status
A local ESP instance is composed of a set of services running in a Docker container. If your container is running, but you can’t access ESP in the browser, use the l7 command-line utility to check the status of the services. Each service can be in any one of the states listed here.
$ l7 status $ l7 stop # stop all services $ l7 start # start all services $ l7 restart # restart all services in one command $ l7 status l7-esp.broker RUNNING pid 429, uptime 0:33:47 l7-esp.concierge RUNNING pid 351, uptime 0:33:51 l7-esp.database RUNNING pid 352, uptime 0:33:51 l7-esp.executor RUNNING pid 440, uptime 0:33:47 l7-esp.haproxy RUNNING pid 437, uptime 0:33:47 l7-esp.http:l7-esp.http.0 RUNNING pid 443, uptime 0:33:47 l7-esp.http:l7-esp.http.1 RUNNING pid 441, uptime 0:33:47 l7-esp.http:l7-esp.http.2 RUNNING pid 444, uptime 0:33:47 l7-esp.hub RUNNING pid 358, uptime 0:33:51 l7-esp.logger RUNNING pid 445, uptime 0:33:47 l7-esp.multitenant EXITED Jun 10 01:23 AM l7-esp.notary EXITED Jun 10 01:23 AM l7-esp.notification RUNNING pid 362, uptime 0:33:51 l7-esp.pdf-server RUNNING pid 436, uptime 0:33:47 l7-esp.pipeline RUNNING pid 446, uptime 0:33:47 l7-esp.queue RUNNING pid 365, uptime 0:33:51 l7-esp.redis RUNNING pid 366, uptime 0:33:51 l7-esp.scheduler EXITED Jun 10 01:23 AM
Here’s a short description of what each service is responsible for:
l7-esp.broker
ZeroMQ Broker (backend messages for services mentioned below)
l7-esp.concierge
Configuration and services control
Metrics
Flask (synchronous*) web server deployed via Gunicorn
l7-esp.database
Launches and monitors PostgreSQL database and creates schema if needed
l7-esp.haproxy
Launches HAProxy and monitors it
l7-esp.http
Main backend server
Tornado (asynchronous) v5 web server
l7-esp.logger
Logger consolidation (places all logs into a combined l7-esp.log)
Custom Python implementation
Receives logging messages via ZeroMQ
l7-esp.notification
Handles all notifications for users
Allows for notifications between ESP instances via Kafka
Flask (synchronous*) web server deployed via Gunicorn
l7-esp.pdf-server
Generates PDF using Puppeteer and Chrome
Node.js web server
l7-esp.pipeline
Controls pipelines by submitting to the Executor
Custom Python implementation
Receives messages via ZeroMQ
l7-esp.executor
Handles execution of tasks given to it
Custom Python implementation
Receives messages via ZeroMQ
l7-esp.scheduler
Runs scheduled tasks read from the configuration
Custom Python implementation
l7-esp.hub
Connects to other ESP instances to function as a hub of content
Allows for installing content from other hubs
Flask (synchronous*) web server deployed via Gunicorn
When faced with problematic idiosyncrasies, stopping and starting (as opposed to “restarting”) the services will typically resolve any issues. Other times, you may have to inspect the logs for specific services. We’ll revisit the ESP logs later in the course.
Python Environments in the Development Container
A typical development container (any docker image with -sdk at the end) has two different Python environments installed.
server (or system) python
the environment in which all ESP services run (including server-side extensions)
interpreter located at
/usr/bin/python
client python
the environment in which the ESP client is installed
typically used by pipeline scripts
interpreter located at
/data/extensions/client/bin/python
For most of this course, we’ll want to work in the client python environment. To activate this environment, run the following command.
source ~/data/extensions/client/bin/activate
If you’re ever unsure of which environment is active, run esp and see if you get the ESP Client help information (see ESP Client in Key Terms section below). If you get a “command not found” error, you do not have the client python environment active.