Engineering Release Summary — July 2019
July was a busy month for the team working on Gloo open source and Enterprise. Thank you for the feedback, issues and PRs — knowing what is and is not working as you deploy Gloo into your environments helps improve Gloo for everyone! Special thanks to @DerrickBurns for the contributions to this release. You can file issues and PRs in GitHub or join our community slack to ask questions.
Gloo Open Source v0.18
We’ve shipped a few more releases already in the first few days of August so make sure to check out the full changelog for a complete list of new features, fixes and breaking changes since our last release post from v0.14.2.
NOTE: This release required an API break to our gateway CRD. We tried to make the upgrade process easy and painless with canarying: pass the upgrade flag to glooctl or helm, and we’ll automatically convert your resources while preserving your existing proxy configuration, and then you can shift traffic to the new proxy. Check out https://gloo.solo.io/upgrading/0.18.1/ for details on how to seamlessly upgrade Gloo, automatically convert existing configuration, and migrate traffic while avoiding downtime.
New Feature Highlights
For the first time, Gloo now supports proxying TCP traffic in addition to HTTP. Like with HTTP routing, Gloo TCP gateways can be configured to route to single or multiple destinations and can route SSL traffic and perform SNI domain matching. This feature expands the utility of the Gloo Gateway, allowing organizations to use it as a unified access point for end users (clients) to access resources like databases, message queues, caches, and more that are not HTTP based. Learn more by trying the tutorial here.
Support for Non-Kubernetes Environments with HashiCorp Consul
In July, we improved the ability for Gloo to run outside of a Kubernetes environment. In particular, we integrated Gloo with HashiCorp products like Consul and Vault for managing config and secrets, and Nomad workload orchestrator. This allows Gloo to discover services in Consul and route requests to them. We are excited about this integration because it supports a key tenant in our mission to help organizations migrate to cloud native architectures and support hybrid and diverse environments. Requested by a number of customers and end users, these new features enable Gloo to run in environments that do not use Kubernetes.
We’ll publish another post soon that goes into this in more detail but in the meantime, check out:
Routing to EC2 Endpoints
Gloo can now be configured to route to instances in EC2. A new EC2 upstream type was added, which requires EC2 credentials and optionally an ARN to take advantage of the AWS assume role API. A filter can also be provided, so that traffic to that upstream destination is automatically load-balanced across all instances that match the filter. For more information, check out the tutorial.
More Envoy Features
A number of Envoy features were added as Gloo plugins in the last month. Gloo can now be configured to setup tracing with a variety of standard Tracers, and with Gateway or Route-level settings. Gloo can configure Envoy access logs for HTTP and TCP traffic (try the feature here)
Get Started with Gloo Today
In addition to the three major features above, we also added a bunch of other improvements to Gloo, such as exposing Envoy tracing, access logging, and traffic shadowing. Check out the full changelog for all the features, bug fixes, and breaking changes since our last release post from v0.14.2.