We have a cluster which will migrate to http tls enabled. There are some nodes which have a different migration cycle than rest of the nodes. This means that we need to have BC for services to talk to http endpoint until all the nodes are upgraded.
There is a way in consul and vault to bind to different ports for http and https at the same time. Is there a similar way in nomad to do it?
Hi @gulavanir! No, sorry there’s no way to do this in Nomad. We use the same port for both and do some logic to detect HTTP vs HTTPS on the first byte received.
Thanks @tgross for the response. What is the best way to handle these kind of scenarios then to support backward compatibility? Any recommendation?
The transport security Learn Guide has a section on upgrading an existing cluster, but it looks like it has stale information here:
In a future release Nomad will allow upgrading a cluster to use TLS by allowing servers to accept TLS and non-TLS connections from clients during the migration.
That’s now possible via the rpc_upgrade_mode flag.
Ah. Yeah, sorry no there’s no way to do that for the HTTP port. Keep in mind though that the HTTP port is only used for external API communication – the clients and servers talk over the RPC interface.
That being said, typically the only reason the client needs to care about HTTP(S) is if you have a workload or tool that talks to the Nomad API by making requests to the local client instead of the servers (the client forwards those to the servers via RPC). So if you have a group of clients that can’t be upgraded to HTTPS that’s ok so long as their workloads don’t need to talk to Nomad directly. And if they do need to talk to Nomad, point them at the server addresses instead of their local client and you should be good-to-go.
Yup. We had a slightly different use case where external clients talk to Nomad API through URL requests and the upgrade cycles for the Nomad servers and these external clients is different. Thanks for the details @tgross .