- Features and Benefits
- Using Ambassador Edge Stack in Your Organization
- Ambassador Edge Stack vs. Other Software
- Certified Builds
- Ambassador Edge Stack Architecture
- Ambassador Edge Stack Deployment Architecture
- Continuous Delivery, Declarative Config, and GitOps
- Microservices API Gateways
- Rate Limiting Concepts
- Self-Service Routing and Deployment Control
- Safely Testing in Production
- OAuth & OIDC Overview
- Why Ambassador Edge Stack Uses Envoy Proxy (External Link)
- Configuring Ambassador Edge Stack
- Mapping Services
- Canary Releases
- Circuit Breakers
- Cross Origin Resource Sharing
- Header-based routing
- Host Header
- Host CRD
- Prefix Regex
- Rate Limits
- Remove Request Headers
- Remove Response Headers
- Add Request Headers
- Add Response Headers
- Automatic Retries
- Routing TCP Connections
- Traffic Shadowing
- Developer Portal
- Filter Reference
- Statistics and Monitoring
Sometimes you may want Ambassador Edge Stack to manipulate an incoming request. Some example use cases:
- Inspect an incoming request, and add a custom header that can then be used for routing
- Add custom Authorization headers
- Validate an incoming request fits an OpenAPI specification before passing the request to a target service
Ambassador Edge Stack supports these use cases by allowing you to execute custom logic in
Filters. Filters are written in Golang, and managed by Ambassador Edge Stack.
Filters are built as Go plugins and loaded directly into the Ambassador Edge Stack container so they can run in-process with the rest of Ambassador Edge Stack.
To build a
Filter into the Ambassador Edge Stack container you will need
Filter is built by
make which uses Docker to create a stable build environment in a container and
rsync to copy files between the container and your host machine.
See the README for more information on how the
We've created an example filter that you can customize for your particular use case.
Start with the example filter:
git clone https://github.com/datawire/apro-example-plugin/.
Make code changes to
param-plugin.go. Note: If you're developing a non-trivial filter, see the rapid development section below for a faster way to develop and test your filter.
make DOCKER_REGISTRY=..., setting
DOCKER_REGISTRYto point to a registry you have access to. This will generate a Docker image named
Push the image to your Docker registry:
docker push $DOCKER_REGISTRY/amb-sidecar-plugin:VERSION.
Configure Ambassador Edge Stack to use the plugin by creating a
FilterPolicyCRD, as per the filter reference.
Update the standard Ambassador Edge Stack manifest to use your Docker image instead of the standard sidecar.value: https://127.0.0.1:8443- name: AMBASSADOR_ADMIN_URLvalue: http://127.0.0.1:8877- image: quay.io/datawire/aes:1.1.0+ image: DOCKER_REGISTRY/aes-plugin:VERSIONimagePullPolicy: AlwayslivenessProbe:httpGet:
During development, you may want to sidestep the deployment process for a faster development loop. The
aes-plugin-runner helps you rapidly develop Ambassador Edge Stack filters locally.
To install the runner, download the latest version:Mac 64-bit |Linux 64-bit
Note that the plugin runner must match the version of Ambassador Edge Stack that you are running. Place the binary somewhere in your
Information about open-source code used in
aes-plugin-runner can be found by running
Now, you can quickly test and develop your filter.
In your filter directory, type:
aes-plugin-runner :8080 ./param-plugin.so.
Test the filter by running
curl:$ curl -Lv localhost:8080?db=2* Rebuilt URL to: localhost:8080/?db=2* Trying ::1...* TCP_NODELAY set* Connected to localhost (::1) port 8080 (#0)> GET /?db=2 HTTP/1.1> Host: localhost:8080> User-Agent: curl/7.54.0> Accept: */*>< HTTP/1.1 200 OK< X-Dc: Even< Date: Mon, 25 Feb 2019 19:58:38 GMT< Content-Length: 0<* Connection #0 to host localhost left intact
Note in the example above the
X-Dc header is added. This lets you inspect the changes the filter is making to your HTTP header.
For more details about configuring filters and the
plugin interface, see the filter reference.