1
0
mirror of https://github.com/Unleash/unleash.git synced 2024-10-28 19:06:12 +01:00
unleash.unleash/website/docs/understanding-unleash/proxy-hosting.mdx

175 lines
10 KiB
Plaintext
Raw Normal View History

---
title: Edge & Proxy hosting strategies
---
import VideoContent from '@site/src/components/VideoContent.jsx'
This document describes the main ways of hosting [Unleash Edge](../generated/unleash-edge.md) (or alternatively [Unleash Proxy](../generated/unleash-proxy.md)) alongside the Unleash API and the tradeoffs between self-hosting compared to using the Frontend API that Unleash hosts for you.
Whether you're hosting Unleash yourself or have a managed solution will be a key consideration.
:::info Warning
Edge is the next-gen replacement of the Unleash proxy and is recommended to be used over the proxy in most cases, with the exception of the scenario where custom strategies are being used as Edge does not support these.
:::
<VideoContent videoUrls={["https://www.youtube.com/embed/6uIdF-yByWs"]}/>
## Unleash-hosted Frontend API vs self-hosted Edge/Proxy {#unleash-hosted-or-self-hosted}
Which way is right for you will depend on your setup and your needs.
In general, we recommend you use Edge over the [Frontend API](https://docs.getunleash.io/reference/front-end-api), but we do recognize that self-hosting requires some extra work on your part and that not all our customers need it.
If you want Unleash to host the Frontend API for you, you should be aware of the following limitations:
- This is only available to Pro and Enterprise customers who have signed up for a managed Unleash instance.
- We allow short spikes in traffic and our adaptive infrastructure will automatically scale to your needs.
- Please check the [Fair Use Policy](https://www.getunleash.io/fair-use-policy) to see the limits of the Unleash-hosted Frontend API.
- There's no guarantee that it'll be geographically close to your end users, this means your end users might be getting slower response times on feature flag evaluations.
- When we host the frontend API, we will also receive whatever end user data you put in the [Unleash context](../reference/unleash-context.md). This may or may not be an issue depending on your business requirements.
Hosting Edge requires a little more setup the Unleash-hosted Frontend API does, but it offers a number of benefits over both the frontend API and Proxy:
- You can scale Edge instances horizontally and automatically.
- There's no request cap or extra charges.
- Edge can handle multiple sets of API tokens and sync these automatically. Compared to the legacy proxy, it is not necessary to setup single instances per token.
- A key benefit of Edge is its ability to dynamically update new tokens while running. This greatly simplifies scaling up additional application workloads that leverage new tokens without the need to restart the instance or make large changes to infra, as was the prior requirement with the proxy.
- You can arrange for Edge to be close to your applications, minimizing response times.
- You have full control of all your user data. None of the data that Edge receives is ever sent to the Unleash API. This keeps _your_ data in _your_ hands.
- You can easily add more Edge instances in different regions, as described in the [multi-region](#multi-region) section.
## Unleash hosts everything
:::info Availability
This setup is only available to Pro and Enterprise customers.
:::
Unleash no longer hosts instances of the proxy, but makes the [Frontend API](../reference/front-end-api) available to all Pro and Enterprise customers. The API is backed by an Amazon RDS database. Your applications can connect to the frontend API from your own cloud or from other hosting solutions.
In order to access the frontend API you'll need
- to create a [Frontend API key](../reference/api-tokens-and-client-keys#front-end-tokens) for the environment you'd like to use.
- The Frontend API URL. This will be the your Unleash instance's URL followed by "/api/frontend".
This is the simplest, but also most limited (by far) way to use Unleash client SDKs. In this setup, Unleash hosts both the Unleash API and the Unleash frontend API. With Unleash hosting, you'll only need to worry about the Frontend API keys and the URL to access the endpoint.
While this is easy to get started with, it comes with the limitations described in the [section on tradeoffs between self-hosted and Unleash-hosted setups](#unleash-hosted-or-self-hosted).
## Unleash hosts the API, you host Edge
:::info Availability
This setup is only available to Pro and Enterprise customers.
:::
![An architecture diagram of using Edge in a setup where Unleash hosts the API and you host the proxy.](/img/proxy-hosting-unleash-api-customer-proxy-edge.svg)
You host Edge yourself. It runs in a standalone container alongside your other applications in your cloud or hosting setup. Unleash manages the Unleash API, the admin UI, and the backing database in our AWS setup: the API and the UI run together in a Kubernetes deployment and connect to an Amazon RDS database.
You'll need to configure Edge and the SDKs.
### On Unleash
- Create one or multiple [client API tokens](https://docs.getunleash.io/reference/api-tokens-and-client-keys#client-tokens) scoped to the projects/environments you wish to leverage the Edge instance for. (Refer to [how to create API tokens](https://docs.getunleash.io/how-to/how-to-create-api-tokens) for the steps to create one)
- Create frontend tokens for the frontend apps that will retrieve feature flags from Edge
### On Edge
Edge will fetch feature flags from the specified upstream Unleash instance for every client API key it has been made aware of, either during startup (recommended) or separate endpoint requests. It will then periodically sync features with upstream.
It will then accept frontend / backend tokens from application SDKs.
:::info Warning
Make sure to use the correct token type for the use case:
Frontend API: Frontend facing apps only, Edge returns app specific context
Client API: For backend SDKs, Edge returns entire flag payload for scope of token (project/environment)
:::
**Start Edge & populate flag cache**
- This initial command will populate flag cache on startup using the client token specified in the environment variable:
```docker run -p 3063:3063 -e TOKENS='CLIENT_API_TOKEN' -e UPSTREAM_URL='UPSTREAM_URL' unleashorg/unleash-edge:v8.1 edge```
The following can be used to pass new tokens to Edge for different project/environment scopes:
```curl --location --request GET 'http://0.0.0.0:3063/api/client/features' \ --header 'Content-Type: application/json' \ --header 'Authorization: NEW_TOKEN' \ --data-raw ''```
### On SDKs
- Point frontend/client SDKs to Edge endpoints
- **Backend SDKs:** /api/client
- **Frontend SDKs:** /api/frontend, /api/proxy
## You host everything
:::info Availability
This setup is only available open-source and Enterprise customers.
:::
![An architecture diagram of using the proxy in a single-region, self-hosted setup.](/img/proxy-hosting-customer-single-edge.svg)
You host everything yourself. Everything runs where and how you configure it to.
**To configure Edge and the SDKs, follow steps in the [previous section on Unleash hosts the API, you host Edge](#unleash-hosts-the-api-you-host-edge)**
As you might expect, doing everything yourself _is_ going to give you the most flexibility, but it's also going to be the most work. If you're already hosting Unleash yourself, though, this shouldn't be any more difficult than the previous section.
As described in the [section on tradeoffs between self-hosted and Unleash-hosted setups](#unleash-hosted-or-self-hosted), running Edge yourself gives you a number of benefits.
## Multi-region
![An architecture diagram of using the proxy in a multi-region, self-hosted setup.](/img/proxy-hosting-customer-multi-edge.svg)
You can also use Edge for a multi-region setup. You can run Edge in a different region to the API and still connect to the API. Because Edge runs closer to your applications it still provides you benefits in terms of quicker response times. Everything should be configured as described in the [you host everything section](#you-host-everything) or the [Unleash hosts the API, you host Edge section](#unleash-hosts-the-api-you-host-edge). You can add as many Edge instances in as many extra regions as you want.
## Legacy: Unleash hosts the API, you host the Proxy
:::info Recommendation
This approach is no longer recommended. You should use [Unleash Edge](../reference/unleash-edge) instead of the Unleash proxy.
If you are an existing Proxy user, see our [Edge migration guide](https://github.com/Unleash/unleash-edge/blob/main/migration-guide.md) for a guide on how to migrate.
Please take note of the section covering features Edge does not currently support in the same linked document before planning a migration.
:::
:::info Availability
This setup is only available to Pro and Enterprise customers.
:::
![An architecture diagram of using the proxy in a setup where Unleash hosts the API and you host the proxy.](/img/proxy-hosting-unleash-api-customer-proxy.svg)
You host the proxy yourself. It runs in a standalone container alongside your other applications in your cloud or hosting setup. Unleash manages the Unleash API, the admin UI, and the backing database in our AWS setup: the API and the UI run together in a Kubernetes deployment and connect to an Amazon RDS database.
You'll need to configure the proxy and the proxy client SDKs.
For the proxy, configure:
- The Unleash API url. This is your Unleash instance URL followed by "/api".
refactor: move docs into new structure / fix links for SEO (#2416) ## What This (admittedly massive) PR updates the "physical" documentation structure and fixes url inconsistencies and SEO problems reported by marketing. The main points are: - remove or move directories : advanced, user_guide, deploy, api - move the files contained within to the appropriate one of topics, how-to, tutorials, or reference - update internal doc links and product links to the content - create client-side redirects for all the urls that have changed. A number of the files have been renamed in small ways to better match their url and to make them easier to find. Additionally, the top-level api directory has been moved to /reference/api/legacy/unleash (see the discussion points section for more on this). ## Why When moving our doc structure to diataxis a while back, we left the "physical' files lying where they were, because it didn't matter much to the new structure. However, that did introduce some inconsistencies with where you place docs and how we organize them. There's also the discrepancies in whether urls us underscores or hyphens (which isn't necessarily the same as their file name), which has been annoying me for a while, but now has also been raised by marketing as an issue in terms of SEO. ## Discussion points The old, hand-written API docs have been moved from /api to /reference/api/legacy/unleash. There _is_ a /reference/api/unleash directory, but this is being populated by the OpenAPI plugin, and mixing those could only cause trouble. However, I'm unsure about putting /legacy/ in the title, because the API isn't legacy, the docs are. Maybe we could use another path? Like /old-docs/ or something? I'd appreciate some input on this.
2022-11-22 10:05:30 +01:00
- A [client API token](../reference/api-tokens-and-client-keys.mdx#client-tokens). (Refer to [how to create API tokens](../how-to/how-to-create-api-tokens.mdx) for the steps to create one.)
- One or more [proxy client keys](../reference/api-tokens-and-client-keys.mdx#proxy-client-keys). Refer to the [configuration section of the proxy document](../reference/unleash-proxy#configuration) for more details.
For the proxy client SDK, configure:
- One of the proxy client keys that you configured for the proxy.
- The proxy's endpoint. This will depend on where and how you're hosting the proxy, but will typically end in "/proxy"
This setup requires a little more setup on your part than the Unleash-hosted proxy does, but it offers all the benefits described in the [section on tradeoffs between self-hosted and Unleash-hosted setups](#unleash-hosted-or-self-hosted).