使用Cloud-Config

时间  2020-01-28
标签 使用 cloud config 栏目 云服务 繁體版
原文   原文链接


文档简单翻译，若有错误请反馈，为方便之后为其它朋友参考！html


CoreOS容许您以声明的方式定制各类操做系统的项目,如网络配置,用户账户,systemd units。
node

本文档描述咱们能够配置项的完整列表.
python

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


这个系统初始化程序所使用的文件称为“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。git

咱们设计咱们的实现容许同一个cloud-config文件在全部支持的平台上工做。github

文件格式

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

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

  • coreosdocker

  • 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文档……

# 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 这样的:

[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文档……

# 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

# 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

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

# 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服务:

# 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

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

主机名

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

# 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从发射台。

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

生成一个密码散列

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

# 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密钥导入用户使用受权服务器的关键。

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

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

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

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

# 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>。

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

# 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。

# cloud-config
manage_etc_hosts: localhost
相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程