This document is a work in progress
Tents is a deployment tool for cloud native apps and app developers.
If you're building a cloud native app, use Tents to:
- Quickly set up a dev environment to run your app in
- Spin up a new instance of your app for each PR
- Run your app in production, and keep it running
- Roll out new versions of your app in production
Tents Does a Lot
Tents has a lot of features and solves a big problem for app developers, but it doesn't invent any new concepts and it isn't novel software. Instead, it "builds on the shoulders of giants"
Tents is an Extraction, not an Invention
Tents assembles modern technologies and principles and makes them accessible to you. During assembly, Tents took a very opionated view on how each piece should be used, and thus, Tents has an opinionated holistic view on how apps should be run. There's a good reason why Tents doesn't do certain things, but if you do need to do something outside the scope of Tents, there's always an "escape hatch" that you can use to get your work done and still use Tents for the other things.
Here are some of the principles that Tents borrows from:
- Organizations, repositories and teams from Github
- Traffic splitting
- Cookie-based routing
- Shadow deployments
- A/B testing
Here are some of the technologies and principles that Tents uses:
- Istio and Envoy
- JSON Web Tokens
User Workflow with Tents
Tents has a standard feature set that gives you a powerful but easy workflow:
- Write your code
- Build your code into a Docker image (Tents can help with this too!)
Tents also helps you do local development:
tents dev init will set up your local development environment:
- A local Minikube cluster optimized for a fast development cycle
- A Dockerfile suitable for building their development app
- A pare configuration file suitable for building the entire application for development
DEVELOPING.mdfile that describes the basic development cycle
Production app rollouts are special because your app can't go down and your users should not notice any issues while the rollout is in progress. Tents supports features to help during rollouts
- Cookie-based routing
- Traffic splitting
- A/B testing
Additionally, Tents has a powerful authentication/authorization system to make sure nobody can accidentally deploy to production
The simplest cloud native application usually runs in three environments:
- Development: the environment you push code to very frequently, to do quick local testing
- Staging: the environment you push code to, so you can test right before you promote to production
- Production: the big show!
Good news! Tents supports those environments and any other ones you define.
Here's what an environment is to Tents:
- Code: the application that's running
- Configuration: credentials, environment variables, etc...
- Resources: the CPUs that run the application, databases, networking, etc...uses)
Environments are defined in Tents by the organization/application model described below in the Application Layout, Authentication and Authorization section.
You'll interact with environments primarily via the
tents deploy tool. For example:
tents deploy myorg/app1
Organizations, Applications and Teams
Organizations, applications and teams define how Tents organizes all your applications.
- Organization: a "bucket" that Tents keeps the following in:
- Common configuration
- Authentication (authn) rules
- Authorization (authz) rules
- Application: an application! Each application has configuration that is merged with its organization's configuration, but the app config overrides the org config
- Teams: groupings of users (see below) inside an organization. An application can assign one or more teams to one of three roles:
read: the team can only see deployment history and app status
deploy: the team can do everything from
read, and they can also deploy new application versions
admin: the team can do everything from
deployand they can change configuration or delete the application. They can also add additional teams or users directly to the application
Organization names have to be "globally" unique (there can only be one organization 'myorg' per Tents installation), and team and application names have to be unique inside each organization.
Note: organizations, applications and teams in Tents are a concept modeled after organizations and repositories in GitHub
Authentication and Authorization
Authentication (authn) and Authorization (authz) are important to Tents because they make sure that nobody accidentally deploys to production! Also, we want to make sure that environments are split up so that everyone has their own environment to work in.
Authn and authz work alongside organizations, applications and teams (from above) to provide a really powerful way to organize and secure your applications.
Each person who interacts with a Tents installation gets a username and a user account. Authentication and authorization are done via a standard username/password, and users are issued JSON Web Tokens after they login, so that they don't need to continuously login (both on the CLI and the Tents dashboard).
Every new user gets an organization automatically created for them, and they have permanent
admin rights for all applications created in that organization (they can't delete the organization though). Since usernames are also organization names, they have to be globally unique just like organizations.
As mentioned in the Organizations, Applications and Teams" section above, each user can get put into one or more teams inside each organization. Users can also be assigned directly to an application.
Use Case: Pull Requests
Most developers submit a pull request (PR) to solicit reviews (code, design, ...) from their team mates. CI systems generally
run on PRs to test whether the code passes the tests from
master and the ones that were introduced in the new branch. This
setup helps give clues to the team whether the branch is ready to be merged.
We need more clues, though.
The entire application should be built from a branch and deployed to the cluster. At that point, the application will be running in an environment that is as close to production as possible. The team should run their tests (UI automation, compatibility, etc...) against that version before the PR is merged.
The application still needs to be slightly different from production, though:
- It needs to be created and deleted separately from production
- It is rolled out differently (most likely all at once)
- It needs to have separate configuration from production (so it can't talk to the production DB, for example)
- It has to have a different URL (if it's internet-facing components) from production
- It needs to have different resiliency and redundancy (probably less)
The organizations and applications feature works very well to achieve this PR workflow, and more. When a PR is created,
you would have your CI system deploy to an application called
pr-$PR_NUM under an appropriate tents organization.
For example, if you open up a PR number 1234, your CI might deploy to
After the deploy is done, your team can do whatever testing is necessary on the application. And on each push to the PR, your CI system would redeploy the app.
Then, when the PR is closed, you would have your CI system delete the
myorg/pr-1234 application using
tents delete myorg/pr/1234.