Persona-driven workspace setup
Review the following persona-driven example to set up workspaces to control team access.
- Pam, the platform admin, installs Gloo Mesh Gateway and sets up workspaces for each team.
- Arjay, the app owner, works with each team’s lead to configure the workspace settings. These settings control which workspaces can share, or import and export resources, with other workspaces.
- Alice, the app developer, focuses on developing her services. She makes sure to label her apps so that they are automatically picked up by the appropriate routes and policies.
- Oliver, the operator, deploys the app services. He sets up the routes and policies. With Arjay, he makes sure that the right resources are reused across workspaces.
Pam focuses on getting the workspaces set up for each team. The setup includes installing Gloo in the cluster. Then, she creates a Workspace resource for each team, that selects the clusters and namespaces to include in the workspace. She might also create a global workspace settings to enforce certain default behavior across workspaces, like service isolation.
The following diagram shows the Gateway, Web-api, and Recommendation workspaces for the team.
The owners for each workspace set up the import and export settings so that they can access services in the other workspaces. Typically, this person is Arjay, the app owner, but if the engineers are primarily responsible for deploying services, the person might be Oliver, the operator.
The following diagram shows the settings for the workspaces.
- Gateway: Imports services from both the Recommendation and Web-api workspaces so that the gateway can serve apps from those workspaces. Exports only to the Recommendation workspace, so that later, the operators can delegate route tables to the workspace.
- Web-api: Imports from only the Recommendation workspace to use the Recommendation services. Exports to only the Gateway workspace, to serve the web apps there.
- Recommendation: Imports from the Gateway workspace so that later, the Recommendation team can set up delegated routing resources. Exports to the Gateway and Web-api workspaces so that they can use the Recommendation services.
Alice, the developer, deploys the apps for her teams. The main thing that she has to remember is to use Kubernetes labels on all of her resources, so that later, Gloo resources like policies are automatically applied.
The following diagram shows the app deployment.
- Gateway: The ingress gateway is set up in the Gateway workspace. Typically, an operator like Oliver does this task. In the virtual gateway spec, the route table for the recommendation app is delegated to the Recommendation workspace.
- Web-api: Alice deploys two versions of the web app. She doesn’t have to worry about deciding how much traffic each gets, because that is controlled by a policy. The policy applies automatically to her app because of the labels.
- Recommendation: Alice deploys the recs app. She also updates a Gloo resource, the route table, with the route to test her app,
test.recommendation.istioinaction.io.
Your operator team focuses on shipping the services to production.
The following diagram shows the final flow for end-user traffic.
- Gateway: The ingress gateway receives the user request and forwards it to the appropriate apps. Additionally, Oliver creates policies to control the traffic: A/B routing to versioned apps in web-api, and security policies in recommendation.
- Web-api: The different versions of the app serve traffic as controlled by the policy that Oliver set up. Arjay the app owner doesn’t have to set up any extra settings.
- Recommendation: Oliver or Arjay make sure that the recs app has a virtual destination so that the web app in a different workspace can reach it.
