1
1
# Architecture
2
2
3
- This document provides a high level overview of Coder's architecture.
3
+ The Coder deployment model is flexible and offers various components that
4
+ platform administrators can deploy and scale depending on their use case. This
5
+ page describes possible deployments, challenges, and risks associated with them.
4
6
5
- ## Single region architecture
7
+ Learn more about our [ Reference Architectures] ( ../admin/architectures/index.md )
8
+ and platform scaling capabilities.
6
9
7
- ![ Architecture Diagram] ( ../images/architecture-single-region.png )
8
-
9
- ## Multi-region architecture
10
+ ## Primary components
10
11
11
- ![ Architecture Diagram ] ( ../images/architecture-multi-region.png )
12
+ ### coderd
12
13
13
- ## coderd
14
-
15
- coderd is the service created by running ` coder server ` . It is a thin API that
16
- connects workspaces, provisioners and users. coderd stores its state in Postgres
17
- and is the only service that communicates with Postgres.
14
+ _ coderd_ is the service created by running ` coder server ` . It is a thin API that
15
+ connects workspaces, provisioners and users. _ coderd_ stores its state in
16
+ Postgres and is the only service that communicates with Postgres.
18
17
19
18
It offers:
20
19
21
20
- Dashboard (UI)
22
21
- HTTP API
23
22
- Dev URLs (HTTP reverse proxy to workspaces)
24
- - Workspace Web Applications (e.g easily access code-server)
23
+ - Workspace Web Applications (e.g for easy access to ` code-server ` )
25
24
- Agent registration
26
25
27
- ## provisionerd
26
+ ### provisionerd
28
27
29
- provisionerd is the execution context for infrastructure modifying providers. At
30
- the moment, the only provider is Terraform (running ` terraform ` ).
28
+ _ provisionerd _ is the execution context for infrastructure modifying providers.
29
+ At the moment, the only provider is Terraform (running ` terraform ` ).
31
30
32
31
By default, the Coder server runs multiple provisioner daemons.
33
32
[ External provisioners] ( ../admin/provisioners.md ) can be added for security or
34
33
scalability purposes.
35
34
36
- ## Agents
35
+ ### Agents
37
36
38
37
An agent is the Coder service that runs within a user's remote workspace. It
39
38
provides a consistent interface for coderd and clients to communicate with
@@ -50,9 +49,9 @@ Templates are responsible for
50
49
[ creating and running agents] ( ../templates/index.md#coder-agent ) within
51
50
workspaces.
52
51
53
- ## Service Bundling
52
+ ### Service Bundling
54
53
55
- While coderd and Postgres can be orchestrated independently, our default
54
+ While _ coderd _ and Postgres can be orchestrated independently, our default
56
55
installation paths bundle them all together into one system service. It's
57
56
perfectly fine to run a production deployment this way, but there are certain
58
57
situations that necessitate decomposition:
@@ -61,7 +60,7 @@ situations that necessitate decomposition:
61
60
- Achieving greater availability and efficiency (horizontally scale individual
62
61
services)
63
62
64
- ## Workspaces
63
+ ### Workspaces
65
64
66
65
At the highest level, a workspace is a set of cloud resources. These resources
67
66
can be VMs, Kubernetes clusters, storage buckets, or whatever else Terraform
@@ -72,3 +71,94 @@ while those that don't are called _peripheral resources_.
72
71
73
72
Each resource may also be _ persistent_ or _ ephemeral_ depending on whether
74
73
they're destroyed on workspace stop.
74
+
75
+ ## Deployment models
76
+
77
+ ### Single region architecture
78
+
79
+ ![ Architecture Diagram] ( ../images/architecture-single-region.png )
80
+
81
+ #### Components
82
+
83
+ This architecture consists of a single load balancer, several _ coderd_ replicas,
84
+ and _ Coder workspaces_ deployed in the same region.
85
+
86
+ ##### Workload resources
87
+
88
+ - Deploy at least one _ coderd_ replica per availability zone with _ coderd_
89
+ instances and provisioners. High availability is recommended but not essential
90
+ for small deployments.
91
+ - Single replica deployment is a special case that can address a
92
+ tiny/small/proof-of-concept installation on a single virtual machine. If you
93
+ are serving more than 100 users/workspaces, you should add more replicas.
94
+
95
+ ** Coder workspace**
96
+
97
+ - For small deployments consider a lightweight workspace runtime like the
98
+ [ Sysbox] ( https://github.com/nestybox/sysbox ) container runtime. Learn more how
99
+ to enable
100
+ [ docker-in-docker using Sysbox] ( https://asciinema.org/a/kkTmOxl8DhEZiM2fLZNFlYzbo?speed=2 ) .
101
+
102
+ ** HA Database**
103
+
104
+ - Monitor node status and resource utilization metrics.
105
+ - Implement robust backup and disaster recovery strategies to protect against
106
+ data loss.
107
+
108
+ ##### Workload supporting resources
109
+
110
+ ** Load balancer**
111
+
112
+ - Distributes and load balances traffic from agents and clients to _ Coder
113
+ Server_ replicas across availability zones.
114
+ - Layer 7 load balancing. The load balancer can decrypt SSL traffic, and
115
+ re-encrypt using an internal certificate.
116
+ - Session persistence (sticky sessions) can be disabled as _ coderd_ instances
117
+ are stateless.
118
+ - WebSocket and long-lived connections must be supported.
119
+
120
+ ** Single sign-on**
121
+
122
+ - Integrate with existing Single Sign-On (SSO) solutions used within the
123
+ organization via the supported OAuth 2.0 or OpenID Connect standards.
124
+ - Learn more about [ Authentication in Coder] ( ../admin/auth.md ) .
125
+
126
+ ### Multi-region architecture
127
+
128
+ ![ Architecture Diagram] ( ../images/architecture-multi-region.png )
129
+
130
+ #### Components
131
+
132
+ This architecture is for globally distributed developer teams using Coder
133
+ workspaces on daily basis. It features a single load balancer with regionally
134
+ deployed _ Workspace Proxies_ , several _ coderd_ replicas, and _ Coder workspaces_
135
+ provisioned in different regions.
136
+
137
+ Note: The _ multi-region architecture_ assumes the same deployment principles as
138
+ the _ single region architecture_ , but it extends them to multi region deployment
139
+ with workspace proxies. Proxies are deployed in regions closest to developers to
140
+ offer the fastest developer experience.
141
+
142
+ ##### Workload resources
143
+
144
+ ** Workspace proxy**
145
+
146
+ - Workspace proxy offers developers the option to establish a fast relay
147
+ connection when accessing their workspace via SSH, a workspace application, or
148
+ port forwarding.
149
+ - Dashboard connections, API calls (e.g. _ list workspaces_ ) are not served over
150
+ proxies.
151
+ - Proxies do not establish connections to the database.
152
+ - Proxy instances do not share authentication tokens between one another.
153
+
154
+ ##### Workload supporting resources
155
+
156
+ ** Proxy load balancer**
157
+
158
+ - Distributes and load balances workspace relay traffic in a single region
159
+ across availability zones.
160
+ - Layer 7 load balancing. The load balancer can decrypt SSL traffic, and
161
+ re-encrypt using internal certificate.
162
+ - Session persistence (sticky sessions) can be disabled as _ coderd_ instances
163
+ are stateless.
164
+ - WebSocket and long-lived connections must be supported.
0 commit comments