Lecture 6 — DevOps and Infrastructure as Code

คาบนี้จะพาไปไหน

คาบ 5 จบที่ Kubernetes ซึ่งดูแล container บนหลายเครื่องให้เอง แต่ยังเหลือสองคำถามที่ Kubernetes ไม่ได้ตอบ

• เครื่องพวกนั้นมาจากไหน ใครสร้าง VM ต่อ network และเปิด firewall ให้
• เครื่องพวกนั้นพร้อมใช้ได้ยังไง ใครลงโปรแกรม แก้ไฟล์ตั้งค่า และเปิด service

ถ้าคำตอบคือ "มีคนทำมือ" ทุกอย่างที่ Kubernetes ทำให้อัตโนมัติจะไปติดอยู่ที่คนคนนั้น คาบนี้ตอบว่าจะเอาคนออกจากทางนี้ยังไง

ส่วนที่ 1 — DevOps: ทำไมโค้ดเสร็จแล้วยังไม่ถึงผู้ใช้

Agile เร็วแค่ครึ่งทาง

รอบบนมีสี่จังหวะ

1. ผู้ใช้บอก requirements
2. นักพัฒนา เขียนโค้ดและทดสอบ
3. นักพัฒนาส่ง prototype ให้ผู้ใช้ลอง
4. ผู้ใช้ส่ง feedback กลับมา แล้ววนรอบใหม่

รอบล่างคือจุดที่พัง นักพัฒนาส่ง product ที่ออกรุ่นแล้วให้ Operator (ผู้ดูแลระบบที่รันอยู่จริง) แต่ operator deploy ไม่ขึ้น เพราะเครื่องจริงไม่เหมือนเครื่องที่นักพัฒนาใช้ทดสอบ และไม่มีใครในรอบบนคิดเรื่องเครื่องจริงมาก่อน

DevOps ตั้งเป้าอะไร

DevOps (การรวมงานพัฒนากับงานดูแลระบบเข้าด้วยกัน) ตั้งเป้าให้ SDLC (Software Development Life Cycle วงจรชีวิตของซอฟต์แวร์ ตั้งแต่คิดจนเลิกใช้) สั้นลง โดยส่งของได้ต่อเนื่องและคุณภาพยังสูง วิธีมีสามข้อ

• คิดเรื่องสถาปัตยกรรมตอน deploy ตั้งแต่ต้น ไม่รอให้โค้ดเสร็จแล้วค่อยถามว่าจะขึ้นเครื่องไหน
• ให้ทุกคนในวงจรมีส่วนร่วมตลอด ไม่ใช่ส่งงานต่อกันเป็นทอด ๆ
• ทำทุกขั้นที่จำเป็นให้อัตโนมัติ มากที่สุดและเร็วที่สุดเท่าที่ทำได้

ข้อสุดท้ายคือจุดที่วิชานี้เข้ามา ถ้าเครื่องยังต้องตั้งด้วยมือ ขั้น deploy ก็อัตโนมัติไม่ได้ ระบบที่สั่งโครงสร้างพื้นฐานด้วยซอฟต์แวร์ได้ (ส่วนที่ 2) จึงเป็นตัวที่ทำให้ขั้นตั้งแต่รวมโค้ด ส่งมอบ จนขึ้นเครื่องจริงไหลต่อกันได้

หลักการสี่ข้อของ DevOps และประโยชน์ของมันอยู่ใน คาบ 1

วงจรของ DevOps

ของชิ้นเดียวกันวิ่งผ่านเครื่องสามชุด แต่ละชุดเรียกว่า Environment (ชุดเครื่องและการตั้งค่าที่แยกไว้สำหรับงานหนึ่ง) คือ development ของนักพัฒนา test สำหรับทดสอบ และ production ที่ผู้ใช้ใช้จริง

วงจรนี้มีแปดขั้นและวนไม่จบ

อัตโนมัติไปได้ไกลแค่ไหน

รูปนี้ใช้เจ็ดขั้นจากแปดขั้นในตารางข้างบน ตัด Plan กับ Monitor ออก และเพิ่ม Integrate ขั้นรวมโค้ดของทุกคนเข้าด้วยกันก่อนทดสอบ แล้วแบ่งตาม environment — Code กับ Build อยู่ใน development, Integrate, Test และ Release อยู่ใน test, Deploy กับ Operate อยู่ใน production

ชื่อที่ได้ยินบ่อยห้าชื่อคือความยาวของเส้นอัตโนมัติ

เครื่องมือของแต่ละขั้น

แต่ละขั้นมีงานที่ทำให้อัตโนมัติและเครื่องมือของมัน

อีกสองชั้นครอบทุกขั้นไว้

• CI/CD workflow tools ร้อยทุกขั้นเข้าเป็น Pipeline (ลำดับขั้นอัตโนมัติที่พาโค้ดจาก commit ไปถึงเครื่องจริง) เส้นเดียว เช่น Jenkins และ GitHub Actions
• Infrastructure ที่ทุกอย่างรันอยู่ข้างบน เช่น Docker และ Kubernetes จากคาบ 2 ถึง 5, VMware ที่แบ่งเครื่องจริงเป็น VM และ Linux ที่เป็น OS ของเซิร์ฟเวอร์ส่วนใหญ่

ทีมแบ่งงานกันสามแบบ

องค์กรที่ทำ platform engineering คู่กับทีม SRE (คอลัมน์ขวาของรูป 4) แบ่งงานกันแบบนี้

• ทีม product แต่ละทีมเหลือแค่ PM (plan), Dev (code) และ Test บางทีมไม่มีคนทดสอบแยก ให้ Dev ทดสอบเอง
• งาน deploy, monitor และ response ตอนเกิดเหตุ ไปอยู่กับทีม SRE
• ทุกทีมใช้ platform tooling ชุดเดียวกัน บน unified infrastructure ชุดเดียว

สามแบบนี้จึงซ้อนกันได้ ไม่ต้องเลือกแบบเดียว

ส่วนที่ 2 — Infrastructure as Code

ตั้งเครื่องด้วยมือพังตรงไหน

Infrastructure as Code คืออะไร

Infrastructure (โครงสร้างพื้นฐาน) คือชุดทรัพยากรที่ทำงานร่วมกันเพื่อรันแอป ทั้ง hardware, software, network และ service

Infrastructure as Code (การเขียนโครงสร้างพื้นฐานเป็นโค้ด แทนการคลิกตั้งค่าทีละหน้าจอ) (IaC) คือการเขียน สถานะที่ต้องการ ของโครงสร้างพื้นฐานไว้ในไฟล์ที่เครื่องอ่านได้ แล้วให้เครื่องมือทำให้เป็นจริง

พอโครงสร้างพื้นฐานกลายเป็นไฟล์ ก็จัดการด้วยวิธีเดียวกับโค้ดได้ทันที

"สถานะที่ต้องการ" เป็นแนวคิดเดียวกับ desired state ของ Kubernetes ใน คาบ 5 — IaC ขยายแนวคิดนี้จาก container ออกไปถึงตัวเครื่อง

IaC ทำงานยังไง

IaC ครอบงานห้าด้าน แต่ละด้านอยู่ในเส้นทางของโค้ดแบบนี้

• นักพัฒนา เขียน infrastructure code ทั้งส่วนที่สร้างเครื่อง (infrastructure automation) และส่วนที่ตั้งค่าบนเครื่อง (configuration management)
• โค้ดถูกเก็บใน version control และผ่าน automated testing
• automation API หรือ server เช่น Terraform หรือ Ansible ที่รันใน pipeline เอาโค้ดไป deploy และจัดการเครื่อง (deployment automation) ทั้งบนคลาวด์และบนเครื่องขององค์กรเอง (on-premises (เครื่องที่องค์กรตั้งไว้เอง ไม่ได้เช่าคลาวด์))

โค้ดไปถึง automation server ได้สองทาง

• Push — ฝั่งที่ถือโค้ดส่งโค้ดไปให้ server ตอนที่เราสั่ง
• Pull — server คอยดึงโค้ดรุ่นล่าสุดมาเทียบกับที่ใช้อยู่เป็นระยะ คล้าย control loop ของ Kubernetes

เครื่องมือ IaC ห้ากลุ่ม

