DevOps專題|Packer使用教程

什麼是Packer

簡單介紹一下本身

Packer 是一個輕量命令行工具, 能在幾乎全部主流的操做系統上運行。

在給定一份配置文件的狀況下, Packer 能爲多種系統架構建立雲主機鏡像。同時 Packer 自身也可以作到多鏡像併發建立, 大大節省了鏡像建立過程當中的時間成本。

爲何要用 Packer

爲何呢？

固然是由於使用預製的鏡像有很是多的好處, 最簡單來講，就是能最大程度地保證不一樣機器上服務的一致性（以經驗來看這一點很是重要)。可是在實際使用中, 鏡像因其建立/管理的工做單調且複雜, 不少狀況下鏡像尚未被徹底普及。

現有的鏡像自動化建立工具, 要麼是很差用或不方便, 要麼就是學習曲線過高。這些特色致使運維團隊投入過多的精力在鏡像的使用中, 進而致使工做效率以及敏捷性被阻礙。這就是爲何雖然鏡像的工做方式具備很是多的優點，可是卻依舊沒有被大規模的普及。

Packer 依據單個的配置文件, 能作到流水線式 + 併發的建立鏡像，與傳統手工操做相比，其 "Infrastructure as Code" 的工做方式也大大減小了失誤的機率。

至少在 Packer 官方認爲:

Packer brings pre-baked images into the modern age,
unlocking untapped potential and opening new opportunities.

Infrastructure as Code 的工做方式

在這個理念被提出以前, 手工+腳本的方式很是廣泛, 手工容易出錯, 而腳本自己也要投入不少人力來進行維護。與此同時，一些主流的雲服務廠商也在積極尋找更多的可能性。2019年4月, 在咱們發佈了 terraform-provider-jdcloud插件之後, 目前一些團隊在使用 Terraform 的京東雲插件, 有的會在 Github 上留下 issues, 有的是經過留言，表示但願能增長更多功能。用戶的這些表現都從側面驗證了 "Infrastructure as Code" 工做方式的可靠性和敏捷性。

到了 Packer, 這些特性依舊被保留下來。相較於傳統方式，IaC 被認爲是: "Modern and Automated" , 一樣是一份簡單的 json 配置文件，IaC 鼓勵開發者開始使用鏡像, 同時使用 Packer 自動化、流水線化地管理鏡像, 從而減小鏡像自己管理帶來的負擔。

介紹一些平常的使用場景

• 持續交付 - Packer&Chef&Puppet：Packer 因其自身體積輕量的特色, 使其被直接放到流水線裏併成爲流水線的一環也變成了一種可能的選擇: 在 Chef/Puppet 的配置產生變更的時候觸發流水線, 下一環 Packer 負責爲新配置生成鏡像, 這些鏡像能夠馬上投入測試, 測試經過後便可部署到生產環境。
• 混合雲的使用：Packer 的一份配置能夠爲多個雲服務商生成鏡像, 假設你使用 VMWare 做爲開發環境, AWS 做爲生產環境, 那麼 Packer 可以併發生成兩份鏡像用於兩家雲服務商, 從而最大程度地減小兩個鏡像之間的區別。

詳細一些, Packer 還包含有這些優點

• 對於臨時產物的處理上：Packer 能爲你建立一些臨時資源，好比在沒有指定子網的狀況下，Packer 可以幫你建立一個臨時子網，用於安放雲主機。而且在出現錯誤的時候終止任務，同時自動清理中間產物。而傳統方式則須要本身先建立一個臨時子網，而且出現錯誤時還須要手動清理。
• 在問題的追溯與定位上：在 Packer 上全部變化都是基於代碼的，而代碼是能夠追溯的，方便快速定位問題並回滾。而在傳統方式中，考慮到手動操做的過程可能涉及多人，完整地追出問題並非一件容易的事兒。
• 在便捷性與效率上：因爲 Packer 上的操做基於代碼，變動的時候操做會很是快；而手動操做的效率則取決於我的的手速了。
• 在操做的可重複性上：Packer 依據配置文件，隨時快速從新操做；而在全手動的狀況下, 想要完整的復現一次全部操做並不容易。Packer 上代碼的可重複利用也說明你能夠用最快的速度再建立一個如出一轍的(測試)環境。

馬上開始使用 Packer

安裝 Packer

安裝 Packer 咱們推薦去 Packer官網 下載一個二進制包，解壓後直接就可使用。另外對於 Mac OS X 用戶, 也可使用 HomeBrew 直接進行安裝。

$ brew install packer

準備配置文件

在開始以前，你須要準備一份配置文件jdcloud.json，在配置文件裏給出相應的參數。

配置文件的模板以下：

