3 navsection: installguide
4 title: InternalURLs and ExternalURL
8 Copyright (C) The Arvados Authors. All rights reserved.
10 SPDX-License-Identifier: CC-BY-SA-3.0
13 The Arvados configuration is stored at @/etc/arvados/config.yml@. See the "Configuration reference":config.html for more detail.
15 The @Services@ section lists a number of Arvados services, each with an @InternalURLs@ and/or @ExternalURL@ configuration key. This document explains the precise meaning of these configuration keys, and how they are used by the Arvados services.
17 The @ExternalURL@ is the address where the service should be reachable by clients, both from inside and from outside the Arvados cluster. Some services do not expose an Arvados API, only Prometheus metrics. In that case, @ExternalURL@ is not used.
19 The keys under @InternalURLs@ are the URLs through which Arvados system components can connect to one another, including the reverse proxy (e.g. Nginx) that fronts Arvados services. The exception is the @Keepstore@ service, where clients on the local network connect directly to @Keepstore.InternalURLs@ (while clients from outside networks connect to @Keepproxy.ExternalURL@). If a service is not fronted by a reverse proxy, e.g. when its endpoint only exposes Prometheus metrics, the intention is that metrics are collected directly from the endpoints defined in @InternalURLs@.
21 Each entry in the @InternalURLs@ section may also indicate a @ListenURL@ to determine the protocol, address/interface, and port where the service process will listen, in case the desired listening address differs from the @InternalURLs@ key itself -- for example, when passing internal traffic through a reverse proxy.
23 If the Arvados service lives behind a reverse proxy (e.g. Nginx), configuring the reverse proxy and the @InternalURLs@ and @ExternalURL@ values must be done in concert.
28 table(table table-bordered table-condensed).
29 |_.Service |_.ExternalURL required? |_.InternalURLs required?|_.InternalURLs must be reachable from other cluster nodes?|_.Note|
30 |railsapi |no |yes|no ^1^|InternalURLs only used by Controller|
31 |controller |yes |yes|yes ^2,4^|InternalURLs used by reverse proxy and container shell connections|
32 |arvados-dispatch-cloud|no |yes|no ^3^|InternalURLs only used to expose Prometheus metrics|
33 |arvados-dispatch-lsf|no |yes|no ^3^|InternalURLs only used to expose Prometheus metrics|
34 |git-ssh |yes |no |no ||
35 |keepproxy |yes |yes|no ^2^|InternalURLs only used by reverse proxy (e.g. Nginx)|
36 |keepstore |no |yes|yes |All clients connect to InternalURLs|
37 |keep-balance |no |yes|no ^3^|InternalURLs only used to expose Prometheus metrics|
38 |keep-web |yes |yes|yes ^5^|InternalURLs used by reverse proxy and container log API|
39 |websocket |yes |yes|no ^2^|InternalURLs only used by reverse proxy (e.g. Nginx)|
40 |workbench2 |yes |no|no ||
43 ^1^ If @Controller@ runs on a different host than @RailsAPI@, the @InternalURLs@ will need to be reachable from the host that runs @Controller@.
44 ^2^ If the reverse proxy (e.g. Nginx) does not run on the same host as the Arvados service it fronts, the @InternalURLs@ will need to be reachable from the host that runs the reverse proxy.
45 ^3^ If the Prometheus metrics are not collected from the same machine that runs the service, the @InternalURLs@ will need to be reachable from the host that collects the metrics.
46 ^4^ If dispatching containers to HPC (Slurm/LSF) and there are multiple @Controller@ services, they must be able to connect to one another using their InternalURLs, otherwise the "tunnel connections":{{site.baseurl}}/architecture/hpc.html enabling "container shell access":{{site.baseurl}}/install/container-shell-access.html will not work.
47 ^5^ All URLs in @Services.WebDAV.InternalURLs@ must be reachable by all Controller services. Alternatively, each entry in @Services.Controller.InternalURLs@ must have a corresponding entry in @Services.WebDAV.InternalURLs@ with the same hostname.
49 When @InternalURLs@ do not need to be reachable from other nodes, it is most secure to use loopback addresses as @InternalURLs@, e.g. @http://127.0.0.1:9005@.
51 It is recommended to use a split-horizon DNS setup where the hostnames specified in @ExternalURL@ resolve to an internal IP address from inside the Arvados cluster, and a publicly routed external IP address when resolved from outside the cluster. This simplifies firewalling and provides optimally efficient traffic routing. In a cloud environment where traffic that flows via public IP addresses is charged, using split horizon DNS can also avoid unnecessary expense.
55 The remainder of this document walks through a number of examples to provide more detail.
59 Consider this section for the @Keep-balance@ service:
61 {% codeblock as yaml %}
64 "http://ip-10-0-1-233.internal:9005/": {}
67 @Keep-balance@ has an API endpoint, but it is only used to expose "Prometheus":https://prometheus.io metrics.
69 There is no @ExternalURL@ key because @Keep-balance@ does not have an Arvados API, no Arvados services need to connect to @Keep-balance@.
71 The value for @InternalURLs@ tells the @Keep-balance@ service to start up and listen on port 9005, if it is started on a host where @ip-10-0-1-233.internal@ resolves to a local IP address. If @Keep-balance@ is started on a machine where the @ip-10-0-1-233.internal@ hostname does not resolve to a local IP address, it would refuse to start up, because it would not be able to find a local IP address to listen on.
73 It is also possible to use IP addresses in @InternalURLs@, for example:
75 {% codeblock as yaml %}
78 "http://127.0.0.1:9005/": {}
81 In this example, @Keep-balance@ would start up and listen on port 9005 at the @127.0.0.1@ IP address. Prometheus would only be able to access the @Keep-balance@ metrics if it could reach that IP and port, e.g. if it runs on the same machine.
83 Finally, it is also possible to listen on all interfaces, for example:
85 {% codeblock as yaml %}
88 "http://0.0.0.0:9005/": {}
91 In this case, @Keep-balance@ will listen on port 9005 on all IP addresses local to the machine.
95 Consider this section for the @Keepstore@ service:
97 {% codeblock as yaml %}
100 "http://keep0.ClusterID.example.com:25107": {}
101 "http://keep1.ClusterID.example.com:25107": {}
104 There is no @ExternalURL@ key because @Keepstore@ is only accessed from inside the Arvados cluster. For access from outside, all traffic goes via @Keepproxy@.
106 When @Keepstore@ is installed on the host where @keep0.ClusterID.example.com@ resolves to a local IP address, it will listen on port 25107 on that IP address. Likewise on the @keep1.ClusterID.example.com@ host. On all other systems, @Keepstore@ will refuse to start.
110 Consider this section for the @Keepproxy@ service:
112 {% codeblock as yaml %}
114 ExternalURL: https://keep.ClusterID.example.com
116 "http://localhost:25107": {}
119 The @ExternalURL@ advertised is @https://keep.ClusterID.example.com@. The @Keepproxy@ service will start up on @localhost@ port 25107, however. This is possible because we also configure Nginx to terminate SSL and sit in front of the @Keepproxy@ service:
121 <notextile><pre><code>upstream keepproxy {
122 server 127.0.0.1:<span class="userinput">25107</span>;
127 server_name <span class="userinput">keep.ClusterID.example.com</span>;
129 proxy_connect_timeout 90s;
130 proxy_read_timeout 300s;
131 proxy_set_header X-Real-IP $remote_addr;
132 proxy_http_version 1.1;
133 proxy_request_buffering off;
134 proxy_max_temp_file_size 0;
136 ssl_certificate <span class="userinput">/YOUR/PATH/TO/cert.pem</span>;
137 ssl_certificate_key <span class="userinput">/YOUR/PATH/TO/cert.key</span>;
139 # Clients need to be able to upload blocks of data up to 64MiB in size.
140 client_max_body_size 64m;
143 proxy_pass http://keepproxy;
146 </code></pre></notextile>
148 If a client connects to the @Keepproxy@ service, it will talk to Nginx which will reverse proxy the traffic to the @Keepproxy@ service.
152 Consider this section for the @RailsAPI@ service:
154 {% codeblock as yaml %}
157 "http://localhost:8004": {}
160 There is no @ExternalURL@ defined because the @RailsAPI@ is not directly accessible and does not need to advertise a URL: all traffic to it flows via @Controller@, which is the only client that talks to it.
162 The @RailsAPI@ service is also a Rails application, and its listening host/port is defined in the Nginx configuration:
164 <notextile><pre><code>
166 # This configures the Arvados API server. It is written using Ruby
167 # on Rails and uses the Passenger application server.
169 listen localhost:8004;
170 server_name localhost-api;
172 root /var/www/arvados-api/current/public;
173 index index.html index.htm index.php;
175 passenger_enabled on;
176 passenger_preload_bundler on;
178 # This value effectively limits the size of API objects users can
179 # create, especially collections. If you change this, you should
180 # also ensure the following settings match it:
181 # * `client_max_body_size` in the previous server section
182 # * `API.MaxRequestSize` in config.yml
183 client_max_body_size 128m;
185 </code></pre></notextile>
187 So then, why is there a need to specify @InternalURLs@ for the @RailsAPI@ service? It is there because this is how the @Controller@ service locates the @RailsAPI@ service it should talk to. Since this connection is internal to the Arvados cluster, @Controller@ uses @InternalURLs@ to find the @RailsAPI@ endpoint.
191 Consider this section for the @Controller@ service:
193 {% codeblock as yaml %}
196 "https://ctrl-0.internal":
197 ListenURL: "http://localhost:8003"
198 ExternalURL: "https://ClusterID.example.com"
201 The @ExternalURL@ advertised to clients is @https://ClusterID.example.com@. The @arvados-controller@ process will listen on @localhost@ port 8003. Other Arvados service processes in the cluster can connect to this specific controller instance, using the URL @https://ctrl-0.internal@. Nginx is configured to sit in front of the @Controller@ service and terminate TLS:
203 <notextile><pre><code>
204 # This is the port where nginx expects to contact arvados-controller.
205 upstream controller {
206 server localhost:8003 fail_timeout=10s;
210 # This configures the public https port that clients will actually connect to,
211 # the request is reverse proxied to the upstream 'controller'
214 server_name ClusterID.example.com ctrl-0.internal;
216 ssl_certificate /YOUR/PATH/TO/cert.pem;
217 ssl_certificate_key /YOUR/PATH/TO/cert.key;
219 # Refer to the comment about this setting in the passenger (arvados
220 # api server) section of your Nginx configuration.
221 client_max_body_size 128m;
224 proxy_pass http://controller;
226 proxy_connect_timeout 90s;
227 proxy_read_timeout 300s;
228 proxy_max_temp_file_size 0;
229 proxy_request_buffering off;
231 proxy_http_version 1.1;
233 proxy_set_header Host $http_host;
234 proxy_set_header Upgrade $http_upgrade;
235 proxy_set_header Connection "upgrade";
236 proxy_set_header X-External-Client $external_client;
237 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
238 proxy_set_header X-Forwarded-Proto https;
239 proxy_set_header X-Real-IP $remote_addr;
242 </code></pre></notextile>
244 If the host part of @ListenURL@ is ambiguous, in the sense that more than one system host is able to listen on that address (e.g., @localhost@), configure each host's startup scripts to set the environment variable @ARVADOS_SERVICE_INTERNAL_URL@ to the @InternalURLs@ key that will reach that host. In the example above, this would be @ARVADOS_SERVICE_INTERNAL_URL=https://ctrl-0.internal@.
246 If the cluster has just a single node running all of the Arvados server processes, configuration can be simplified:
248 {% codeblock as yaml %}
251 "http://localhost:8003": {}
252 ExternalURL: "https://ClusterID.example.com"