Gloo invites invites developers to extend Gloo’s functionality and adapt to new use cases via the addition of plugins.
Gloo’s plugin based architecture makes it easy to extend functionality in a variety of areas:
- Gloo’s API: extensible through the use of Protocol Buffers along with Solo-Kit
- Service Discovery Plugins: automatically discover service endpoints from catalogs such as Kubernetes and Consul
- Function Discovery Plugins: annotate services with information discovered by polling services directly (such as OpenAPI endpoints and gRPC methods).
- Routing Plugins: customize what happens to requests when they match a route or virtual host
- Upstream Plugins: customize what happens to requests when they are routed to a service
- Operators for Configuration: Gloo exposes its intermediate language for proxy configuration via the
gloo.solo.io/ProxyCustom Resource, allowing operators to leverage Gloo for multiple use cases. The Gloo Gateway and Sqoop provide API Gateway and GraphQL Server functionality respectively, without needing to run in the same process (or even the same container) as Gloo.
Gloo API Concepts
- v1.Proxies provide the routing configuration which Gloo will translate and apply to Envoy.
v1.Upstreams describe routable destinations for Gloo.
Proxies represent a unified configuration to be applied to one or more instances of a proxy. You can think of the proxy of as tree like such:
proxy ├─ bind-address │ ├── domain-set │ │ ├── /route │ │ ├── /route │ │ ├── /route │ │ └── tls-config │ └── domain-set │ ├── /route │ ├── /route │ ├── /route │ └── tls-config └─ bind-address ├── domain-set │ ├── /route │ ├── /route │ ├── /route │ └── tls-config └── domain-set ├── /route ├── /route ├── /route └── tls-config
A single proxy CRD contains all the configuration necessary to be applied to an instance of Envoy. In the Gloo system, Proxies are treated as an intermediary representation of config, while user-facing config is imported from simpler, more opinionated resources such as the gateway.VirtualService or Kubernetes Ingress objects.
For this reason, a standard Gloo deployment contains one or more controllers which programmatically generate and write these CRDs to provide simpler, use-case specific APIs such as API Gateway and Ingress. Sqoop is an advanced controller which creates routing configuration for Gloo from GraphQL Schemas.
Click here for a tutorial providing a simple example utilizing this lower-level Proxy API. This tutorial will walk you through building a Kubernetes controller to automatically configure Gloo without any user interaction](example-proxy-controller.go).
- Upstreams represent destinations for routing requests in Gloo. Routes in Gloo specify one or more Upstreams (by name) as their destination. Upstreams have a
typewhich is provided in their
upstreamSpecfield. Each type of upstream corresponds to an Upstream Plugin, which tells Gloo how to translate upstreams of that type to Envoy clusters. When a route is declared for an upstream, Gloo invokes the corresponding plugin for that type
This Section includes the following developer guides:
- Setting up the Development Environment
- Building a Proxy Controller for Gloo
- Service Discovery Plugins for Gloo
- Building and Deploying Gloo from Source
- Contributor Guide
Environment Setup Prerequsistes Developing on Gloo requires the following to be installed on your system: make git go dep protoc (solo-io projects are built using version 3.6.1) the github.com/gogo/protobuf go package To install all the requirements, run the following: On macOS: # install protoc curl -LO https://github.com/protocolbuffers/protobuf/releases/download/v3.6.1/protoc-3.6.1-osx-x86_64.zip unzip protoc-3.6.1-osx-x86_64.zip sudo mv bin/protoc /usr/local/bin/ rm -rf bin include protoc-3.6.1-osx-x86_64.zip readme.txt # install go curl https://raw.githubusercontent.com/canha/golang-tools-install-script/master/goinstall.sh | bash # install dep go get -u github.
In this tutorial, we’re going to show how to use Gloo’s Proxy API to build a router which automatically creates routes for every existing kubernetes service, Writing the Code You can view the complete code written in this section here: example-proxy-controller.go. Initial code First, we’ll start with a main.go. We’ll use the main function to connect to Kubernetes and start an event loop. Start by creating a new main.go file in a new directory:
Intro Gloo uses the v1.Upstream config object to define routable destinations for Gloo. These are converted inside Gloo This tutorial will show how we can add an Upstream Plugin to Gloo to extend Gloo with service discovery data. Rather than provide a trivial example, we’ll use VM instances on Google Compute Engine as our Upstream. A single endpoint will represent a single VM instance, and an Upstream will group them by their VM Labels.
Intro This doc coming soon! For now, see Gloo’s Makefile and Helm Chart to get started building and deploying Gloo from source.
Excited about Gloo and want to help make it better? At Solo we strive to make the world of microservices, serverless and service mesh available to everyone. If you want to help but don’t know where to start, let us know, and we’ll find something for you. If you haven’t already, make sure you sign up for the Solo Slack. Here are some of the ways you can contribute:
Note: the Controller tutorial does not require modifying any Gloo code.