I want to use RancherOS for a decently large scale test deployment. For this to not be a very large pain, it would need to be automated. So this is the rundown of what needs to happen:
RancherOS gets installed to disk
It gets a random hostname
It is added to the main Rancher cluster
What would be the best way to do this?
I have tried using an imaging server, but the hostname ends up being the same for all of the instances, and because of that, it can’t connect to the cluster.
If someone could help me out putting together a cloud-config or something else which will help me achieve this, that would be great.
Rancher doesn’t care about the hostname, but there is a state volume (rancher-agent-state)and/or directory (/var/lib/rancher/state) with a uuid for the host. If you added the host before imaging they will all have the same uuid and be the “same” host. Remove them before imaging.
From what I’ve seen, large scale tends to use PXE booting, or some variation on OVF with customised settings in guestinfo.
Customisation gets done using cloud-init files - often served by a scripted web server - which would allow you to set the hostname from there.
Or you can add some startup script / RancherOS service on the imaged system that changes the hostname (and anything else) to make them different
Considering @vincent’s reply - my idea would be to add a some cmdline options to the pxe server that auto-starts rancher agent with the registration token. (I might have time to make something tomorrow)
@vincent that actually solved my problem! I just kept the hostnames the same, on a rancher specific subnet. I added it to the rancher cluster before making an image, so it automatically joins. Much simpler than using ubuntu, which i have been doing until now.
I’m looking for something like this.
If I understood correctly @A_Person you installed rancheros on a VM added it to the rancher server, and then just clone the VM ?
With respect, development on RancherOS has fallen behind quite a bit. My own experiences with it show that it’s has outstanding issues that just aren’t getting addressed until at a minimum Rancher 2.0 comes out, and that release just got pushed back a quarter.
CoreOS/Container Linux and by extension ignition was a serious pain to learn. Particularly because a lot of the documentation references older versions that are incompatible with current ignition schema. It feels like it’s really only made for the people who created it. That said, once you do get your config sorted out its an extremely solid product. Does not have any of the production issues that I was experiencing on RancherOS. Now, I just provision a new server instance, point it at the PXE chain and in less than 5 minutes I have a fully running host provisioned in the rancher hosts panel. It would even be more automated than that, but Rancher 1.6 wants a boot2docker image and doesn’t play nice with trying to do PXE.
There has been a period where there was not much going on with RancherOS because Sven left, but there is work going again now. Rancher 2.0 has not been “pushed back” anywhere. A 2nd preview is due soon and is later than we wanted, but we have always said an actual release would be in (not “by”) Q1 2018, and plan to meet that.
I’m not sure what that has to do with this topic though, but docker-machine hasn’t changed so machine support in 2.0 will be substantially the same. Some docker-machine drivers have an input for an ISO, the driver create a machine from it and must inject the SSH key and provide the IP address so that the rest of bootstrapping can continue running SSH commands to install docker (which is a no-op if your ISO is RancherOS) and run our registration command. It doesn’t have to be an actual boot2docker ISO, that’s just what they call the field.