Menu
I'm currently dealing with CoreOS, and so far I think I got the overall idea and concept. One thing that I did not yet get is execution of cloud-init.
I understand that cloud-init is a process that does some configuration for CoreOS. What I do not yet understand is…
cloud-init? On first boot? On each boot? …?cloud-init know where to find its configuration data? I've seen that there is config-drive and that totally makes sense, but is this the only way? What exactly is the role of the user-data file? …?
564
So cloud-init will retrieve your user-data from an attached ISO image (from a file named user-data. txt ). When cloud-init runs, it will typically populate /var/lib/cloud-init/instance with any information retrieved from the cloud provider, so you should find a copy of the user data in that directory.
You can check the /var/lib/cloud/data/status. json for cloud-init status. Or if the host is using upstart, add one init process in /etc/init/newprocess. conf and newprocess.
How Does cloud-init Work? Cloud-init is a service that sets up your VM instance with the wanted configuration and software ready to use. The service starts at boot and uses the metadata provided by the cloud provider or the direct user. It does so by executing scripts, most commonly from the cloud-config file.
By default, cloud-init attempts to determine which case it is running in by checking the instance ID in the cache against the instance ID it determines at runtime. If they do not match, then this is an instance's first boot; otherwise, it's a subsequent boot.
CoreOS runs cloudinit a few times during the boot process. Right now this happens at each boot, but that functionality may change in the future.
The first pass is the OEM cloud-init, which is baked into the image to set up networking and other features required for that provider. This is done for EC2, Rackspace, Google Compute Engine, etc since they all have different requirements. You can see these files on Github.
The second pass is the user-data pass, which is handled differently per provider. For example, EC2 allows the user to input free-form text in their UI, which is stored in their metadata service. The EC2 OEM has a unit that reads this metadata and passes it to the second cloud-init run. On Rackspace/Openstack, config-drive is used to mount a read-only filesystem that contains the user-data. The Rackspace and Openstack OEMs know to mount and look for the user-data file at that location.
The latest version of CoreOS also has a flag to fetch a remote file to be evaluated for use with PXE booting.
The CoreOS distribution docs have a few more details as well.
54
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
