What’s the reason why we must prepare a host with Docker and paste a command? Rancher could as well SSH into the server and make the necessary installation via script. We have a custom solution which does this very reliably, and it’s less work, as providers typically provision new machines and I could just paste the same SSH key into Rancher as well.
That is what “node drivers” do for specific clouds/providers. Custom is for running on arbitrary existing machines.
1.x had a registration command like this and it worked well. Earlier 2.0 alphas had an add host by SSH option and it is a poor experience all around.
-
The node has to have an IP and firewall rules allowing the server to open a connection to it. The registration command/agent works the opposite, agent connects to server. Outbound is more likely to be open, and works in situations where the nodes are on a private network that the server has no access to.
-
You have to get 3 pieces of information right (ip, user, ssh key). If any one of them is wrong, you can’t connect and we can’t tell you much about why (the key could be wrong, the key is valid but for a different user, it’s the wrong IP entirely but some other machine is responding)
-
None of the info can be validated in advance, so a record has to be created for the node in the hopes that it someday calls in and is then associated to it.
-
If you do manage to connect, you’re on an arbitrary machine with arbitrary version of arbitrary OS installed, which may or may not have arbitrary version of Docker installed. The installed version may or not be supported, and upgrading may or may not break things. So you probably want to prompt for some info or confirm before doing destructive things, but you can’t because nothing about this is interactive.
-
Some cloud providers change IPs of VMs on reboot, so the node falls off the face of the earth because the server has no way to know the new IP.
So this was intentionally removed. If you just want to list out a bunch of machines and make them a cluster via SSH, RKE does just that.
You can run the registration command in a script in your custom solution. The command shown in the UI can be used many times, it’s not tied for registering a single new node.
For small/test setups copying the registration command is ok, but for any serious size infrastructure automation is clearly the way to go, and in a Prod environment hands-free is more typically an absolute red-line (outside of a ‘break the glass process’). So I agree with Vincent, there is a fair bit of external setup that has to be in place before registering Rancher hosts.
That said, it’s pretty straightforward to create infrastructure-as-code these days with your preferred config mgmt tooling. Personally I find Terraform to be the most feature rich as well as having a relatively short learning curve because the abstractions are so well factored. There is also a Rancher specific provider which allows management of the primary Rancher v1.x constructs including ‘environment’ which returns the registration command and/or token (you can also of course simply use the Rancher API or CLI to grab that info and execute it). That provider is not suitable for Rancher v2 so for now you will likely have to use the APIs, but as I understand it, Rancher will update the Terraform provider at some point since (from my networking experience) plenty of customers use it.