1{
 2  "builders": [
 3    {
 4
 5      # 服務商與身份信息
 6      "type":             "jdcloud",
 7      "access_key":       "<Your access_key>",
 8      "secret_key":       "<Your secret_key>",
 9
10      # 雲主機規格信息
11      "image_id":         "<Base Image Id>",
12      "region_id":        "cn-north-1",
13      "az":               "cn-north-1c",
14      "instance_name":    "packer_demo",
15      "instance_type":    "g.n2.medium",
16      "ssh_password":     "DevOps2018",
17      "image_name":       "packer_image_demo",
18      "subnet_id":        "subnet-jo6e38sdli",
19
20      # 登陸設置(不用改)
21      "communicator":     "ssh",
22      "ssh_username":     "root"
23    }
24  ],
25
26  "provisioners": [
27    {
28      "type": "shell",
29      "inline": [
30
31        # 雲主機運行的腳本信息
32        "sleep 30",
33        "sudo apt update",
34        "sudo apt install nginx -y"
35      ]
36    }
37  ]
38}

• 服務商與身份信息 : 服務提供商-jdcloud, 其次你須要提供你的AccessKey/SecretKey 向咱們說明你的身份。
• 雲主機規格信息 :
  這裏包含：

雲主機/地域/可用區/機型與規格

基礎鏡像: 能夠是京東雲官方提供的 Centos/Ubuntu，也能夠是你的私人鏡像，將它的ID填寫在這裏便可。

子網信息: 能夠爲空，若是爲空的話，咱們會爲你建立一個臨時的子網。

登陸密碼: 在這裏咱們選擇使用密碼來登陸，在這兒還有另外一個示例，會告訴用戶如何使用祕鑰的方式來建立雲主機鏡像。

• 運行命令: 在這裏做爲示例，咱們選擇安裝一個 nginx。

使用配置文件開始建立鏡像

1bash
 2~ $ packer build jdcloud.json 
 3
 4==> jdcloud: Validating parameters...
 5    jdcloud: validating your subnet:subnet-xxx
 6    jdcloud: subnet found: Packer 測試子網
 7    jdcloud: validating your base image:img-1iubdz7gzu
 8    jdcloud: image found:Ubuntu 16.04 64位
 9    jdcloud: Password detected, we are going to login with this password :)
10
11==> jdcloud: Creating instances
12    jdcloud: Creating public-ip
13    jdcloud: Associating public-ip with instance
14    jdcloud: Hi, we have created the instance, its name=packer_demo , its id=i-xxxx, and its eip=116.196.xx.xx  :)
15
16==> jdcloud: Using ssh communicator to connect: 116.196.xx.xx
17==> jdcloud: Waiting for SSH to become available...
18==> jdcloud: Connected to SSH!
19==> jdcloud: Provisioning with shell script
20==> jdcloud: Stopping this instance
21    jdcloud: Instance has been stopped :)
22==> jdcloud: Creating images
23Build 'jdcloud' finished.
24
25
26==> Builds finished. The artifacts of successful builds are:
27--> jdcloud: A VMImage was created: img-riggr2xxx

在上面的建立過程當中, 咱們能夠看到, 鏡像的建立過程大致能夠分紅四個階段:

1. 階段-1 參數驗證階段：在這個階段裏咱們將要去驗證參數的有效性，包括是否指定子網，需不須要建立臨時子網，給出的運行鏡像是否存在，是否指定使用密碼登陸或指定密鑰登陸。
2. 階段-2 建立雲主機階段：在這個階段咱們按照給出的雲主機規格建立出一臺雲主機，並建立出一個公網IP, 用於稍後登陸這臺雲主機執行命令。
3. 階段-3 執行命令階段：命令的輸出都會打印在這裏。
4. 階段-4 建立鏡像階段：Packer 會將這臺雲主機建立出一個鏡像，並保存到鏡像倉庫裏, 在上面咱們能夠看到對應的鏡像ID爲:img-riggr2xxx。

建立出來的新鏡像，用戶能夠拿來手動建立雲主機，也能夠經過 terraform 自動建立雲主機。

更進一步地，若是考慮到服務的多地域性，用戶可能會但願爲每一個地域都建立出各自的專屬鏡像。這個時候，只須要在配置文件後面追加出其他地域的配置信息，Packer 就能在一次併發內完成全部鏡像的建立，很大程度的提高了鏡像建立的效率。

Packer 以其 "Infrastructure as Code" 的工做方式，在幫助用戶下降失誤故障風險的同時，提升了持續交付效率和業務可用性，解決了傳統鏡像建立方式在跨雲平臺環境下的諸多弊端。

看了這篇文章，您是否對Packer有一個全面的瞭解呢？若是您想了解更多關於京東雲翼的相關訊息，請點擊「這裏」，進入京東雲官網瞭解相關產品噢~

歡迎點擊「京東雲」瞭解更多精彩內容