Go to file
Jonathan Boulle dfb5b4fc3a initialize: use correct heuristic to check if etcdenvironment is set
In some circumstances (e.g. nova-agent-watcher) cloudconfig files will
be created where the EtcdEnvironment is an empty map, and hence != nil.
If this is the case we should not do anything at all (because the user
hasn't explicitly asked us to configure etcd). This change standardises
behaviour with the check that we already do for FleetEnvironment.
2014-08-11 16:01:08 -07:00
datasource datasource: Fix ec2 URLs 2014-08-06 21:31:43 -07:00
Documentation doc: escape user.home example 2014-08-01 13:20:44 -07:00
initialize initialize: use correct heuristic to check if etcdenvironment is set 2014-08-11 16:01:08 -07:00
network networkd: Reverse lexicographic order of generated unit files 2014-07-17 20:47:37 -07:00
pkg metadata: Refactor metadata service into ec2 metadata 2014-08-05 17:19:43 -07:00
system system: Add more logging for networkd 2014-07-21 11:25:22 -07:00
third_party add(netlink): import dotcloud/docker/pkg/netlink 2014-06-02 15:31:30 -07:00
units units: update dependencies 2014-06-27 14:29:59 -07:00
.gitignore style(httpbackoff -> pkg): Adjusts package name to follow convention 2014-05-22 14:37:19 -04:00
.travis.yml chore(travis): Adds travis yaml file and badge in README 2014-05-16 17:09:59 -04:00
build style(httpbackoff -> pkg): Adjusts package name to follow convention 2014-05-22 14:37:19 -04:00
CONTRIBUTING.md chore(contributing): clean up CONTRIBUTING.md and split out DCO 2014-04-04 10:40:37 -07:00
coreos-cloudinit_test.go cloudinit: merge cloudconfig info from user-data and meta-data 2014-06-27 23:48:48 -07:00
coreos-cloudinit.go metadata: Refactor metadata service into ec2 metadata 2014-08-05 17:19:43 -07:00
cover feat(tests): add cover script 2014-05-10 01:42:57 -07:00
DCO chore(contributing): clean up CONTRIBUTING.md and split out DCO 2014-04-04 10:40:37 -07:00
LICENSE feat(*): initial commit 2014-01-19 12:25:11 -08:00
NOTICE feat(*): initial commit 2014-01-19 12:25:11 -08:00
README.md chore(travis): Adds travis yaml file and badge in README 2014-05-16 17:09:59 -04:00
test metadata: Refactor metadata service into ec2 metadata 2014-08-05 17:19:43 -07:00

coreos-cloudinit Build Status

coreos-cloudinit enables a user to customize CoreOS machines by providing either a cloud-config document or an executable script through user-data.

Configuration with cloud-config

A subset of the official cloud-config spec is implemented by coreos-cloudinit. Additionally, several CoreOS-specific options have been implemented to support interacting with unit files, bootstrapping etcd clusters, and more. All supported cloud-config parameters are documented here.

The following is an example cloud-config document:

#cloud-config

coreos:
    units:
      - name: etcd.service
        command: start

users:
  - name: core
    passwd: $1$allJZawX$00S5T756I5PGdQga5qhqv1

write_files:
  - path: /etc/resolv.conf
    content: |
        nameserver 192.0.2.2
        nameserver 192.0.2.3

Executing a Script

coreos-cloudinit supports executing user-data as a script instead of parsing it as a cloud-config document. Make sure the first line of your user-data is a shebang and coreos-cloudinit will attempt to execute it:

#!/bin/bash

echo 'Hello, world!'

user-data Field Substitution

coreos-cloudinit will replace the following set of tokens in your user-data with system-generated values.

Token Description
$public_ipv4 Public IPv4 address of machine
$private_ipv4 Private IPv4 address of machine

These values are determined by CoreOS based on the given provider on which your machine is running. Read more about provider-specific functionality in the CoreOS OEM documentation.

For example, submitting the following user-data...

#cloud-config
coreos:
    etcd:
        addr: $public_ipv4:4001
        peer-addr: $private_ipv4:7001

...will result in this cloud-config document being executed:

#cloud-config
coreos:
    etcd:
        addr: 203.0.113.29:4001
        peer-addr: 192.0.2.13:7001