จุดเริ่มคือ ad hoc scripts — สคริปต์ติดตั้งและตั้งค่าที่ผู้ดูแลระบบเขียนเอง ใช้ได้ แต่ต้องคิดเองทุกเรื่อง เช่น รันซ้ำแล้วพังไหม อีกสี่กลุ่มเกิดมาเพื่อแทนสคริปต์พวกนี้ทีละช่วง

สองกลุ่มเจอมาแล้ว — Docker ใน คาบ 2 คือ server templating ส่วน orchestration คือ Compose ในคาบ 3 และ Kubernetes กับ Docker Swarm (ตัวคุม container หลายเครื่องของ Docker เอง) ใน คาบ 5 คาบนี้เพิ่ม provisioning กับ configuration management

เครื่องมือหลายกลุ่มใช้ร่วมกันได้ และในงานจริงก็มักใช้ร่วมกัน

Terraform กับ Ansible ทำงานคนละชั้น

• Terraform provision ชั้นล่าง: network, load balancer, database, user, permission และตัวเซิร์ฟเวอร์
• Ansible configure ชั้นบน: ลงแอปและตั้งค่าบนเซิร์ฟเวอร์ที่ Terraform สร้างไว้

ส่วนที่ 3 — Terraform: สร้างโครงสร้างพื้นฐานจากไฟล์

Terraform ประกอบด้วยอะไร

Terraform แก้สองปัญหานั้นด้วยการแยกเป็นสามชิ้น

• Terraform Core อ่านไฟล์ *.tf ที่เราเขียน แล้ววางแผนว่าต้องทำอะไร ตัวนี้ไม่รู้จักผู้ให้บริการเจ้าไหนเลย
• Provider (ปลั๊กอินที่แปลงงานของ Terraform เป็นการเรียก API ของผู้ให้บริการเจ้าหนึ่ง) คือปลั๊กอินที่คุยกับ API ของผู้ให้บริการแทน Core ไฟล์ชุดเดียวใช้หลาย provider พร้อมกันได้
• State (ไฟล์ที่ Terraform จดว่าสร้างอะไรไปแล้ว) คือไฟล์ *.tfstate ที่ Core อ่านและเขียน เพื่อรู้ว่าของในไฟล์ตัวไหนมีอยู่จริงแล้ว

provider หนึ่งตัวมีของสองแบบให้ใช้

• Resource (ของที่ Terraform สร้างและดูแลเอง) — ของที่ Terraform สร้าง แก้ และลบ เช่น VM, virtual network หรือ container
• Data source (ข้อมูลที่ Terraform อ่านมาใช้ โดยไม่ได้ดูแลของชิ้นนั้น) — ข้อมูลที่อ่านมาใช้อย่างเดียว มีตัวอย่างเต็มในหัวข้อ variable, local, output

ชื่อ resource และ data source ที่ใช้ได้ รวมถึง argument ของแต่ละตัว ถูกกำหนดไว้ใน เอกสารของ provider ตัวอย่าง provider ที่ใช้กันบ่อย

ชื่อเดียวกันเป็นได้ทั้งสองแบบ เช่น aws_ami เป็น resource เมื่อเราสร้าง image เอง และเป็น data source เมื่ออ่าน image ที่คนอื่นสร้างไว้

เขียนไฟล์ Terraform

ไฟล์ Terraform เขียนด้วย Terraform Configuration Language ใช้ประกาศ resource และวิธีจัดการมัน ทุกอย่างเป็น Block (หน่วยหนึ่งของไฟล์ Terraform มีชนิด ป้ายชื่อ และเนื้อในวงเล็บปีกกา) ที่มีรูปแบบเดียว

<BLOCK TYPE> "<BLOCK LABEL>" "<BLOCK LABEL>" {
  # Block body
  <IDENTIFIER> = <EXPRESSION> # Argument
}

ตัวอย่างจริงหนึ่ง block

resource "docker_image" "nginx" {
  name         = "nginx:latest"
  keep_locally = false
}

ชนิดกับชื่อรวมกันเป็นที่อยู่ของ resource คือ docker_image.nginx block อื่นอ้างถึงค่าของมันได้ด้วยที่อยู่นี้ เช่น docker_image.nginx.image_id

Terraform ใช้การอ้างถึงนี้หาลำดับการสร้างเอง ถ้า container อ้างถึง image มันก็สร้าง image ก่อน กรณีที่ความเกี่ยวข้องไม่ได้ปรากฏเป็นการอ้างถึง ให้ประกาศเองด้วย depends_on ซึ่งอยู่ในหัวข้อ meta-argument

Hello World: nginx ใน Docker

ไฟล์ main.tf นี้รัน nginx ใน Docker บนเครื่องตัวเอง ไม่ต้องมีบัญชีคลาวด์

terraform {
  required_providers {
    docker = {
      source  = "kreuzwerker/docker"
      version = "~> 2.21.0"
    }
  }
}

provider "docker" {}

resource "docker_image" "nginx" {
  name         = "nginx:latest"
  keep_locally = false
}

resource "docker_container" "nginx" {
  image = docker_image.nginx.image_id
  name  = "tutorial"
  ports {
    internal = 80
    external = 8000
  }
}

output "nginx_id" {
  value = docker_container.nginx.id
}

output "nginx_ip_address" {
  value = docker_container.nginx.network_data[0].ip_address
}

วงจร init, plan, apply, destroy

terraform init — เตรียมโฟลเดอร์

init อ่าน required_providers แล้วโหลด provider ที่ตรงเงื่อนไขมาไว้ในโฟลเดอร์

- Finding kreuzwerker/docker versions matching "~> 2.21.0"...
- Installing kreuzwerker/docker v2.21.0...
- Installed kreuzwerker/docker v2.21.0 (self-signed, key ID BD080C4571C6104C)
Terraform has created a lock file .terraform.lock.hcl to record the provider
selections it made above. Include this file in your version control repository

• เงื่อนไข ~> 2.21.0 ได้รุ่นจริง v2.21.0
• provider ของ partner และชุมชนลงลายเซ็นโดยผู้พัฒนาเอง จึงขึ้นว่า self-signed
• init สร้าง .terraform.lock.hcl ซึ่งจดรุ่น provider ที่เลือกไว้ ไฟล์นี้ต้อง commit ทุกคนที่รัน init ครั้งต่อไปจะได้ provider รุ่นเดียวกัน
• ถ้าเปลี่ยน module (ชุดไฟล์ Terraform ที่เรียกใช้ซ้ำ มีในหัวข้อ module ด้านล่าง) หรือ backend (ที่เก็บ state) ต้องรัน init ใหม่ ถ้าลืม คำสั่งอื่นจะเตือนเอง

$ terraform init
Initializing the backend...
Initializing provider plugins...
- Finding kreuzwerker/docker versions matching "~> 2.21.0"...
- Installing kreuzwerker/docker v2.21.0...
- Installed kreuzwerker/docker v2.21.0 (self-signed, key ID BD080C4571C6104C)
Partner and community providers are signed by their developers.
If you'd like to know more about provider signing, you can read about it here:
https://www.terraform.io/docs/cli/plugins/signing.html
Terraform has created a lock file .terraform.lock.hcl to record the provider
selections it made above. Include this file in your version control repository
so that Terraform can guarantee to make the same selections by default when
you run "terraform init" in the future.

Terraform has been successfully initialized!

You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.

If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.

terraform plan — ดูก่อนว่าจะเกิดอะไร

plan เทียบไฟล์กับของจริงแล้วบอกว่าจะทำอะไร โดยยังไม่แตะของจริง

