使用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文檔……

# 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