Project

General

Profile

Salt Installer Features » History » Version 4

Lucas Di Pentima, 07/03/2024 06:37 PM

1 1 Lucas Di Pentima
h2. Introduction
2
3 2 Lucas Di Pentima
To be able to plan for a new Arvados deployment tool, we need to list all the features our current "salt installer" supports. In broad terms what we call the "salt installer" consists of the following parts:
4 1 Lucas Di Pentima
5
h4. The "arvados-formula" salt formula
6
7
Hosted at https://github.com/arvados/arvados-formula, this code is a group of "salt":https://saltproject.io states & pillars that takes care of installing Arvados packages and setting up the services needed to run a cluster. In this repo there's also the "provision script", meant to enable anyone to use the @arvados-formula@ without needing a full-fledged master+minions salt installation. The provision script installs salt in "masterless mode", and it's mostly useful for the single-host use case, where someone needs a complete Arvados cluster running on a single system, for testing purposes.
8
9
h4. The Terraform code
10
11
For multi-host deployments in the cloud (AWS only at the moment), we wrote a set of Terraform files that manage everything from networking, access control, data storage and service nodes resources to speed up the initial setup and be able to quickly modify it once it's deployed. This code outputs a set of useful data that needs to be fed as input to the installer script described below.
12
13
h4. The "installer.sh" script
14
15
In order to easily use the above in a multi-host (e.g.: production) setting, the installer script takes care of setting up a local git repository that holds the installer files, distributing those files to the hosts that will take part of a deployment, and orchestrating the execution of the provision script on each host, each one with their particular configurations. This script heavily relies on search&replace operations using @sed@ that modify templates that will in turn get applied to salt, so it gets complicated to add features when we need to manage 2 level of templating.
16
17
h2. Detailed list of features
18
19
Below is the list of functionality that every part of the installer provides. We aim to list everything that'll be likely needed to be implemented in the new version of the tool. The list of features is written in the order an operator currently handles.
20
21
h3. Terraform deployment
22
23
As suggested in the book "Terraform: Up & Running":https://www.oreilly.com/library/view/terraform-up-and/9781098116736/, the terraform code is explicitly split in several sections to limit the "blast radius" of a potential mistake. The below sections are applied in the described order to build the complete cloud infrastructure needed to install Arvados.
24
25
h4. Networking layer
26
27
# Allows the operator to deploy new or use existing network resources, like VPC, security group & subnets.
28
# Creates an S3 endpoint and route so that keepstore nodes have direct access.
29
# Sets up Internet and NAT gateways to give nodes outbound network access.
30
# Sets up the security group that allows communication between nodes in the VPC, and also inbound SSH & HTTP(S) access.
31
# Manages Route53 domain names from a customizable list of hosts, with an optional split-horizon configuration.
32
# Creates credentials for Let's Encrypt to be able to work with Route53 from the service nodes.
33
# Optionally creates Elastic IP resources for user-facing hosts (controller, workbench).
34
35
h4. Data layer
36
37
# Creates the S3 bucket needed for Keep blocks storage.
38
# Creates keepstore & compute node roles with policies that grants S3 access to the created bucket.
39
40
h4. Service layer
41
42
# Optionally creates an RDS instance as the database service with a sensible set of default values that can be customized.
43
# Creates an AWS secret to hold the TLS certificate private key's decrypting password (for cases where the TLS certificate is provided by the user).
44
# Creates policy and instance profiles so that every service node has access to the above secret.
45
# Creates a policy that gives permissions to compute nodes so that EBS-autoscale filesystems work.
46
# Creates policy, role & instance profile so that the dispatcher node can do its work (launching EC2 instances, listing them, etc.)
47
# Creates the service nodes from the list of hosts names defined in the networking layer, assigning the public IP addresses to the nodes that need them.
48
49 4 Lucas Di Pentima
h3. Installer script
50 3 Lucas Di Pentima
51
The @installer.sh@ script provides a handful of useful features, some of which will be needed in some form on the new tool as they are not aimed to mitigate salt shortcomings but necessary in some or all styles of deployments.
52 1 Lucas Di Pentima
53 4 Lucas Di Pentima
# *Selective deployment:* Sometimes doing a quick update on a single node is enough.
54
# *Deployment ordering:* when doing a full deploy run, some nodes need to be updated before others, the current ordering scheme is:
55
## Database node
56
## Controller node(s): To be able to perform rolling updates on balanced controllers deployments, it removes the controller node about to be updated from the balancer's pool on each iteration.
57
## Balancer node (if exists)
58
## Everything else
59
# *Optional use of a jump host:* In some situations, using a reachable jump host is needed for the installer to be able to connect to internal cluster nodes like the database, shell or even keepstore. This will depend on whether the installer is run from the same network as the cluster or from the outside.
60
# *Secret vs Non-secret configuration handling:* Secret config data include cluster's default admin account password, database credentials, dispatcher's private SSH key, etc. These need to be separate from the rest of the configuration parameters so that they can be placed on secure storages if needed.
61
# *General sanity checks:* The installer script does some checks previous to a deploy run, like:
62
## Node connectivity and SSH access.
63
## TLS certificate existence when not using Let's Encrypt
64
# *Cluster Diagnostics test launching:* To confirm everything is working correctly, it runs @arvados-client diagnostics@ from the local host or the shell node.
65 3 Lucas Di Pentima
66 1 Lucas Di Pentima
h3. Salt installer
67
68
The Terraform's output data (vpc and subnet ids, various credentials, Route53 domain name servers, etc) gets used by the installer and provision scripts to install & configure the necessary software on each host.
69
70
There's a "node-to-roles" mapping that is declared as part of the provision script's configuration, each of them described below.
71
72
h4. 'database' role
73
74
Can be overridden to use an external database service (like AWS RDS)
75
76
* Installs a PostgreSQL database server.
77
* Configures PG user & database for Arvados, enabling the @pg_trgm@ extension.
78
* Configures PG server ACLs to allow access from localhost, websocket, keepbalance and controller nodes.
79
* Installs Prometheus node and PG exporters.
80
81
h4. 'controller' role
82
83
* Installs @nginx@, @passenger@ and PG client libraries.
84
** If in "balanced mode", only set up HTTP nginx, as the balancer will act as the TLS termination proxy.
85
* From the @arvados.controller@ & @arvados.api@ formula states
86
** Install rvm if required -- this won't be necessary anymore as we'll be using the distro's provided ruby packages.
87
** Installs @arvados-api-server@, @arvados-controller@
88
** Runs the services and waits up to 2 minutes for the controller service to answer requests, so that Arvados resource creation work in future stages.
89
* If using an external database service, it makes sure the @pg_trgm" extension is enabled.
90
* Sets up @logrotate@ to rotate the RailsAPI's logs daily, keeping the last year of logs. This is because these files are not inside @/var/log/@
91
92
h4. 'monitoring' role
93
94
* Installs & configures Nginx, Prometheus, Node exporter, Blackbox exporter and Grafana.
95
* Nginx configuration details
96
** Sets up basic authentication for the prometheus website (as it doesn't seem to provide its own access controls)
97
** Sets up custom TLS certs or installs Let's Encrypt to manage them, depending on configuration.
98
* Prometheus configuration details
99
** Sets configurable data retention period
100
** Correctly configures multiple controller nodes in balanced configurations.
101
* Grafana configuration details
102
** Sets up admin user & password with @grafana-cli@
103
** Installs custom dashboards
104
105
h4. 'balancer' role
106
107
* Installs Nginx with a round-robin balanced upstream configuration.
108
* Sets up custom TLS certs or installs Let's Encrypt to manage them, depending on configuration.
109
110
h4. 'workbench/workbench2' role
111
112
* From @arvados.workbench2@ formula state
113
** Installs @arvados-workbench2@ package
114
* Installs & configures nginx
115
* Sets up custom TLS certs or installs Let's Encrypt to manage them, depending on configuration.
116
* Uninstalls workbench1 -- this might not be needed in future versions.
117
118
h4. 'webshell' role
119
120
* Installs an nginx virtualhost that uses the shell node's @shellinabox@ service as the upstream.
121
* Sets up custom TLS certs or installs Let's Encrypt to manage them, depending on configuration.
122
123
h4. 'keepproxy' role
124
125
* From @arvados.keepproxy@ formula state
126
** Installs @arvados-keepproxy@ and runs the service
127
* Installs & configures nginx
128
** Sets up custom TLS certs or installs Let's Encrypt to manage them, depending on configuration.
129
130
h4. 'keepweb' role
131
132
* From @arvados.keepweb@ formula state
133
** Installs @keep-web@ and runs the service
134
* Installs & configures nginx
135
** Sets up nginx's "download" and "collections" virtualhosts
136
** Sets up custom TLS certs or installs Let's Encrypt to manage them, depending on configuration.
137
138
h4. 'websocket' role
139
140
* From @arvados.websocket@ formula state
141
** Installs @arvados-ws@ and runs the service
142
* Installs & configures nginx
143
** Sets up custom TLS certs or installs Let's Encrypt to manage them, depending on configuration.
144
145
h4. ' dispatcher' role
146
147
* From @arvados.dispatcher@ formula state
148
** Installs @arvados-dispatch-cloud@ and runs the service
149
150
h4. 'keepbalance' role
151
152
* From @arvados.keepbalance@ formula state
153
** Installs the @keep-balance@ package and runs the service
154
155
h4. 'keepstore' role
156
157
* From @arvados.keepstore@ formula state
158
** Installs @keepstore@ and runs the service
159
160
h4. 'shell' role
161
162
* Installs @docker@
163
* Installs @sudo@, configures it to allow password-less access to "sudo" group members.
164
* From @arvados.shell@ formula state
165
** Installs @jq@, @arvados-login-sync@, @arvados-client@, @arvados-src@, @libpam-arvados-go@, @python3-arvados-fuse@, @python3-arvados-python-client@, @python3-arvados-cwl-runner@, @python3-crunchstat-summary@ and @shellinabox@
166
** Installs gems: @arvados-cli@, @arvados-login-sync@
167
** Creates a Virtual Machine record for the shell node and sets a scoped 'login' token for it.
168
* Queries the API server for the created virtual machine with the same name as its hostname, and configures cron to run arvados-login-sync with the necessary credentials.
169
170
h4. Default role mapping
171
172
By default the installer deployes a 4-node cluster with only 2 of them needing public IP addresses (in case of a publicly accessible cluster)
173
* Controller node: database & controller roles
174
* Workbench node: monitoring, workbench, workbench2, webshell, keepproxy, keepweb, websocket, dispatcher and keepbalance roles
175
* Keep0 node: keepstore role
176
* Shell node: shell role