indicated with the following symbols:
  + create

  # docker_container.nginx will be created
  + resource "docker_container" "nginx" {
      + id               = (known after apply)
      + ip_address       = (known after apply)
      + must_run         = true
      + name             = "tutorial"

• + คือจะสร้าง ส่วนสัญลักษณ์ ~ (แก้ที่เดิม) และ - (ลบ) จะเจอในหัวข้อถัด ๆ ไป
• ค่าที่เราเขียนเองรู้แล้ว เช่น name = "tutorial"
• ค่าที่ต้องรอของจริงเกิดก่อนขึ้นว่า (known after apply) เช่น id และ ip_address เพราะ Docker เป็นคนแจก ไม่ใช่เรา

$ terraform plan

Terraform used the selected providers to generate the following execution plan. Resource actions are
indicated with the following symbols:
  + create

Terraform will perform the following actions:

  # docker_container.nginx will be created
  + resource "docker_container" "nginx" {
      + attach           = false
      + bridge           = (known after apply)
      + command          = (known after apply)
      + container_logs   = (known after apply)
      + entrypoint       = (known after apply)
      + env              = (known after apply)
      + exit_code        = (known after apply)
      + gateway          = (known after apply)
      + hostname         = (known after apply)
      + id               = (known after apply)
      + image            = (known after apply)
      + init             = (known after apply)
      + ip_address       = (known after apply)
      + ip_prefix_length = (known after apply)
      + ipc_mode         = (known after apply)
      + log_driver       = (known after apply)
      + logs             = false
      + must_run         = true
      + name             = "tutorial"

terraform apply — ทำจริง

apply แสดงแผนเดิมอีกรอบ แล้วรอให้ยืนยัน

Plan: 2 to add, 0 to change, 0 to destroy.

  Only 'yes' will be accepted to approve.

  Enter a value: yes

docker_image.nginx: Creation complete after 18s [id=sha256:4b196525bd3cc6aa7a72ba63c6c2ae6d957b57edd603a7070c5e31f8e63c51f9nginx:latest]
docker_container.nginx: Creation complete after 0s [id=0530ae24006f1606ced13da71ce2b1a9361d52990a059fda00ee8700bcb3e3d3]

Apply complete! Resources: 2 added, 0 changed, 0 destroyed.

nginx_ip_address = "172.17.0.2"

• ต้องพิมพ์ yes เท่านั้น พิมพ์อย่างอื่นถือว่ายกเลิก
• image ถูกสร้างก่อน ใช้ 18 วินาทีเพราะต้องดาวน์โหลด แล้ว container ตามมา ลำดับนี้มาจาก image = docker_image.nginx.image_id
• ค่าที่เคยเป็น (known after apply) ตอนนี้มีจริงแล้ว container ได้ IP 172.17.0.2
• Terraform จดทุกอย่างที่สร้างลง state

$ terraform apply

Terraform used the selected providers to generate the following execution plan. Resource actions are
indicated with the following symbols:
  + create

Terraform will perform the following actions:

  # docker_container.nginx will be created
  + resource "docker_container" "nginx" {
      + attach           = false
      + bridge           = (known after apply)
      + command          = (known after apply)
      + container_logs   = (known after apply)
      + entrypoint       = (known after apply)
      + env              = (known after apply)
      + exit_code        = (known after apply)
      + gateway          = (known after apply)
      + hostname         = (known after apply)
      + id               = (known after apply)
      + image            = (known after apply)
      + init             = (known after apply)
      + ip_address       = (known after apply)
      + ip_prefix_length = (known after apply)
      + ipc_mode         = (known after apply)
      + log_driver       = (known after apply)
      + logs             = false
      + must_run         = true
      + name             = "tutorial"
    }

Plan: 2 to add, 0 to change, 0 to destroy.

Changes to Outputs:
  + nginx_id         = (known after apply)
  + nginx_ip_address = (known after apply)

Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value: yes

docker_image.nginx: Creating...
docker_image.nginx: Still creating... [10s elapsed]
docker_image.nginx: Creation complete after 18s [id=sha256:4b196525bd3cc6aa7a72ba63c6c2ae6d957b57edd603a7070c5e31f8e63c51f9nginx:latest]
docker_container.nginx: Creating...
docker_container.nginx: Creation complete after 0s [id=0530ae24006f1606ced13da71ce2b1a9361d52990a059fda00ee8700bcb3e3d3]

Apply complete! Resources: 2 added, 0 changed, 0 destroyed.

Outputs:

nginx_id = "0530ae24006f1606ced13da71ce2b1a9361d52990a059fda00ee8700bcb3e3d3"
nginx_ip_address = "172.17.0.2"

terraform destroy — ลบทุกอย่างที่สร้างไว้

docker_container.nginx: Refreshing state... [id=0530ae24006f1606ced13da71ce2b1a9361d52990a059fda00ee8700bcb3e3d3]

  - destroy

  # docker_container.nginx will be destroyed
  - resource "docker_container" "nginx" {
      - command           = [
          - "nginx",
          - "-g",
          - "daemon off;",
        ] -> null
      - entrypoint        = [
          - "/docker-entrypoint.sh",
        ] -> null
      - gateway           = "172.17.0.1" -> null

• Refreshing state — ก่อนวางแผนลบ Terraform ถามของจริงก่อนว่ายังตรงกับ state ไหม
• - คือจะลบ และทุกค่าจะกลายเป็น -> null
• ตอนนี้ทุกค่ารู้แล้ว เช่น container รันคำสั่ง nginx -g "daemon off;" ผ่าน /docker-entrypoint.sh และ gateway คือ 172.17.0.1
• destroy ลบเฉพาะของที่อยู่ใน state ของที่ใครสร้างด้วยมือไว้ข้าง ๆ ไม่โดนลบ

$ terraform destroy
docker_image.nginx: Refreshing state... [id=sha256:4b196525bd3cc6aa7a72ba63c6c2ae6d957b57edd603a7070c5e31f8e63c51f9nginx:latest]
docker_container.nginx: Refreshing state... [id=0530ae24006f1606ced13da71ce2b1a9361d52990a059fda00ee8700bcb3e3d3]

Terraform used the selected providers to generate the following execution plan. Resource actions are
indicated with the following symbols:
  - destroy

Terraform will perform the following actions:

  # docker_container.nginx will be destroyed
  - resource "docker_container" "nginx" {
      - attach            = false -> null
      - command           = [
          - "nginx",
          - "-g",
          - "daemon off;",
        ] -> null
      - cpu_shares        = 0 -> null
      - dns               = [] -> null
      - dns_opts          = [] -> null
      - dns_search        = [] -> null
      - entrypoint        = [
          - "/docker-entrypoint.sh",
        ] -> null
      - env               = [] -> null
      - gateway           = "172.17.0.1" -> null

อ่านของที่มีอยู่แล้ว: data source

data source อ่านข้อมูลจาก API ของ provider โดยไม่ได้ดูแลของชิ้นนั้น Terraform ไม่สร้าง ไม่แก้ และไม่ลบมัน แค่ถามค่าปัจจุบันมาใช้ ตัวอย่างเต็มอยู่ในหัวข้อถัดไป

ทำให้ไฟล์ใช้ซ้ำได้: variable, local, output

Terraform มีค่าสามแบบ

ตัวอย่างนี้ใช้ variable, data source และ output ร่วมกันเพื่อสร้าง VM บน AWS

provider "aws" {
  region     = "us-east-1"
  access_key = var.aws_access_key
  secret_key = var.aws_secret_key
}

# 1. VARIABLE: Define the input parameter
variable "component_name" {
  type        = string
  description = "The application name used for tagging and lookup"
  default     = "nomad-server"
}

# 2. DATA SOURCE: Fetch information from AWS using the variable
data "aws_ami" "latest_ubuntu" {
  most_recent = true
  owners      = ["099720109477"] # Canonical (Ubuntu) owner ID

  filter {
    name   = "name"
    values = ["ubuntu/images/hvm-ssd/ubuntu-jammy-22.04-amd64-server-*"]
  }

  # An example of a lifecycle rule check inside a data block
  lifecycle {
    postcondition {
      condition     = var.component_name != ""
      error_message = "The component_name variable cannot be empty."
    }
  }
}

# 3. RESOURCE: Create a new EC2 instance using the data source AND the variable
resource "aws_instance" "web" {
  # References the output ID of the data source block
  ami           = data.aws_ami.latest_ubuntu.id
  instance_type = "t3.micro"

  tags = {
    # References the input variable via the "var." prefix
    Component = var.component_name
    Name      = "${var.component_name}-web-server"
  }
}

output "instance_public_ip" {
  value = aws_instance.web.public_ip
}

• variable component_name มีค่าเริ่มต้น "nomad-server"
• data source aws_ami.latest_ubuntu ค้น image ที่เจ้าของเป็น Canonical (owner ID 099720109477) และชื่อตรงกับ Ubuntu 22.04 (jammy) แล้วเลือกตัวล่าสุดด้วย most_recent = true
• block lifecycle ข้างในมี postcondition ตรวจหลังอ่านข้อมูลว่า component_name ไม่ว่าง ถ้าว่างให้หยุดพร้อมข้อความ error
• resource aws_instance.web อ้าง data source ด้วยคำนำหน้า data. และอ้าง variable ด้วย var.
• "${var.component_name}-web-server" แทนค่าตัวแปรลงกลางข้อความ ได้ "nomad-server-web-server" (ตรวจด้วย terraform console)
• output instance_public_ip พิมพ์ IP สาธารณะของเครื่องหลัง apply

แบ่งเป็นชิ้นที่ใช้ซ้ำได้: module

Module (โฟลเดอร์ของไฟล์ Terraform ที่เรียกใช้ซ้ำได้) คือโฟลเดอร์ของไฟล์ Terraform ที่มี interface สำหรับใช้ซ้ำ — variable คือช่องรับค่าเข้า output คือค่าที่ส่งออก

• โฟลเดอร์ที่เรารันคำสั่งอยู่คือ Root module (module ของโฟลเดอร์ที่รันคำสั่ง)
• root module เรียก Child module (module ที่ถูกเรียกจาก module อื่น) ได้ ทั้งจากโฟลเดอร์ในเครื่องและจาก registry (คลังกลางที่แชร์ module)

$ terraform apply
...
Outputs:

db_password = <sensitive>
hosts = [
  "sds-pacific",
  "sds-arctic",
]

$ terraform plan -var 'web_name='
Error: Invalid value for variable
web_name cannot be empty.

variable "name" {
  type = string
}

resource "terraform_data" "this" {
  input = var.name
}

output "hostname" {
  value = terraform_data.this.output
}

variable "web_name" {
  type        = string
  description = "Name of the web server"
  default     = "pacific"

  validation {
    condition     = length(var.web_name) > 0
    error_message = "web_name cannot be empty."
  }
}

variable "db_password" {
  type      = string
  sensitive = true
}

locals {
  prefix = "sds"
}

module "web" {
  source = "./modules/server"
  name   = "${local.prefix}-${var.web_name}"
}

module "db" {
  source = "./modules/server"
  name   = "${local.prefix}-arctic"
}

output "hosts" {
  value = [module.web.hostname, module.db.hostname]
}

output "db_password" {
  value     = var.db_password
  sensitive = true
}

Initializing modules...
- db in modules/server
- web in modules/server

  # module.db.terraform_data.this will be created
  # module.web.terraform_data.this will be created

Apply complete! Resources: 2 added, 0 changed, 0 destroyed.

Outputs:

db_password = <sensitive>
hosts = [
  "sds-pacific",
  "sds-arctic",
]

Planning failed. Terraform encountered an error while generating this plan.

Error: Invalid value for variable

  on main.tf line 1:
   1: variable "web_name" {

web_name cannot be empty.

This was checked by the validation rule at main.tf:6,3-13.

$ grep -n s3cret terraform.tfstate
8:      "value": "s3cret",

สร้างหลายชิ้นจาก block เดียว: meta-argument

Meta-argument (argument พิเศษที่ Terraform เข้าใจเอง ใช้ได้กับ resource ทุกชนิด) คือ argument ที่ใช้ได้กับ resource ทุกชนิด ไม่ขึ้นกับ provider

• depends_on — ประกาศว่าต้องสร้างหลังของอีกชิ้น ในกรณีที่ Terraform อนุมานจากการอ้างถึงไม่ได้
• count — สร้างหลายชิ้นตามจำนวนเต็ม
• for_each — สร้างหลายชิ้นตาม map หรือ set
• provider — เลือกการตั้งค่า provider ที่ไม่ใช่ตัวหลัก เช่น region ที่สอง
• lifecycle — ปรับพฤติกรรมตอนสร้าง แทนที่ และลบ postcondition ในตัวอย่าง AWS ก็อยู่ใน block นี้

Provisioner (block ที่สั่งรันสคริปต์ตอนสร้างหรือลบ resource) เป็น block แยก ไม่ใช่ meta-argument และควรใช้ เป็นทางสุดท้าย เพราะ Terraform ไม่รู้ว่าสคริปต์จะทำอะไร จึงใส่ผลของมันลงแผนไม่ได้ และ plan ก็บอกไม่ได้ว่าจะเกิดอะไร

terraform_data.firewall: Creating...
terraform_data.web: Creating...

terraform_data.firewall: Creating...
terraform_data.firewall: Creation complete after 0s [id=8b4b4fcd-b2ca-a265-eebf-e2e0fcf7ef7a]
terraform_data.web: Creating...

resource "terraform_data" "firewall" {
  input = "allow-tcp-8000"
}

resource "terraform_data" "web" {
  input      = "sds-pacific"
  depends_on = [terraform_data.firewall]
}

terraform_data.firewall: Creating...
terraform_data.web: Creating...
terraform_data.firewall: Creation complete after 0s [id=141b9e7f-16f3-7cc3-08c2-6f3ae50ebd47]
terraform_data.web: Creation complete after 0s [id=28d999f2-ed1f-7c17-82fa-eb553cbb79ff]

terraform_data.firewall: Creating...
terraform_data.firewall: Creation complete after 0s [id=8b4b4fcd-b2ca-a265-eebf-e2e0fcf7ef7a]
terraform_data.web: Creating...
terraform_data.web: Creation complete after 0s [id=ee36e01a-30df-3163-adbe-6c3b27436433]

$ terraform graph
digraph G {
  rankdir = "RL";
  node [shape = rect, fontname = "sans-serif"];
  "terraform_data.firewall" [label="terraform_data.firewall"];
  "terraform_data.web" [label="terraform_data.web"];
  "terraform_data.web" -> "terraform_data.firewall";
}

provider "docker" {}

provider "docker" {
  alias = "arctic"
  host  = "ssh://[email protected]:22"
}

resource "docker_image" "nginx" {
  name = "nginx:latest"
}

resource "docker_image" "nginx_arctic" {
  provider = docker.arctic
  name     = "nginx:latest"
}

$ terraform validate
Success! The configuration is valid.

$ terraform validate
Error: Provider configuration not present
...
provider["registry.terraform.io/kreuzwerker/docker"].atlantic is required,

count กับ for_each ดูเหมือนทำงานเดียวกัน แต่ต่างกันมากตอนรายการเปลี่ยน

$ terraform plan -var='instance_set=["pacific","atlantic"]'
  # terraform_data.by_count[1] will be updated in-place
      ~ input  = "sds-arctic" -> "sds-atlantic"
  # terraform_data.by_count[2] will be destroyed
  # terraform_data.by_each["arctic"] will be destroyed
Plan: 0 to add, 1 to change, 2 to destroy.

variable "instance_set" {
  type    = list(string)
  default = ["pacific", "arctic", "atlantic"]
}

locals {
  prefix = "sds"
}

resource "terraform_data" "by_count" {
  count = length(var.instance_set)
  input = "${local.prefix}-${var.instance_set[count.index]}"
}

resource "terraform_data" "by_each" {
  for_each = toset(var.instance_set)
  input    = "${local.prefix}-${each.value}"
}

output "names" {
  value = { for k, s in terraform_data.by_each : k => s.output }
}

$ terraform state list
terraform_data.by_count[0]
terraform_data.by_count[1]
terraform_data.by_count[2]
terraform_data.by_each["arctic"]
terraform_data.by_each["atlantic"]
terraform_data.by_each["pacific"]

No changes. Your infrastructure matches the configuration.

$ terraform plan -var='instance_set=["pacific","atlantic"]'
terraform_data.by_each["pacific"]: Refreshing state... [id=fe29d928-8a00-71a9-ae31-e9d67fec2868]
terraform_data.by_count[2]: Refreshing state... [id=dae09a5a-cc86-e4ae-e878-9bb52d59a81e]
terraform_data.by_count[0]: Refreshing state... [id=059eb67b-bd5b-f2ad-5b4c-3e9574e80cab]
terraform_data.by_each["arctic"]: Refreshing state... [id=3e4c9cf3-17e5-9e8b-5ff1-5ce042009130]
terraform_data.by_count[1]: Refreshing state... [id=b0a5e607-df46-4b85-3c0b-b0fbbf322585]
terraform_data.by_each["atlantic"]: Refreshing state... [id=697d4118-79d3-4171-f208-9344a32bf9ec]

Terraform used the selected providers to generate the following execution
plan. Resource actions are indicated with the following symbols:
  ~ update in-place
  - destroy

Terraform will perform the following actions:

  # terraform_data.by_count[1] will be updated in-place
  ~ resource "terraform_data" "by_count" {
        id     = "b0a5e607-df46-4b85-3c0b-b0fbbf322585"
      ~ input  = "sds-arctic" -> "sds-atlantic"
      ~ output = "sds-arctic" -> (known after apply)
    }

  # terraform_data.by_count[2] will be destroyed
  # (because index [2] is out of range for count)
  - resource "terraform_data" "by_count" {
      - id     = "dae09a5a-cc86-e4ae-e878-9bb52d59a81e" -> null
      - input  = "sds-atlantic" -> null
      - output = "sds-atlantic" -> null
    }

  # terraform_data.by_each["arctic"] will be destroyed
  # (because key ["arctic"] is not in for_each map)
  - resource "terraform_data" "by_each" {
      - id     = "3e4c9cf3-17e5-9e8b-5ff1-5ce042009130" -> null
      - input  = "sds-arctic" -> null
      - output = "sds-arctic" -> null
    }

Plan: 0 to add, 1 to change, 2 to destroy.

Changes to Outputs:
  ~ names = {
      - arctic   = "sds-arctic"
        # (2 unchanged attributes hidden)
    }

Note: You didn't use the -out option to save this plan, so Terraform can't
guarantee to take exactly these actions if you run "terraform apply" now.

ของที่มีตัวตนเฉพาะ เช่นเครื่องที่มีชื่อ ให้ใช้ for_each ส่วน count เหมาะกับของที่ทุกชิ้นเหมือนกันและสลับกันได้

Terraform กับ OpenTofu

• เดือนสิงหาคม 2023 HashiCorp เปลี่ยนสัญญาอนุญาตของ Terraform รุ่นต่อ ๆ ไป จาก MPL 2.0 ซึ่งเป็น open source ไปเป็น Business Source License 1.1 (BSL) ซึ่งยังเปิดให้อ่าน source และใช้งานได้ แต่ห้ามเอาไปทำผลิตภัณฑ์ที่แข่งกับ HashiCorp จึงไม่นับเป็น open source
• OpenTofu (Terraform ฉบับ fork ที่ยังเป็น open source) คือ fork แบบ open source ที่เขียนไฟล์และใช้ขั้นตอนเหมือน Terraform
• ทั้งสองฝั่งยังพึ่ง provider และ module เป็นหลัก แต่ความเข้ากันได้อาจห่างกันขึ้นเรื่อย ๆ
• จะเลือกตัวไหน ให้ดูเงื่อนไขสัญญาอนุญาต ความสามารถของ platform การซัพพอร์ต และ provider ที่ทดสอบแล้วว่าใช้ด้วยกันได้

ส่วนที่ 4 — Ansible: ตั้งค่าเครื่องที่มีอยู่แล้ว

Ansible ทำอะไร

Ansible (เครื่องมือ automation และ configuration management) คือเครื่องมือ automation และ configuration management แบบ Agentless (ไม่ต้องติดตั้งโปรแกรมของเครื่องมือค้างไว้บนเครื่องปลายทาง)

วิธีคิดคือ เขียนสภาพที่ต้องการของเซิร์ฟเวอร์ แล้วให้เครื่องมือบังคับให้เซิร์ฟเวอร์เป็นอย่างนั้น สภาพที่เขียนได้ เช่น

• package ถูกติดตั้ง (หรือถอนออก)
• ไฟล์ตั้งค่าถูกแก้ถูกต้อง และมี permission ที่ถูก
• service ถูกเปิด (หรือปิด)

Ansible ใช้ทำ deployment และ provisioning ได้ด้วย แม้งานถนัดจะเป็นการตั้งค่า

สถาปัตยกรรม

• Control node (เครื่องที่ติดตั้ง Ansible และเป็นคนสั่งงาน) — เครื่องที่ติดตั้ง Ansible และเป็นคนสั่ง ข้างในมีส่วนแกนกลาง (core components) กับส่วนเสริมจากชุมชน (community components)
• Managed node (เครื่องที่ถูก Ansible ตั้งค่า) — เครื่องที่ถูกตั้งค่า control node เชื่อมไปหาผ่าน SSH
• Inventory (รายชื่อเครื่องที่ Ansible จัดการ) — รายชื่อเครื่องและที่อยู่ของมัน
• Playbook (ไฟล์ YAML ที่เขียนสภาพที่ต้องการและขั้นตอน) — ไฟล์ที่บอกว่าเครื่องต้องอยู่ในสภาพไหน

ทำไมใช้ Ansible

ข้อสุดท้ายต่างจาก Chef และ Puppet ที่อยู่กลุ่มเดียวกัน ซึ่งในการติดตั้งแบบดั้งเดิมต้องลง agent บนทุกเครื่องให้คอยดึงงานจากเซิร์ฟเวอร์กลาง

ติดตั้งและบอกว่ามีเครื่องอะไรบ้าง

ติดตั้งบน control node ด้วย pip แล้วตรวจว่าใช้ได้

pip install ansible
ansible --version

สร้างไฟล์ตั้งค่า แล้วลิงก์ไปไว้ที่ ~/.ansible.cfg ซึ่งเป็นที่หนึ่งที่ Ansible มองหาไฟล์ตั้งค่า

ansible-config init --disabled > ~/ansible/ansible.cfg
ln -s ~/ansible/ansible.cfg ~/.ansible.cfg

--disabled สร้างไฟล์ที่มีทุกตัวเลือกแต่ comment ไว้หมด จากนั้นแก้ส่วน [defaults] ให้ชี้ไปที่ inventory

[defaults]
inventory       = ~/ansible/inventory

Inventory

all:
  hosts:
    pacific:
      ansible_host: 35.240.143.206
      ansible_python_interpreter: /usr/bin/python3
    arctic:
      ansible_host: 35.240.143.207
      ansible_python_interpreter: /usr/bin/python3
    atlantic:
      ansible_host: 35.240.143.208
      ansible_python_interpreter: /usr/bin/python3
webservers:
  hosts:
    pacific:
    atlantic:

• pacific เป็นชื่อเรียกใน Ansible ส่วน IP จริงอยู่ใน ansible_host
• ansible_python_interpreter บอกว่า Python บนเครื่องปลายทางอยู่ที่ไหน
• กลุ่ม webservers อ้างถึงเครื่องที่ประกาศไว้แล้วด้วยชื่ออย่างเดียว เครื่องหนึ่งอยู่ได้หลายกลุ่ม

สั่งทีละคำสั่ง: ad-hoc command

ansible <pattern> [options]

• <pattern> เลือกเครื่อง เช่น all หรือชื่อกลุ่ม webservers
• -m <module> เลือก Module (Ansible) (โปรแกรมชิ้นเล็กที่ทำงานหนึ่งอย่างบนเครื่องปลายทาง) — โปรแกรมชิ้นเล็กที่ Ansible ส่งไปทำงานหนึ่งอย่างบนเครื่องปลายทาง
• -a <module args> ส่ง argument ให้ module

$ ansible all -m ping
atlantic | SUCCESS => {
    "changed": false,
    "ping": "pong"
}
pacific | SUCCESS => {
    "changed": false,
    "ping": "pong"
}
arctic | SUCCESS => {
    "changed": false,
    "ping": "pong"
}

• module ping ไม่ใช่ ping แบบ ICMP มันล็อกอินผ่าน SSH แล้วรัน Python บนปลายทาง ได้ pong แปลว่าเครื่องนั้นพร้อมให้ Ansible ใช้
• "changed": false บอกว่าไม่มีอะไรบนเครื่องถูกเปลี่ยน
• ลำดับคำตอบไม่ตรงกับ inventory เพราะ Ansible ถามหลายเครื่องพร้อมกัน

รันคำสั่งบนบางเครื่อง

$ ansible webservers -a "/bin/echo hello" --limit pacific
pacific | CHANGED | rc=0 >>
hello

• ไม่ใส่ -m Ansible ใช้ module command เป็นค่าเริ่มต้น
• --limit pacific กรองเครื่องในกลุ่ม webservers ให้เหลือแค่ pacific
• rc=0 คือ return code ของคำสั่ง
• ขึ้น CHANGED ทั้งที่ echo ไม่ได้เปลี่ยนอะไร เพราะ module command ไม่รู้ว่าคำสั่งทำอะไรไป จึงรายงานว่าเปลี่ยนไว้ก่อนเสมอ

งานที่ต้องใช้สิทธิ์ root

Become (การยกสิทธิ์ขึ้นเป็นผู้ใช้อื่น ปกติคือ root) คือชื่อที่ Ansible ใช้เรียกการยกสิทธิ์ ปกติทำผ่าน sudo

$ ansible all -a "/sbin/reboot" --limit arctic,atlantic
arctic | FAILED | rc=1 >>
Call to Reboot failed: Interactive authentication required.non-zero return code
atlantic | FAILED | rc=1 >>
Call to Reboot failed: Interactive authentication required.non-zero return code

$ ansible all -a "/sbin/reboot" --limit arctic,atlantic -b --ask-become-pass
BECOME password:
atlantic | CHANGED | rc=0 >>

arctic | CHANGED | rc=0 >>

--limit arctic,atlantic เลือกหลายเครื่องโดยคั่นด้วยจุลภาค

Module และ collection

module ที่มากับทุกการติดตั้ง

module ที่มากับ Ansible ทุกชุดอยู่ในกลุ่มชื่อ ansible.builtin (ชื่อนี้มีที่มาในหัวข้อชื่อเต็มด้านล่าง) ครอบงานพื้นฐานห้าด้าน

ตัวที่ใช้บ่อยที่สุด

เอกสารของทุก module ในกลุ่มนี้อยู่ที่ https://docs.ansible.com/projects/ansible/latest/collections/ansible/builtin/index.html

ชื่อเต็มกันชื่อชน

ส่วนเสริมของ Ansible มาเป็น Collection (ชุด module, plugin, role และ playbook ที่รวมไว้ใต้ namespace เดียว) ซึ่งรวม module, plugin, role และ playbook ไว้ใต้ Namespace (ชื่อกลุ่มหน้าสุดที่บอกว่าใครเป็นเจ้าของ collection) เดียว ชื่อเต็มของ module จึงมีสามท่อน เรียกว่า FQCN (Fully Qualified Collection Name ชื่อเต็มที่ระบุ namespace และ collection)

namespace.collection.module
ansible.builtin.copy
kubernetes.core.k8s

• เขียนชื่อสั้นอย่าง copy หรือ yum ได้ แต่ แนะนำ FQCN เพราะอ่านแล้วรู้ทันทีว่ามาจากไหน และไม่ชนกับ collection อื่น
• ansible.builtin คือ collection ของ module ที่มากับทุกการติดตั้ง

module ยังถูกจัดเป็นหมวดตามชนิดของงาน เช่น หมวด Cloud รวม module ที่สร้างและดูแลทรัพยากรบนคลาวด์ ส่วนหมวด Database รวม module ที่จัดการฐานข้อมูล

ansible-core กับ ansible

pip install ansible ในหัวข้อติดตั้งจึงได้แบบหลัง

Collection จากชุมชน

Galaxy มี role และ collection ที่ชุมชนทำไว้จำนวนมาก ทำให้ Ansible ต่อเติมได้แทบทุกงาน ใครทำ role หรือ collection ที่ติดตั้งและตั้งค่าซอฟต์แวร์ยอดนิยมได้ ก็แชร์ขึ้น Galaxy ให้คนอื่นใช้ต่อ การดาวน์โหลดจาก Galaxy ต้องใช้ ansible-core ตั้งแต่ 2.13.9 ขึ้นไป

หน้า Galaxy ยังโปรโมต Ansible Lightspeed ของ Red Hat ซึ่งใช้ generative AI (IBM watsonx Code Assistant) ช่วยเขียนงาน Ansible

ตัวอย่างคือ collection สำหรับ Kubernetes ชื่อ kubernetes.core ต้องติดตั้งสองฝั่ง

kubernetes.core เดิมชื่อ community.kubernetes ใช้จัดการแอปบน Kubernetes และ OpenShift (Kubernetes ฉบับของ Red Hat) รวมถึงสร้างและดูแลตัวคลัสเตอร์ ต้องใช้ ansible-core ตั้งแต่ 2.15.0 ขึ้นไป — เลขรุ่นแบบ 2.x ทั้งสองจุดในหัวข้อนี้เป็นของ ansible-core ส่วนแพ็กเกจ ansible นับรุ่นเป็น 8, 9, 10 module หลักของมันคือ kubernetes.core.k8s ที่เจอในหัวข้อ FQCN

ปักรุ่นของ collection

ถ้าอยากให้ทุกคนและทุกรอบที่รันได้ collection รุ่นเดียวกัน ให้ ปักรุ่นของ collection ไว้ใน requirements.yml — เหตุผลเดียวกับที่ Terraform มี .terraform.lock.hcl

---
collections:
  - name: kubernetes.core
    version: 5.0.0

Playbook — เขียนสภาพที่ต้องการลงไฟล์

playbook เขียนการตั้งค่าและการ deploy หลายเครื่องไว้เป็นไฟล์ YAML ที่ ทำซ้ำได้ ใช้ซ้ำได้ และเรียบง่าย ในไฟล์ประกาศทั้งการตั้งค่าและลำดับขั้นของการสั่งงานข้ามเครื่อง

nginx_install.yaml

---
- hosts: webservers
  become: yes
  tasks:
    - name: ensure nginx is at the latest version
      apt: name=nginx state=latest
    - name: start nginx
      service:
        name: nginx
        state: started

รายการแต่ละข้อที่ขึ้นต้นด้วย - hosts: เรียกว่า Play (ชุดงานหนึ่งชุดที่ทำกับกลุ่มเครื่องหนึ่งกลุ่ม) ข้างในมี Task (งานหนึ่งขั้นใน play ที่เรียก module หนึ่งตัว) เรียงตามลำดับ

argument ของ module ไม่ได้บอกขั้นตอนว่าต้องติดตั้งหรือเปิดยังไง มีแต่ state: ที่บอกปลายทาง ส่วน - name: บรรทัดแรกของแต่ละ task เป็นแค่ป้ายที่ Ansible พิมพ์ตอนรัน

$ ansible-playbook playbooks/nginx_install.yaml

PLAY [webservers] **************************************************************

TASK [Gathering Facts] *********************************************************
ok: [pacific]
ok: [atlantic]

TASK [ensure nginx is at the latest version] ***********************************
changed: [pacific]
changed: [atlantic]

TASK [start nginx] *************************************************************
ok: [pacific]
ok: [atlantic]

PLAY RECAP *********************************************************************
atlantic                   : ok=3    changed=1    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0
pacific                    : ok=3    changed=1    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

• Gathering Facts เป็น task ที่ Ansible แทรกให้ก่อนเสมอถ้าไม่ปิดไว้ มันเรียก module setup เก็บข้อมูลเครื่อง เช่น OS และ IP
• task ติดตั้งขึ้น changed เพราะเครื่องยังไม่มี nginx
• task เปิด service ขึ้น ok เพราะบน Debian และ Ubuntu ติดตั้ง nginx เสร็จ service ก็เปิดเองแล้ว ไม่มีอะไรต้องทำ
• PLAY RECAP สรุปต่อเครื่อง ok=3 นับทุก task ที่สำเร็จ รวมตัวที่ changed ด้วย

Idempotency

Idempotency (สั่งซ้ำกี่ครั้งผลก็เหมือนเดิม) คือ ทำสิ่งเดียวกันซ้ำหลายครั้ง แล้วยังได้ผลเหมือนเดิม คำนี้เจอมาแล้วตอนพูดถึง manifest ของ Kubernetes ใน คาบ 5

รัน nginx_install.yaml ซ้ำเป็นรอบที่สอง

TASK [ensure nginx is at the latest version] ***********************************
ok: [pacific]
ok: [atlantic]

TASK [start nginx] *************************************************************
ok: [atlantic]
ok: [pacific]

PLAY RECAP *********************************************************************
atlantic                   : ok=3    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

รอบสองได้ changed=0 เพราะ module ตรวจสภาพก่อนลงมือ nginx เป็นรุ่นล่าสุดและรันอยู่แล้ว จึงไม่ทำอะไร

นี่คือเหตุผลที่รัน playbook ได้บ่อยเท่าที่ต้องการ ครั้งแรกทำให้เครื่องเข้าที่ ครั้งต่อ ๆ ไปคือการตรวจว่ายังเข้าที่อยู่ No changes. ของ terraform plan ในส่วนที่ 3 คือคุณสมบัติเดียวกัน

$ ansible all -m ansible.builtin.shell -a "echo 'listen 8000;' >> site_shell.cfg"
my_notebook | CHANGED | rc=0 >>
$ cat site_shell.cfg
listen 8000;
listen 8000;

$ ansible all -m ansible.builtin.lineinfile -a "path=site_line.cfg line='listen 8000;' create=true"
my_notebook | SUCCESS => {
    "changed": false,
    ...
}
$ cat site_line.cfg
listen 8000;

$ ansible all -m ansible.builtin.shell -a "echo 'listen 8000;' >> site_shell.cfg"
my_notebook | CHANGED | rc=0 >>

$ ansible all -m ansible.builtin.shell -a "echo 'listen 8000;' >> site_shell.cfg"
my_notebook | CHANGED | rc=0 >>

$ cat site_shell.cfg
listen 8000;
listen 8000;

$ ansible all -m ansible.builtin.lineinfile -a "path=site_line.cfg line='listen 8000;' create=true"
my_notebook | CHANGED => {
    "backup": "",
    "changed": true,
    "msg": "line added"
}

$ ansible all -m ansible.builtin.lineinfile -a "path=site_line.cfg line='listen 8000;' create=true"
my_notebook | SUCCESS => {
    "backup": "",
    "changed": false,
    "msg": ""
}

$ cat site_line.cfg
listen 8000;

ถ้าต้องใช้ command หรือ shell ให้คิดเสมอว่ารันซ้ำแล้วจะเกิดอะไร

Playbook ที่ใช้งานจริงมากขึ้น

nginx_complex.yaml ติดตั้ง nginx แล้วเปลี่ยนให้เสิร์ฟเว็บของเราเอง

---
- hosts: webservers
  tasks:
    - name: ensure nginx is at the latest version
      apt: name=nginx state=latest
      become: yes
    - name: start nginx
      service:
        name: nginx
        state: started
      become: yes
    - name: copy the nginx config file and restat nginx
      copy:
        src: static_site.cfg
        dest: /etc/nginx/sites-available/static_site.cfg
      become: yes
    - name: Delete existing sites default
      file:
        path: /etc/nginx/sites-available/default
        state: absent
      become: yes
    - name: create symlink
      file:
        src: /etc/nginx/sites-available/static_site.cfg
        dest: /etc/nginx/sites-available/default
        state: link
      become: yes
    - name: copy the content of the web site
      copy:
        src: static-site-src/
        dest: /home/natawut/static-site
    - name: restart nginx
      service:
        name: nginx
        state: restarted
      become: yes

• ไฟล์นี้ใส่ become: yes ทีละ task แทนการใส่ทั้ง play task 6 ไม่มี become เพราะคัดลอกลงบ้านของผู้ใช้ที่ SSH เข้าไปเอง
• task 4 และ 5 ใช้โครงสร้างของ nginx บน Debian และ Ubuntu nginx อ่านไฟล์ใน sites-enabled/ และ sites-enabled/default เป็นลิงก์อยู่แล้ว หลัง task 5 nginx จึงอ่านการตั้งค่าใหม่ผ่านลิงก์สองชั้น sites-enabled/default → sites-available/default → static_site.cfg
• src ที่ลงท้ายด้วย / แปลว่าคัดลอกของข้างในโฟลเดอร์ ไม่ใช่ตัวโฟลเดอร์

server {
    listen 80 default_server;
    listen [::]:80 default_server;
    root /home/natawut/static-site;
    server_name _;
    location / {
        try_files $uri $uri/ =404;
    }
}

TASK [copy the nginx config file] **********************************************
changed: [my_notebook]
RUNNING HANDLER [restart nginx] ************************************************
ok: [my_notebook] => {
    "msg": "nginx restarts here"
}

TASK [copy the nginx config file] **********************************************
ok: [my_notebook]
my_notebook                : ok=1    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

---
- hosts: all
  gather_facts: false
  tasks:
    - name: copy the nginx config file
      ansible.builtin.copy:
        content: "listen 8000;\n"
        dest: "{{ playbook_dir }}/static_site.cfg"
      notify: restart nginx
  handlers:
    - name: restart nginx
      ansible.builtin.debug:
        msg: "nginx restarts here"

TASK [copy the nginx config file] **********************************************
changed: [my_notebook]

RUNNING HANDLER [restart nginx] ************************************************
ok: [my_notebook] => {
    "msg": "nginx restarts here"
}

PLAY RECAP *********************************************************************
my_notebook                : ok=2    changed=1    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

TASK [copy the nginx config file] **********************************************
ok: [my_notebook]

PLAY RECAP *********************************************************************
my_notebook                : ok=1    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

Variable, loop และ when

playbook มีเครื่องมือสำหรับเรื่องนี้

• variable ประกาศใน playbook ได้สามรูป คือ ค่าเดี่ยว, list และ dictionary ใส่ค่าลงไปด้วย {{ ชื่อตัวแปร }} ซึ่งเป็นไวยากรณ์ของ Jinja2 (ภาษา template ที่ Ansible ใช้แทนค่าตัวแปร)
• register (คำสั่งให้เก็บผลของ task ไว้ในตัวแปร) เก็บผลของ task ไว้ในตัวแปร ให้ task ถัดไปใช้
• loop (การวน task เดิมตามรายการ) วน task เดิมตาม list ค่าของแต่ละรอบอยู่ในตัวแปร item
• when (เงื่อนไขที่ต้องจริงก่อน task จะทำงาน) ตรวจเงื่อนไขก่อนทำ task

วนตาม list ของข้อความ — task เดียวลงสามโปรแกรม

- name: Install multiple packages
  ansible.builtin.apt:
    name: "{{ item }}"
    state: present
  loop:
    - curl
    - git
    - tmux

วนตาม list ของ dictionary — แต่ละรอบ item เป็น dictionary อ่านค่าข้างในด้วยจุด

- name: Create users with specific shells
  ansible.builtin.user:
    name: "{{ item.username }}"
    shell: "{{ item.shell }}"
    state: present
  loop:
    - { username: 'alice', shell: '/bin/bash' }
    - { username: 'bob', shell: '/bin/zsh' }

วนพร้อมเงื่อนไข — when ถูกตรวจ ทีละรอบ รอบที่ไม่ผ่านถูกข้าม

- name: Create directories only for active users
  ansible.builtin.file:
    path: "/home/{{ item.name }}/shared"
    state: directory
  loop:
    - { name: 'clara', active: true }
    - { name: 'david', active: false }
    - { name: 'emma', active: true }
  when: item.active == true

TASK [Create directories only for active users] ********************************
changed: [my_notebook] => (item={'name': 'clara', 'active': True})
skipping: [my_notebook] => (item={'name': 'david', 'active': False})
changed: [my_notebook] => (item={'name': 'emma', 'active': True})

my_notebook                : ok=5    changed=1    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

---
- hosts: all
  gather_facts: false
  vars:
    base: ./home
    web_port: 8000
    packages: [curl, git, tmux]
    site: { name: static_site, root: /home/natawut/static-site }
  tasks:
    - name: Print a simple variable and a dictionary field
      ansible.builtin.debug:
        msg: "{{ site.name }} listens on {{ web_port }}"
    - name: Iterate over a list of strings
      ansible.builtin.debug:
        msg: "install {{ item }}"
      loop: "{{ packages }}"
    - name: Create directories only for active users
      ansible.builtin.file:
        path: "{{ base }}/{{ item.name }}/shared"
        state: directory
      loop:
        - { name: 'clara', active: true }
        - { name: 'david', active: false }
        - { name: 'emma', active: true }
      when: item.active == true
    - name: Check whether clara's directory exists
      ansible.builtin.stat:
        path: "{{ base }}/clara/shared"
      register: clara_dir
    - name: Print what register captured
      ansible.builtin.debug:
        var: clara_dir.stat.isdir

PLAY [all] *********************************************************************

TASK [Print a simple variable and a dictionary field] **************************
ok: [my_notebook] => {
    "msg": "static_site listens on 8000"
}

TASK [Iterate over a list of strings] ******************************************
ok: [my_notebook] => (item=curl) => {
    "msg": "install curl"
}
ok: [my_notebook] => (item=git) => {
    "msg": "install git"
}
ok: [my_notebook] => (item=tmux) => {
    "msg": "install tmux"
}

TASK [Create directories only for active users] ********************************
changed: [my_notebook] => (item={'name': 'clara', 'active': True})
skipping: [my_notebook] => (item={'name': 'david', 'active': False})
changed: [my_notebook] => (item={'name': 'emma', 'active': True})

TASK [Check whether clara's directory exists] **********************************
ok: [my_notebook]

TASK [Print what register captured] ********************************************
ok: [my_notebook] => {
    "clara_dir.stat.isdir": true
}

PLAY RECAP *********************************************************************
my_notebook                : ok=5    changed=1    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

ok: [my_notebook] => (item={'name': 'clara', 'active': True})
skipping: [my_notebook] => (item={'name': 'david', 'active': False})
ok: [my_notebook] => (item={'name': 'emma', 'active': True})

my_notebook                : ok=5    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

ส่วนที่ 5 — ต่อทุกอย่างเข้าด้วยกัน

เลือก Terraform หรือ Ansible

ส่งต่อจาก Terraform ไป Ansible

1. Terraform อ่าน aws.tf แล้ว provision เครื่องและบริการบน AWS
2. ผลถูกจดลง state รวมถึง IP ของเครื่องและ secret
3. Ansible อ่านค่าเหล่านั้นจาก state ผ่าน collection cloud.terraform
4. Ansible ใช้ playbook configure เครื่องชุดเดียวกันนั้น

ขั้นที่ 3 ทำงานด้วย Inventory plugin (ตัวสร้าง inventory จากแหล่งข้อมูลอื่น แทนไฟล์รายชื่อที่เขียนเอง) ชื่อ cloud.terraform.terraform_state มันอ่าน state แล้วเปลี่ยน resource ที่เป็นเครื่อง เช่น aws_instance และ google_compute_instance เป็น host ใน inventory โดยมี attribute ของเครื่อง เช่น IP เป็นตัวแปรของ host นั้น ไฟล์ inventory จึงเหลือแค่บอกว่า state อยู่ที่ไหน และชื่อไฟล์ต้องลงท้ายด้วย terraform_state.yml หรือ terraform_state.yaml

plugin: cloud.terraform.terraform_state
backend_type: s3
backend_config:
  region: us-east-1
  bucket: my-sample-bucket
  key: terraform/state

ไฟล์นี้ชี้ไปที่ state ที่เก็บใน S3 bucket ทุกครั้งที่ Terraform สร้างหรือลบเครื่อง inventory ก็เปลี่ยนตามโดยไม่มีใครต้องแก้ไฟล์ ansible-inventory --graph พิมพ์ inventory ที่ได้เป็นต้นไม้ของกลุ่มและ host ผลข้างล่างย่อจากตัวอย่างในเอกสารของ plugin ซึ่งรันกับ state ที่มี aws_instance ชื่อ test หนึ่งเครื่องและใส่ --vars ด้วย ที่นี่ตัดตัวแปรออกให้เหลือเท่าที่ --graph อย่างเดียวพิมพ์ และเปลี่ยนชื่อไฟล์เป็นของหน้านี้ (ยังไม่ได้รันจริง เพราะต้องมีบัญชี AWS)

$ ansible-inventory -i aws.terraform_state.yml --graph
@all:
|--@ungrouped:
|  |--aws_instance_test

ชื่อ host มาจากชนิดกับชื่อของ resource ใส่ --vars เพิ่มจะเห็น attribute อย่าง public_ip เป็นตัวแปรของ host นั้น

output "nat_ip" {
  value = {
    for instance in google_compute_instance.default : instance.name => instance.network_interface.0.access_config.0.nat_ip
  }
}

Kubernetes มี kubectl แล้ว ทำไมยังต้องใช้ Ansible

kubectl จัดการ deployment, pod และ service ได้ครบ แต่การ deploy แอปในงานจริงมักซับซ้อนกว่านั้น

• มีหลาย deployment ต้องขึ้นพร้อมกัน Kubernetes ประกาศหลาย object ในไฟล์ YAML เดียวได้ แต่ไม่ได้คุมว่าตัวไหนต้องพร้อมก่อนตัวไหน
• ต้องตั้งค่าอุปกรณ์ network ใหม่ เช่น firewall และ router
• อาจต้องรีสตาร์ต host หรือเซิร์ฟเวอร์
• ต้องรันชุดทดสอบจากเซิร์ฟเวอร์หรือ client เครื่องอื่น

สามข้อหลังอยู่นอกคลัสเตอร์ทั้งหมด kubectl ไปไม่ถึง playbook เดียวของ Ansible เรียงงานทั้งหมดนี้ต่อกันได้ รวมถึงสั่ง Kubernetes ผ่าน kubernetes.core.k8s

GitOps

GitOps (ใช้ git เป็นแหล่งความจริงเดียวของการตั้งค่าระบบ) เอาทุกอย่างในหน้านี้มาต่อกัน

• infrastructure as code (Terraform), configuration management (Ansible) และ application code เก็บอยู่ใน git ที่เดียว git จึงเป็น source of truth ของโค้ดแบบ declarative ทั้งหมด
• การแก้โค้ดใน git สั่งให้ pipeline ทำงาน
• pipeline รันงานเป็นชุด จนสภาพของระบบที่รันจริงตรงกับที่เขียนใน git

$ git diff HEAD~1 -- main.tf
-  default = ["pacific", "arctic", "atlantic"]
+  default = ["pacific", "arctic", "atlantic", "baltic"]

$ terraform plan
  # terraform_data.server["baltic"] will be created
Plan: 1 to add, 0 to change, 0 to destroy.

$ terraform apply -auto-approve
Apply complete! Resources: 1 added, 0 changed, 0 destroyed.

$ terraform plan
No changes. Your infrastructure matches the configuration.

$ git log --oneline
225d635 Add baltic web server
046778b Create three web servers

variable "instance_set" {
  type    = list(string)
  default = ["pacific", "arctic", "atlantic", "baltic"]
}

resource "terraform_data" "server" {
  for_each = toset(var.instance_set)
  input    = "sds-${each.value}"
}

$ git diff HEAD~1 -- main.tf
diff --git a/main.tf b/main.tf
index 34b52e8..78393cb 100644
--- a/main.tf
+++ b/main.tf
@@ -1,6 +1,6 @@
 variable "instance_set" {
   type    = list(string)
-  default = ["pacific", "arctic", "atlantic"]
+  default = ["pacific", "arctic", "atlantic", "baltic"]
 }

 resource "terraform_data" "server" {

$ terraform plan
terraform_data.server["pacific"]: Refreshing state... [id=67c40bb6-09f4-fd7c-1046-3f00d7d6dd01]
terraform_data.server["atlantic"]: Refreshing state... [id=ad902833-5fd1-2759-752a-f9f898aae256]
terraform_data.server["arctic"]: Refreshing state... [id=cc7c7e24-f1ca-6521-af6c-cee079c019e5]

Terraform used the selected providers to generate the following execution
plan. Resource actions are indicated with the following symbols:
  + create

Terraform will perform the following actions:

  # terraform_data.server["baltic"] will be created
  + resource "terraform_data" "server" {
      + id     = (known after apply)
      + input  = "sds-baltic"
      + output = (known after apply)
    }

Plan: 1 to add, 0 to change, 0 to destroy.

$ terraform apply -auto-approve
terraform_data.server["baltic"]: Creation complete after 0s [id=cc3bd525-8b0e-119d-5337-28db4bcae3d4]

Apply complete! Resources: 1 added, 0 changed, 0 destroyed.

$ terraform plan
terraform_data.server["baltic"]: Refreshing state... [id=cc3bd525-8b0e-119d-5337-28db4bcae3d4]
terraform_data.server["arctic"]: Refreshing state... [id=cc7c7e24-f1ca-6521-af6c-cee079c019e5]
terraform_data.server["pacific"]: Refreshing state... [id=67c40bb6-09f4-fd7c-1046-3f00d7d6dd01]
terraform_data.server["atlantic"]: Refreshing state... [id=ad902833-5fd1-2759-752a-f9f898aae256]

No changes. Your infrastructure matches the configuration.

plan รอบถัดไปได้ No changes. ระบบจึงตรงกับ commit ล่าสุด ขั้นต่อไปของ pipeline คือรัน playbook กับ baltic โดยใช้ inventory ที่อ่านจาก state ตามหัวข้อส่งต่อจาก Terraform ไป Ansible ข้างบน