使用Cloud-Config

CoreOS允许您以声明的方式定制各种操作系统的项目,如网络配置,用户帐户,systemd units。 

本文档描述我们可以配置项的完整列表.


coreos-cloudinit程序使用这些文件,操作系统在启动或运行时，都会加载cloud-config配置文件。

这个系统初始化程序所使用的文件称为“cloud-config”文件。 它是由cloud-init项目的cloud-config配置文件。 这是“事实上的multi-distribution包处理早期cloud instance的初始化”(cloud-init docs)。 因为cloud-init项目包括CoreOS使用的工具,而没有使用相关的子集的配置项，将在我们cloud-config文件执行。 除了这些,我们添加了一些CoreOS-specific项,如etcd configuration,OEM definition,和systemd units。

我们设计我们的实现允许同一个cloud-config文件在所有支持的平台上工作。

文件格式

cloud-config文件使用YAML文件格式,它使用空格和new-lines分隔列表,关联数组,和values。

cloud-config文件应该包含#cloud-config,紧随其后的是一个关联数组,零个或更多的下列键:

• coreos

• ssh_authorized_keys

• hostname

• users

• write_files

• manage_etc_hosts

这些键的预期值定义在本文档的其余部分。

提供Cloud-Config Config-Drive

CoreOS试图符合每个平台的本机方法提供用户数据。 每一个云提供商往往是独一无二的,但是这种复杂性被CoreOS抽象。 您可以查看每个平台的文档页面的指示。 提供cloud-config最普遍方法via config-drive高度只读设备机器,包含您的cloud-config文件。

配置参数

coreos

etcd

coreos.etcd.*参数将翻译部分systemd unit作为etcd configuration文件。如果平台环境支持的模板特征coreos-cloudinit可以自动化etcd 配置（configuration）;$private_ipv4和$public_ipv4字段。例如,下面的cloud-config文档……

1 2 3 4 5 6 7 8

# cloud-configcoreos:      etcd:          name: node001      #产生一个新的令牌为每一个独特的集群从https://discovery.etcd.io/new          discovery: https: //discovery .etcd.io/<token>      # multi-region和多重云部署需要使用$public_ipv4          addr: $public_ipv4:4001          peer-addr: $private_ipv4:7001

… 将生成一个systemd unit 这样的:

1 2 3 4 5

[Service] Environment= "ETCD_NAME=node001" Environment="ETCD_DISCOVERY= Environment= "ETCD_ADDR=203.0.113.29:4001" Environment= "ETCD_PEER_ADDR=192.0.2.13:7001"

关于可用的配置参数的更多信息,请参阅etcd documentation。 请注意,在coreos.etcd.*keys映射到下划线。

注意:$private_ipv4和$public_ipv4替换变量中引用其他文件只支持在Amazon EC2上,谷歌计算引擎,OpenStack,Rackspace和Vagrant的。

fleet

coreos.fleet.*参数的工作非常类似coreos.etcd.*的配置,让fleet通过环境变量.例如,下面的cloud-config文档……

1 2 3 4

# cloud-configcoreos:      fleet:          public-ip: $public_ipv4          metadata: region= us-west

… 将生成一个systemd单位救助这样的:

[Service]
Environment="FLEET_PUBLIC_IP=203.0.113.29"
Environment="FLEET_METADATA=region=us-west"

有关fleet配置的更多信息,请参阅fleet documentation。

update

coreos.update.*参数操作设置相关CoreOS实例是如何更新的。

这些字段将被写入和替换/etc/coreos/update.conf。如果只有一个参数只会覆盖给定的字段.reboot-strategy参数也会影响的行为locksmith。

• reboot-strategy:"reboot","etcd-lock","best-efort"或"off"控制,当重新启动执行更新后发布。

  • reboot:重启后立即更新。

  • etcd-lock:重启后第一次在etcd distributed blck ,这可以保证只有一个主机将同时启动,集群将保持在更新期间可用。

  • best-effort——如果etcd正在运行,“etcd-lock”,否则只是“重启”。

  • off——禁用后重新启动更新应用(不推荐)。

