4

The way I am currently running a CoreOS cluster in a VMWare ESXi environment has been to use an ISO mounted in vCenter as described by this blog post...

http://www.chrismoos.com/2014/05/28/coreos-with-cloud-config-on-vmware-esxi

However with that particular VMWare environment, I have to explicitly define my assigned IP address into a /etc/systemd/network/static.network service in the cloud config in a few places... so I have to create an ISO file for each CoreOS machine I want to run. This seems fine, but does not scale... and sometimes the IT admins unmount the ISO drive unintentionally.

The OEM distribution documentation (here) says that you can define a /usr/share/oem/cloud-config.yml file and that you should be able to "create additional units that process user-provided metadata, as described below."

Then the process for EC2 and Rackspace is illuminated, and the explanation just points you to their baked in code in CoreOS.

What I would like to do is create a CoreOS unit that pulls a cloud-config file via HTTP with a simple URL...something like http://server-ip/cloud-configs/specific-hostname and pull the YAML file from there at boot...

This would solve two issues: I wouldn't have to provide a separate ISO for each CoreOS machine and I wouldn't have to have the VMWare admins consistently managing an ISO for each CoreOS machine.

The docs are not really clear on the best way to accomplish that. It seems like Amazon/Rackspace works because they have code inside the OS. How does Joe Schmoe provide dynamic cloud config data outside of mounting an ISO?

The big disconnect is that I can write a unit that fetches the file via wget/curl (whatever is available) but how do I tell CoreOS to process the YAML after I've fetched it?

azurewraith
  • 161
  • 1
  • 4

1 Answers1

2

So, I probably should have rummaged through some of the other cloud providers... like there is this 'exoscale' provider which provides a bash script and a unit to fire off that bash script...

  - name: exoscale-cloudinit.service
    command: restart
    runtime: yes
    content: |
      [Unit]
      Description=Cloudinit from exoscale (cloudstack-style) metadata
      Requires=coreos-setup-environment.service
      After=coreos-setup-environment.service

      [Service]
      Type=oneshot
      EnvironmentFile=/etc/environment
      ExecStart=/usr/share/oem/bin/exoscale-coreos-cloudinit

...and the method of getting CoreOS to parse a cloud-config via URL...

#!/bin/bash

. /usr/share/oem/bin/exoscale-dhcp

DHCP_SERVER=$(get_dhcp_ip)
USERDATA_URL="http://${DHCP_SERVER}/latest/user-data"

block-until-url "${USERDATA_URL}"
coreos-cloudinit --from-url="${USERDATA_URL}"

...but now I have a bit of a chicken/egg problem unless I have some method of getting a temporary IP address to perform the curl operation...

azurewraith
  • 161
  • 1
  • 4
  • In theory, DHCP is what gives you the IP and you go from there.You could, again in theory, use link local addresses to talk to a server. – Randall Smith Oct 09 '14 at 19:46
  • Agreed, I just can not remember if the allocated DHCP address/subnet allowed access to the part of the network where the user-data server would be... – azurewraith Oct 09 '14 at 21:08
  • @azurewraith have you blogged about this? I'm looking to do the same thing and getting really stuck – xddsg May 29 '15 at 15:29
  • I was successful in getting my cloud-config to work, it ended up being very similar to the above snippets, the complicated part is making sure you are connected to the network at the point of executing `coreos-cloudinit --from-url` – azurewraith May 29 '15 at 19:00
  • One thing I forgot to mention -- if using VMWare / vSphere this article has some automation that can be applied during virtual machine creation: http://www.virtuallyghetto.com/2014/11/how-to-quickly-deploy-new-coreos-image-wvmware-tools-on-esxi.html – azurewraith Jun 01 '15 at 20:49