• server:omaha端点URL将查询更新。

• group:表示应该用于自动更新的通道。这个值默认为形象最初的版本下载。(“master”,“阿尔法”、“beta”、“stable”)

注意:cloudinit只会操纵 locksmith systemd unit 文件运行时目录(/run/systemd/system/locksmithd.service)。 如果任何手动修改一个覆盖 unit 配置文件(如。/etc/systemd/system/locksmithd.service),cloudinit将不再能够控制locksmith service unit。

example

1 2 3

# cloud-configcoreos:    update:      reboot-strategy: etcd-lock

units

coreos.units.*参数定义的列表任意systemd units启动后开始。这个功能旨在帮助你开始基本服务需要挂载存储和配置网络为了加入CoreOS集群。这并不是一个Chef/Puppet替代。

每个条目是一个对象有以下字段:

• name:字符串代表单位的名字。必需的。

• runtime:布尔指示是否在重新引导时持久化单元。这是类似于--runtime参数systemctl enable。 默认值是false。

• enable:布尔指示是否要处理的(安装)部分单位文件。 这类似于跑步systemctl enable <name>。 默认值是false。

• content:纯文本字符串代表整个单元文件。 如果没有提供任何值,单位假定已经存在。

• command:命令执行单位:start、stop、,reboot,try-restart,reload-or-restart reload-or-try-restart。 默认值是reboot。

• mask:是否屏蔽单元文件的符号链接/dev/null(类似于systemctl mask <name>)。 请注意,不像systemctl mask,这将破坏地删除任何现有单元文件位于/etc/systemd/system/<unit>,以确保面具成功。 默认值是false。

注意:为所有网络命令字段被忽略,netdev,和链接单元。 systemd-networkd。 服务单位将重新启动。e

example

编写一个单元到磁盘,自动启动它。

1 2 3 4 5 6 7 8 9 10 11 12 13 14

# cloud-configcoreos:      units :         - name: docker-redis.service          command : start          content: |            [Unit]            Description= Redis container            Author=Me            After=docker.service              [Service]            Restart=always            ExecStart= /usr/bin/docker  start -a redis_server            ExecStop= /usr/bin/docker  stop - t 2 redis_server

启动内置的etcd和fleet服务:

1 2 3 4 5 6

# cloud-configcoreos:      units :        - name: etcd.service          command : start        - name: fleet.service          command : start

ssh_authorized_keys

ssh_authorized_keys参数添加公共SSH密钥将被授权的core用户。

键将被命名为“coreos-cloudinit”默认情况下。覆盖这个使用--ssh-key-nameflag在调用coreos-cloudinit

1 2	# cloud-configssh_authorized_keys:    -  ssh -rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC0g+ZTxC7weoIJLUafOgrm+h……

主机名

的hostname参数定义了系统的主机名。这是当地的FQDN名(即的一部分foo在foo.example.com

1 2	# cloud-config hostname : coreos1

用户

users参数添加或修改指定的用户列表。每个用户是一个对象,包含以下字段。字符串类型的每个字段是可选的,除非另有注明。所有,但passwd和ssh-authorized-keys如果用户已经存在字段将被忽略。

• name:必须的。用户登录名

• gecos:GECOS评论的用户

• passwd:哈希密码用于该用户

• homedir:用户的主目录。默认为/home/<name>

• no-create-home:布尔。跳过主目录的创建。

• primary-group:为用户默认组。默认为创建一个新组命名的用户。

• 组:将用户添加到这些额外的组

• no-user-group:布尔。跳过默认组的创建。

• ssh-authorized-keys:此用户的公共SSH密钥授权列表

• coreos-ssh-import-github:从Github用户授权SSH密钥

• coreos-ssh-import-url:从一个url端点进口授权SSH密钥。

• 系统:创建用户作为一个系统用户。没有主目录将被创建。

• no-log-init:布尔。 跳过初始化lastlog和faillog数据库。

以下字段尚未实现:

• inactive:停用用户在创建

• lock-passwd:布尔。禁用密码登录的用户

• sudo:进入添加/etc/sudoers用户。 默认情况下,没有sudo访问授权。

• selinux-user:相应的SELinux用户

• ssh-import-id:进口SSH密钥ID从发射台。

1 2 3 4 5 6 7 8

# cloud-config用户:    - name: elory      passwd : $6$5s2u6 /un0AvWnqilcgaNB3Mkxd5yYv6mTlWfOoCYHZmfi3LDKVltj .E8XNKEcwWm$……      groups :        -  sudo        - docker      ssh -authorized-keys:        -  ssh -rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC0g+ZTxC7weoIJLUafOgrm+h……

生成一个密码散列

如果您选择使用一个密码,而不是一个SSH密钥,生成一个安全散列系统的安全是非常重要的。简化散列像md5crypt微不足道的裂纹在现代GPU硬件。这里有一些方法来生成安全散列:

1 2 3 4 5 6 7 8 9 10 11

# On Debian/Ubuntu (via the package "whois") mkpasswd --method=SHA-512 --rounds=4096   # OpenSSL (note: this will only make md5crypt.  While better than plantext it should not be considered fully secure) openssl  passwd  -1   # Python (change password and salt values) python -c  "import crypt, getpass, pwd; print crypt.crypt('password', '\$6\$SALT\$')"   # Perl (change password and salt values) perl -e  'print crypt("password","\$6\$SALT\$") . "\n"'

使用更多的轮将帮助创造更安全的密码,但考虑到足够的时间,密码散列可以逆转。 在大多数基于RPM的发行版有一种工具叫mkpasswd中可用expect包,但这并不处理“轮”也不先进的散列算法。

检索SSH密钥授权

从GitHub的用户

使用coreos-ssh-import-github领域,我们可以从GitHub公共SSH密钥导入用户使用授权服务器的关键。

1 2 3 4

# cloud-config users :    - name: elroy      coreos- ssh - import -github: 埃尔罗伊

从HTTP端点

我们也可以把公共SSH密钥从匹配的HTTP端点GitHub的API响应格式。 例如,如果你有一个GitHub的安装企业,您可以提供一个完整的URL和一个身份验证标记:

1 2 3

# cloud-config用户:    - name: elroy      coreos- ssh - import -url: https: //github-enterprise .example.com /api/v3/users/elroy/keys ?access_token= <标记>

您还可以指定任何URL的响应匹配公钥的JSON格式:

1 2 3 4

# cloud-config users :    - name: elroy      coreos- ssh - import -url: https: //example .com /public-keys

write_files

的write-file参数定义了创建在本地文件系统的文件列表。 每个文件都被表示为一个关联数组,以下键:

• path:绝对位置在磁盘内容应该写

• content:数据写在提供path

• permissions:字符串表示八进制表示法(即文件权限。“0644”)

• owner:用户和组,应该拥有文件写入磁盘。这是相当于<user>:<group>参数chown <user>:<group> <path>。

明确没有实现编码属性。 的内容字段必须代表什么应该被写入磁盘。

1 2 3 4 5 6 7

# cloud-config write_files: - path:  /etc/fleet/fleet .conf      permissions: 0644      content: |        verbosity= 1        metadata="region=us-west, type =ssd”

manage_etc_hosts

manage_etc_hosts参数配置的内容/etc/hosts文件,该文件用于本地名称解析。目前,仅支持值是“localhost”,这将导致您的系统的主机名 解决“127.0.0.1”。这是有用的,当主机没有DNS 基础设施来解决自己的主机名,例如,当使用的Vagrant。

1 2	# cloud-config manage_etc_hosts: localhost