Part of 10306343 การจัดการโครงสร้างพื้นฐานและการส่งมอบซอฟต์แวร์อย่างต่อเนื่อง (Development Operations: DevOps)

บทที่ 1 วัฒนธรรม DevOps และ Linux ที่จำเป็น: สิทธิ์ไฟล์ การค้นหาใน log และ exit status

ภาพรวมของบท

บทนี้ปูพื้นสองเรื่องที่คุณจะใช้ตลอดวิชา เรื่องแรกคือแนวคิดของ DevOps ว่าทำไมทีมพัฒนากับทีมดูแลระบบต้องทำงานร่วมกัน และวัดผลการส่งมอบซอฟต์แวร์อย่างไร เรื่องที่สองคือ Linux ที่จำเป็น ได้แก่ โครงสร้างไดเรกทอรี สิทธิ์ไฟล์ การค้นหาใน log และ exit status ของคำสั่ง

ทำไมเรื่องนี้สำคัญ: เครื่องมือ DevOps เกือบทุกตัวในวิชานี้ทำงานบน Linux ไม่ว่าจะเป็น Git, GitHub Actions runner, Docker หรือเซิร์ฟเวอร์ปลายทาง ถ้าคุณตั้งสิทธิ์ไฟล์ผิด รหัสผ่านอาจรั่ว ถ้าอ่าน log ไม่เป็น คุณจะหาสาเหตุไม่เจอเมื่อระบบพัง และถ้าไม่เข้าใจ exit status คุณจะไม่เข้าใจว่าทำไม pipeline ผ่านหรือไม่ผ่าน

ความเชื่อมโยงกับบทอื่น: บทนี้เป็นบทแรก จึงไม่มีบทก่อนหน้าในวิชานี้ รายวิชาที่คุณเรียนมาแล้วสอน JavaScript การทดสอบ ฐานข้อมูล และเครือข่าย แต่ไม่มีวิชาใดสอนการใช้ Linux ผ่าน Terminal บทนี้จึงเริ่มจากศูนย์ สิ่งที่คุณทำในบทนี้จะถูกใช้ต่อดังนี้

ผลลัพธ์การเรียนรู้

เมื่อจบบท คุณต้องทำสิ่งต่อไปนี้ได้ และแต่ละข้อมีงานที่ใช้วัดผล

CLO ที่เกี่ยวข้อง (ข้อความจากหลักสูตร):

• CLO3 ใช้เครื่องมือดิจิทัลอย่างเหมาะสมเพื่อพัฒนาระบบ และสามารถเรียนรู้และปรับตัวด้วยตนเองจากแหล่งข้อมูลที่เชื่อถือได้
• CLO4 ผู้เรียนแสดงออกถึงความรับผิดชอบและความใฝ่รู้ในการเรียนรู้เทคโนโลยีและเครื่องมือใหม่ที่เกี่ยวข้องกับ DevOps โดยศึกษาค้นคว้าด้วยตนเองจากแหล่งข้อมูลที่เชื่อถือได้ และปฏิบัติตามแนวปฏิบัติด้านความปลอดภัยและคุณภาพของระบบ

แนวคิด CAMS และ DORA metrics ในส่วนที่ 1 เป็นพื้นความรู้ของวิชา ไม่ได้วัดเป็น CLO ในบทนี้ คุณจะใช้ DORA metrics จริงในบทที่ 12

ก่อนเริ่ม: ความรู้พื้นฐาน เครื่องมือ และรุ่นซอฟต์แวร์

ความรู้พื้นฐาน: ใช้คอมพิวเตอร์และแก้ไฟล์ข้อความได้ ไม่ต้องเคยใช้ Linux มาก่อน

สิ่งที่ต้องมี: เครื่อง Ubuntu (เครื่องในห้องแลบหรือ VM) ที่เปิด Terminal ได้ และบัญชีของคุณใช้คำสั่ง sudo ได้ ห้ามทำ Lab ด้วยบัญชี root โดยตรง เพราะ root ข้ามการตรวจสิทธิ์ไฟล์ได้ คุณจะไม่เห็นผลของสิทธิ์ที่ตั้ง

รุ่นซอฟต์แวร์ที่ใช้ทดสอบ: ทุกคำสั่งและผลลัพธ์ในบทนี้ทดสอบแล้วบนรุ่นต่อไปนี้ โดยรันในฐานะผู้ใช้ทั่วไปที่ใช้ sudo ได้

ถ้าเครื่องของคุณใช้รุ่นอื่น ผลส่วนใหญ่จะเหมือนเดิม แต่ข้อความผิดพลาดบางบรรทัดอาจต่างเล็กน้อย

ค่าใช้จ่ายและข้อมูลลับ: บทนี้ทำบนเครื่องของคุณทั้งหมด ไม่ใช้บริการคลาวด์ จึงไม่มีค่าใช้จ่าย รหัสผ่านในบทนี้เป็นค่าสมมติ (change-me) ห้ามใส่รหัสผ่านจริงลงในไฟล์ฝึก ผู้ใช้และโฟลเดอร์ทดลองที่สร้างขึ้นต้องลบตามขั้นตอนท้ายส่วนที่ 2

ส่วนที่ 1 บรรยาย

แต่ละหัวข้อมีตัวอย่างที่ยากขึ้นทีละระดับ และจบด้วยคำถามตรวจความเข้าใจ ให้ตอบในใจหรือคุยกับเพื่อนข้าง ๆ ก่อนไปหัวข้อถัดไป

1.1 DevOps คืออะไร

DevOps คือวิธีทำงานที่ให้คนเขียนโปรแกรมกับคนดูแลระบบร่วมกันรับผิดชอบซอฟต์แวร์ตั้งแต่เขียนจนถึงใช้งานจริง มาตรฐาน ISO/IEC/IEEE 32675:2022 กำหนดแนวทางใช้ DevOps กับวงจรชีวิตซอฟต์แวร์ ครอบคลุมทั้งการ build การ package และการ deploy ให้ระบบเชื่อถือได้และปลอดภัย (ISO)

คำถามตรวจความเข้าใจ 1.1: ถ้าทีมพัฒนาส่งโค้ดให้ทีมดูแลระบบแล้วไม่สนใจต่อว่ารันได้หรือไม่ ทีมนี้ทำตามแนวคิด DevOps หรือไม่ เพราะอะไร

1.2 หัวใจของ DevOps: CAMS

John Willis สรุปหัวใจของ DevOps ไว้ในปี 2010 เป็นคำย่อ CAMS (Chef Blog)

คำถามตรวจความเข้าใจ 1.2: "ทีมเขียนสคริปต์ให้ทดสอบโค้ดทุกครั้งที่มีคนส่งงาน" ตรงกับตัวอักษรใดของ CAMS

1.3 วัดผลการส่งมอบด้วย DORA metrics

ตัว M ใน CAMS ต้องมีตัวเลขที่วัดได้ ทีมวิจัย DORA ใช้ตัวชี้วัด 5 ตัวกับประสิทธิภาพการส่งมอบซอฟต์แวร์ (DORA)

ตัวอย่าง: ทีมหนึ่ง deploy 4 ครั้งในสัปดาห์นี้ และมี 1 ครั้งที่ต้องแก้ทันทีหลังขึ้นระบบ Deployment frequency คือ 4 ครั้งต่อสัปดาห์ และ Change fail rate คือ 1 ÷ 4 = 25%

คุณจะใช้ตัวชี้วัดเหล่านี้รายงานผลงานในบทที่ 12

คำถามตรวจความเข้าใจ 1.3: ถ้าทีมอยากรู้ว่า "แก้บั๊กแล้วกว่าจะถึงมือผู้ใช้ใช้เวลานานแค่ไหน" ควรดูตัวชี้วัดใด

1.4 เส้นทางของวิชา

ทุกบทใช้แอป Node.js ตัวเดียวกันต่อยอดไปเรื่อย ๆ ตั้งแต่เก็บโค้ดด้วย Git, ทดสอบอัตโนมัติด้วย GitHub Actions, บรรจุลง Docker, deploy ขึ้นเซิร์ฟเวอร์ ไปจนถึงสแกนความปลอดภัยและเฝ้าดูระบบ งานของแต่ละบทจะสะสมไปเป็นโครงงานสุดท้าย (Capstone) ในสัปดาห์ที่ 13 ลำดับบททั้งหมดอยู่ที่ หน้ารวมรายวิชา 10306343

1.5 โครงสร้างไดเรกทอรีของ Linux

ไดเรกทอรีหลักของ Linux จัดตามมาตรฐาน Filesystem Hierarchy Standard 3.0 (FHS 3.0)

เวลาแอปมีปัญหา ที่แรกที่คุณควรดูคือ /var/log ส่วนเวลาจะแก้ค่าตั้งของบริการ ให้ดูที่ /etc

คำถามตรวจความเข้าใจ 1.5: ไฟล์ค่าตั้งของ Nginx ซึ่งคุณจะใช้ในบทที่ 9 ควรอยู่ใต้ไดเรกทอรีใด

1.6 ผู้ใช้ กลุ่ม และสิทธิ์ไฟล์

ทุกไฟล์มีเจ้าของ (user) และกลุ่ม (group) สิทธิ์แบ่งเป็น 3 ชุด คือ เจ้าของ กลุ่ม และคนอื่น (others) แต่ละชุดมีสิทธิ์ 3 อย่าง (GNU Coreutils)

ระดับ 1 อ่านสิทธิ์: rwxr-x--- แบ่งเป็นสามชุด คือ เจ้าของ rwx กลุ่ม r-x คนอื่น ---

ระดับ 2 แปลงเป็นตัวเลข: ตัวเลขแต่ละหลักคือผลบวกของค่าเลข เช่น 7 = 4 + 2 + 1 = rwx และ 5 = 4 + 1 = r-x ดังนั้น rwxr-x--- คือ 750 (GNU Coreutils)

ระดับ 3 เลือกสิทธิ์ให้ตรงสถานการณ์: "สคริปต์ที่เจ้าของแก้และรันได้ คนในกลุ่มรันได้แต่ห้ามแก้ คนอื่นห้ามยุ่ง" → เจ้าของ rwx (7) กลุ่ม r-x (5) คนอื่น --- (0) = 750

หลักที่ใช้ตัดสินว่าควรให้สิทธิ์เท่าไรคือ หลักให้สิทธิ์เท่าที่จำเป็น (principle of least privilege) ซึ่ง NIST นิยามว่าให้จำกัดสิทธิ์ของผู้ใช้และโปรแกรม "to the minimum necessary to accomplish assigned tasks" (NIST) คุณจะใช้หลักนี้อีกครั้งตอนเก็บรหัสผ่านใน GitHub Secrets ในบทที่ 10

คำถามตรวจความเข้าใจ 1.6: rw-r----- เป็นตัวเลขอะไร และคนในกลุ่มแก้ไฟล์นี้ได้หรือไม่

1.7 exit status: คำสั่งบอกผลสำเร็จหรือล้มเหลว

ระดับ 1: ทุกคำสั่งใน Linux จบด้วยตัวเลขที่เรียกว่า exit status ค่า 0 หมายถึงสำเร็จ ค่าอื่นทุกค่าหมายถึงล้มเหลว และดูค่าของคำสั่งล่าสุดได้จากตัวแปร $? ถ้าสั่งรันไฟล์ที่ไม่มีสิทธิ์รัน bash จะคืนค่า 126 (GNU Bash)

ระดับ 2: แต่ละคำสั่งกำหนดความหมายของตัวเลขเอง เช่น grep คืน 0 เมื่อเจอบรรทัดที่ค้นหา 1 เมื่อไม่เจอ และ 2 เมื่อเกิดข้อผิดพลาด เช่น ไม่มีไฟล์ (GNU Grep)

ระดับ 3: ใช้ exit status ตัดสินใจว่าจะทำคำสั่งถัดไปหรือไม่ คำสั่ง1 && คำสั่ง2 รันคำสั่ง 2 เมื่อคำสั่ง 1 สำเร็จเท่านั้น ส่วน คำสั่ง1 || คำสั่ง2 รันคำสั่ง 2 เมื่อคำสั่ง 1 ล้มเหลวเท่านั้น (GNU Bash)

เรื่องนี้สำคัญกับ DevOps เพราะระบบ CI ในบทที่ 5 ตัดสินว่า pipeline ผ่านหรือไม่ผ่านจาก exit status ของแต่ละคำสั่ง ใน Lab E คุณจะเขียนสคริปต์ที่ตอบ 0, 1 หรือ 2 เอง

คำถามตรวจความเข้าใจ 1.7: grep -q CRITICAL app.log || echo "ไม่พบ" จะพิมพ์คำว่า "ไม่พบ" เมื่อไร

1.8 ต่อคำสั่งด้วย pipe

เครื่องหมาย | (pipe) ส่งผลของคำสั่งทางซ้ายไปเป็นข้อมูลเข้าของคำสั่งทางขวา ทำให้ต่อเครื่องมือเล็ก ๆ เป็นงานใหญ่ได้

• ระดับ 1: grep ERROR app.log เลือกเฉพาะบรรทัดที่มีคำว่า ERROR
• ระดับ 2: grep ERROR app.log | grep -o "/api/[a-z]*" เลือกบรรทัด ERROR แล้วตัดเอาเฉพาะ path
• ระดับ 3: ... | sort | uniq -c เรียงแล้วนับว่าแต่ละ path ซ้ำกี่ครั้ง ต้อง sort ก่อน เพราะ uniq ตรวจเฉพาะบรรทัดที่ซ้ำกันและอยู่ติดกัน (GNU Coreutils)

คำถามตรวจความเข้าใจ 1.8: ถ้าตัด sort ออกจากระดับ 3 ผลจะผิดอย่างไร (คุณจะได้ทดลองจริงใน Lab C.6)

ส่วนที่ 2 ปฏิบัติ

ทุก Lab มีสองช่วง ฝึกตามตัวอย่าง ให้พิมพ์คำสั่งตามและเทียบผล ส่วน ตัดสินใจเอง ไม่มีคำสั่งให้ คุณต้องเลือกคำสั่งหรือหาสาเหตุเอง

Lab A: สำรวจเครื่อง

สถานการณ์: คุณได้รับเครื่อง Ubuntu เครื่องใหม่ และต้องรู้ว่าไฟล์สำคัญอยู่ที่ไหนก่อนเริ่มงาน

เป้าหมาย: ระบุตำแหน่งของ /etc, /home, /tmp, /usr, /var และ /var/log จากผลของคำสั่งจริง (พื้นฐานสำหรับ Lab B–E ไม่นับ CLO)

ฝึกตามตัวอย่าง

ls /
ls /var/log | head -5
head -2 /etc/os-release

ผลลัพธ์ที่คาดหวัง (สองคำสั่งหลัง)

README
alternatives.log
apt
bootstrap.log
btmp
PRETTY_NAME="Ubuntu 24.04.5 LTS"
NAME="Ubuntu"

จุดตรวจ A: เทียบผลของ ls / กับตารางในหัวข้อ 1.5 แล้วชี้ได้ว่าไดเรกทอรีทั้งหกอยู่ตรงไหน

ตัดสินใจเอง A: ไฟล์ 3 อย่างต่อไปนี้ควรอยู่ใต้ไดเรกทอรีใด (1) ไฟล์ค่าตั้งของบริการเว็บ (2) log ของการติดตั้งแพ็กเกจด้วย apt (3) ไฟล์ที่ทิ้งได้หลังเปิดเครื่องใหม่ แล้วใช้ ls ยืนยันข้อ 2 บนเครื่องของคุณ

ปัญหาที่พบบ่อย

Lab B: สิทธิ์ไฟล์

สถานการณ์: ทีมของคุณมีสคริปต์และไฟล์รหัสผ่านฐานข้อมูลบนเซิร์ฟเวอร์ที่หลายคนใช้ร่วมกัน คุณต้องตั้งสิทธิ์ให้สคริปต์รันได้ และไม่ให้คนอื่นอ่านรหัสผ่าน

เป้าหมาย: LLO 1.1 ตั้งสิทธิ์ตามสถานการณ์ และ LLO 1.3 ปกป้องไฟล์ความลับ

ฝึกตามตัวอย่าง

B.1 สร้างโฟลเดอร์และไฟล์

cd ~
mkdir -p devops-lab01
cd devops-lab01
printf '#!/bin/bash\necho "Hello DevOps"\n' > hello.sh
echo "DB_PASSWORD=change-me" > .env
ls -l

total 4
-rw-rw-r-- 1 student student 32 Oct 17 14:41 hello.sh

คุณจะเห็นแค่ hello.sh เพราะไฟล์ที่ชื่อขึ้นต้นด้วยจุด เช่น .env เป็นไฟล์ซ่อน ต้องใช้ ls -la จึงจะเห็น

คอลัมน์ของ ls -l เรียงเป็น ชนิดไฟล์กับสิทธิ์, จำนวน hard link, เจ้าของ, กลุ่ม, ขนาด (ไบต์), เวลาแก้ไข และชื่อไฟล์ (GNU Coreutils) ตัวแรกบอกชนิดไฟล์ (- คือไฟล์ปกติ, d คือไดเรกทอรี) อีก 9 ตัวคือสิทธิ์ของเจ้าของ กลุ่ม และคนอื่น ตามลำดับ

B.2 ทำให้สคริปต์รันได้

./hello.sh
echo "exit=$?"

bash: ./hello.sh: Permission denied
exit=126

exit status 126 หมายถึงพบไฟล์แต่ไฟล์ไม่มีสิทธิ์รัน (หัวข้อ 1.7)

chmod 755 hello.sh
./hello.sh

Hello DevOps

B.3 ป้องกันไฟล์ความลับ

chmod 600 .env
ls -la

total 16
drwxrwxr-x 2 student student 4096 Oct 17 14:41 .
drwxr-x--- 3 student student 4096 Oct 17 14:41 ..
-rw------- 1 student student   22 Oct 17 14:41 .env
-rwxr-xr-x 1 student student   32 Oct 17 14:41 hello.sh

B.4 ตรวจสิทธิ์เป็นตัวเลข

stat แสดงสิทธิ์เป็นเลขฐานแปดได้ ใช้ตรวจงานของตัวเองได้เร็วกว่าการอ่าน rwx

stat -c "%a %U %G %n" hello.sh .env

755 student student hello.sh
600 student student .env

จุดตรวจ B.1–B.4: stat ต้องแสดง 755 สำหรับ hello.sh และ 600 สำหรับ .env

ตัดสินใจเอง

B.5 ตั้งสิทธิ์ตามสถานการณ์ (LLO 1.1): สร้างไฟล์ตามตารางนี้ด้วย touch แล้วเลือกสิทธิ์เอง จากนั้นตรวจด้วย stat -c "%a %n"

B.6 พิสูจน์ความเสี่ยงของ .env บนเครื่องที่ใช้ร่วมกัน (LLO 1.3): โฟลเดอร์ home ของ Ubuntu 24.04 สร้างด้วยสิทธิ์ 750 คนอื่นจึงเข้าไม่ถึงอยู่แล้ว แต่ไฟล์ของบริการบนเซิร์ฟเวอร์มักอยู่ใน /srv ซึ่งทุกคนเข้าถึงได้ ให้สร้างโฟลเดอร์จำลองแล้วทดสอบด้วยผู้ใช้ nobody ซึ่งเป็นผู้ใช้ที่ไม่มีสิทธิ์พิเศษที่มีอยู่แล้วในเครื่อง

sudo mkdir -p /srv/app
sudo chown $USER:$USER /srv/app
echo "DB_PASSWORD=change-me" > /srv/app/.env
chmod 644 /srv/app/.env
sudo -u nobody cat /srv/app/.env
echo "exit=$?"

จากผลที่ได้ ให้คุณตัดสินใจเองว่าต้องแก้สิทธิ์เป็นเท่าไร แล้วรัน sudo -u nobody cat /srv/app/.env ซ้ำเพื่อพิสูจน์ว่าแก้สำเร็จ

ผลลัพธ์ที่คาดหวัง B.6: ก่อนแก้ nobody อ่านรหัสผ่านได้และ exit เป็น 0 หลังแก้ต้องขึ้น Permission denied และ exit ไม่ใช่ 0

ปัญหาที่พบบ่อย

เฉลยจะเปิดในชั้นเรียนหลังทุกคนทำเสร็จ

Lab C: ค้นหาข้อมูลใน log

สถานการณ์: ผู้ใช้แจ้งว่าสั่งซื้อสินค้าไม่ได้ คุณได้ log ของแอปมา 1 ไฟล์ และต้องหาว่าปัญหาอยู่ที่ส่วนใด

เป้าหมาย: LLO 1.2 ใช้ grep, sort และ uniq หาบรรทัดผิดพลาดและนับข้อมูลตามเงื่อนไข

ฝึกตามตัวอย่าง

C.1 สร้างไฟล์ log ตัวอย่าง คัดลอกคำสั่งนี้ไปวางทั้งก้อน

cd ~/devops-lab01
cat > app.log <<'EOF'
2026-10-17 09:00:01 INFO GET /api/users 200 12ms
2026-10-17 09:00:05 INFO GET /api/products 200 30ms
2026-10-17 09:01:10 ERROR GET /api/orders 500 1200ms
2026-10-17 09:02:00 INFO POST /api/login 200 45ms
2026-10-17 09:02:30 WARN GET /api/products 200 950ms
2026-10-17 09:03:15 ERROR POST /api/orders 500 1500ms
2026-10-17 09:04:00 INFO GET /health 200 2ms
2026-10-17 09:05:42 INFO GET /api/users 404 8ms
2026-10-17 09:06:10 ERROR GET /api/orders 500 1100ms
2026-10-17 09:07:00 INFO GET /health 200 3ms
2026-10-17 09:08:20 INFO GET /api/products 200 28ms
2026-10-17 09:09:05 INFO POST /api/login 401 20ms
EOF

แต่ละบรรทัดคือ วันเวลา ระดับ (INFO, WARN, ERROR) method path รหัสสถานะ HTTP และเวลาที่ใช้

C.2 นับบรรทัดและดูท้ายไฟล์

wc -l app.log
tail -n 3 app.log

12 app.log
2026-10-17 09:07:00 INFO GET /health 200 3ms
2026-10-17 09:08:20 INFO GET /api/products 200 28ms
2026-10-17 09:09:05 INFO POST /api/login 401 20ms

ถ้าไม่ใส่ -n คำสั่ง tail จะแสดง 10 บรรทัดสุดท้าย

C.3 หาบรรทัดที่ผิดพลาดด้วย grep

grep พิมพ์บรรทัดที่ตรงกับรูปแบบที่ค้นหา (GNU Grep)

grep ERROR app.log
grep -c ERROR app.log
grep -n " 500 " app.log

2026-10-17 09:01:10 ERROR GET /api/orders 500 1200ms
2026-10-17 09:03:15 ERROR POST /api/orders 500 1500ms
2026-10-17 09:06:10 ERROR GET /api/orders 500 1100ms
3
3:2026-10-17 09:01:10 ERROR GET /api/orders 500 1200ms
6:2026-10-17 09:03:15 ERROR POST /api/orders 500 1500ms
9:2026-10-17 09:06:10 ERROR GET /api/orders 500 1100ms

grep -v INFO app.log

2026-10-17 09:01:10 ERROR GET /api/orders 500 1200ms
2026-10-17 09:02:30 WARN GET /api/products 200 950ms
2026-10-17 09:03:15 ERROR POST /api/orders 500 1500ms
2026-10-17 09:06:10 ERROR GET /api/orders 500 1100ms

C.4 นับ request แยกตาม path

grep -o "/api/[a-z]*" app.log | sort | uniq -c

      2 /api/login
      3 /api/orders
      3 /api/products
      2 /api/users

จากผลใน C.3 และ C.4 คุณบอกได้ว่าปัญหาอยู่ที่ /api/orders ซึ่งถูกเรียก 3 ครั้งและตอบ 500 ทั้ง 3 ครั้ง

C.5 แก้ข้อความใน log ด้วย sed

sed แทนที่ข้อความด้วยรูปแบบ s/สิ่งที่หา/สิ่งที่แทน/ (GNU sed) คำสั่งแรกแสดงผลบนจอเท่านั้น ไฟล์เดิมไม่เปลี่ยน

sed "s/ERROR/[ERROR]/" app.log | head -3

2026-10-17 09:00:01 INFO GET /api/users 200 12ms
2026-10-17 09:00:05 INFO GET /api/products 200 30ms
2026-10-17 09:01:10 [ERROR] GET /api/orders 500 1200ms

ถ้าต้องการแก้ไฟล์จริง ใช้ -i และใส่นามสกุลไฟล์สำรองต่อท้ายเสมอ

sed -i.bak "s/INFO/[INFO]/" app.log
head -2 app.log
head -2 app.log.bak

2026-10-17 09:00:01 [INFO] GET /api/users 200 12ms
2026-10-17 09:00:05 [INFO] GET /api/products 200 30ms
2026-10-17 09:00:01 INFO GET /api/users 200 12ms
2026-10-17 09:00:05 INFO GET /api/products 200 30ms

จุดตรวจ C.1–C.5: grep -c ERROR app.log.bak ต้องได้ 3 และ app.log.bak ต้องยังเป็นข้อความเดิมที่ไม่มีวงเล็บ

ตัดสินใจเอง C.6 (LLO 1.2): ใช้ app.log.bak และเขียนคำสั่งเองเพื่อตอบ 3 ข้อ

1. มี request ที่ตอบด้วยรหัส 4xx (ขึ้นต้นด้วย 4) กี่ครั้ง และเป็น path ใด
2. path ใดบ้างที่เกิด ERROR และแต่ละ path เกิดกี่ครั้ง (ใช้คำสั่งเดียวต่อด้วย pipe)
3. รัน grep -o "/api/[a-z]*" app.log.bak | uniq -c (ไม่มี sort) แล้วอธิบายว่าทำไมผลต่างจาก C.4

ปัญหาที่พบบ่อย

เฉลยจะเปิดในชั้นเรียนหลังทุกคนทำเสร็จ

Lab D: โฟลเดอร์ทีมด้วยกลุ่ม

สถานการณ์: ทีมพัฒนาต้องใช้โฟลเดอร์ร่วมกันบนเซิร์ฟเวอร์ alice อยู่ในทีม ส่วน bob ยังไม่อยู่ คุณต้องตั้งโฟลเดอร์ให้เฉพาะคนในทีมเขียนได้ และทุกคนในทีมแก้ไฟล์ของกันและกันได้

เป้าหมาย: LLO 1.1 ตั้งเจ้าของ กลุ่ม และสิทธิ์ของโฟลเดอร์ให้ตรงสถานการณ์

ฝึกตามตัวอย่าง

D.1 สร้างกลุ่มและผู้ใช้ทดลอง

sudo groupadd devteam
sudo useradd -m -s /bin/bash alice
sudo useradd -m -s /bin/bash bob
sudo usermod -aG devteam alice
id alice
id bob

uid=30035(alice) gid=30036(alice) groups=30036(alice),30035(devteam)
uid=30036(bob) gid=30037(bob) groups=30037(bob)

alice มีกลุ่ม devteam เพิ่ม ส่วน bob ไม่มี ตัวเลือก -a ของ usermod หมายถึงเพิ่มกลุ่มต่อท้าย ถ้าลืม -a รายการกลุ่มเสริมของผู้ใช้จะถูกแทนด้วยรายการใหม่ทั้งหมด

D.2 สร้างโฟลเดอร์ทีม

sudo mkdir -p /srv/project
sudo chown root:devteam /srv/project
sudo chmod 770 /srv/project
ls -ld /srv/project

drwxrwx--- 2 root devteam 4096 Oct 17 21:52 /srv/project

รูปแบบคำสั่งคือ chown เจ้าของ:กลุ่ม ไฟล์ สิทธิ์ 770 ให้เจ้าของและกลุ่ม rwx แต่คนอื่นไม่มีสิทธิ์เลย

D.3 ทดสอบในฐานะผู้ใช้แต่ละคน

sudo -u ชื่อผู้ใช้ รันคำสั่งในฐานะผู้ใช้คนนั้น

sudo -u alice touch /srv/project/report.txt
echo "exit=$?"
sudo -u bob touch /srv/project/report.txt
echo "exit=$?"
sudo ls -l /srv/project

exit=0
touch: cannot touch '/srv/project/report.txt': Permission denied
exit=1
total 0
-rw-rw-r-- 1 alice alice 0 Oct 17 21:52 report.txt

alice เขียนได้เพราะอยู่ในกลุ่ม devteam ส่วน bob ถูกปฏิเสธเพราะตกอยู่ในชุด "คนอื่น"

จุดตรวจ D.3: มี exit=0 ของ alice และ exit=1 ของ bob

ตัดสินใจเอง D.4 (LLO 1.1): หัวหน้าทีมให้ bob เข้าทีม ให้คุณเพิ่ม bob เข้ากลุ่ม devteam เอง แล้วทดสอบว่า bob เขียนต่อท้าย report.txt ได้หรือไม่

sudo -u bob sh -c 'echo "bob was here" >> /srv/project/report.txt'
echo "exit=$?"

คุณจะพบว่า bob ยังเขียนไม่ได้ ทั้งที่อยู่ในกลุ่มแล้ว ให้หาสาเหตุจากผลของ sudo ls -l /srv/project แล้วแก้ให้ได้ 2 ระดับ

1. แก้ไฟล์ report.txt ที่มีอยู่ให้ bob เขียนได้
2. ตั้งโฟลเดอร์ให้ไฟล์ที่สร้างใหม่ต่อจากนี้ใช้กลุ่ม devteam โดยอัตโนมัติ (คำใบ้: อ่านเรื่อง set-group-ID bit ของไดเรกทอรีใน GNU Coreutils)

พิสูจน์ข้อ 2 โดยให้ alice สร้าง plan.txt แล้วให้ bob เขียนต่อท้ายไฟล์นั้น

ผลลัพธ์ที่คาดหวัง D.4: bob เขียนทั้ง report.txt และ plan.txt ได้ด้วย exit=0 และ ls -ld /srv/project แสดงตัว s ในชุดสิทธิ์ของกลุ่ม

ปัญหาที่พบบ่อย

เฉลยจะเปิดในชั้นเรียนหลังทุกคนทำเสร็จ

Lab E: สคริปต์ตรวจ log

สถานการณ์: ทีมอยากให้เครื่องตรวจ log แทนคน ถ้าเจอ ERROR ให้ถือว่า "ไม่ผ่าน" แบบเดียวกับที่ CI จะตัดสินในบทที่ 5

เป้าหมาย: เขียนสคริปต์ที่บอกผลด้วย exit status ตามเงื่อนไข (เตรียมพื้นสำหรับบทที่ 5 ไม่นับ CLO)

ฝึกตามตัวอย่าง

E.1 สร้างสคริปต์ คัดลอกทั้งก้อน

cd ~/devops-lab01
cat > check-errors.sh <<'EOF'
#!/bin/bash
LOG_FILE="$1"
COUNT=$(grep -c ERROR "$LOG_FILE")
echo "พบ ERROR $COUNT บรรทัดใน $LOG_FILE"
if [ "$COUNT" -gt 0 ]; then
  exit 1
fi
exit 0
EOF
chmod 755 check-errors.sh

$1 คือชื่อไฟล์ที่ส่งเข้าสคริปต์ และ $(...) เก็บผลของคำสั่งไว้ในตัวแปร

E.2 ทดสอบกับ log ที่มี ERROR และไม่มี ERROR

grep -v ERROR app.log.bak > clean.log
./check-errors.sh app.log.bak
echo "exit status = $?"
./check-errors.sh clean.log
echo "exit status = $?"

พบ ERROR 3 บรรทัดใน app.log.bak
exit status = 1
พบ ERROR 0 บรรทัดใน clean.log
exit status = 0

จุดตรวจ E.2: exit status เป็น 1 กับไฟล์ที่มี ERROR และ 0 กับไฟล์ที่ไม่มี

ตัดสินใจเอง E.3: ทดสอบสคริปต์กับไฟล์ที่ไม่มีอยู่จริง

./check-errors.sh missing.log
echo "exit status = $?"

สคริปต์บอกว่า "ผ่าน" ทั้งที่ไม่มีไฟล์ให้ตรวจเลย ซึ่งอันตรายมากถ้าอยู่ใน CI เพราะ pipeline จะผ่านโดยไม่ได้ตรวจอะไร ให้คุณ

1. อธิบายว่าทำไมได้ exit status 0 (ดูข้อความผิดพลาดที่ขึ้นทีละบรรทัด)
2. แก้สคริปต์ให้จบด้วย exit status 2 เมื่อไม่พบไฟล์ โดยยังให้ผลเดิมกับไฟล์ที่มีอยู่
3. ทดสอบให้ครบ 3 กรณี: missing.log, app.log.bak และ clean.log

ผลลัพธ์ที่คาดหวัง E.3: exit status เป็น 2, 1 และ 0 ตามลำดับ

ปัญหาที่พบบ่อย

เฉลยจะเปิดในชั้นเรียนหลังทุกคนทำเสร็จ

เก็บกวาดเมื่อจบ Lab

ลบผู้ใช้ กลุ่ม และโฟลเดอร์ทดลองทั้งหมดที่สร้างใน Lab B และ D

sudo rm -rf /srv/project /srv/app
sudo userdel -r alice
sudo userdel -r bob
sudo groupdel devteam
id alice

id: ‘alice’: no such user

ถ้าเห็นข้อความ mail spool ... not found ตอนลบผู้ใช้ ไม่ต้องกังวล หมายถึงผู้ใช้นั้นไม่มีกล่องจดหมายในเครื่อง ให้เก็บโฟลเดอร์ ~/devops-lab01 ไว้ เพราะต้องใช้ส่งงานและใช้ต่อในบทที่ 2

แบบฝึกหัด

ทำข้อ ก1–ก2 และ ข1 ในชั้นเรียนถ้ามีเวลาเหลือ ข้อที่เหลือทำในเวลาศึกษาด้วยตนเอง ทุกข้อระบุผลลัพธ์การเรียนรู้ที่ฝึก

ก. ความเข้าใจ

• ก1 (LLO 1.1) แปลงสิทธิ์เป็นตัวเลข: rwxr-x---, rw-r-----, rwx------, r--r--r--
• ก2 (LLO 1.1) สิทธิ์ x ของไดเรกทอรีต่างจากสิทธิ์ x ของไฟล์อย่างไร
• ก3 (พื้นความรู้ ไม่นับ CLO) ทีมหนึ่ง deploy 10 ครั้งใน 2 สัปดาห์ และมี 2 ครั้งที่ต้องแก้ทันทีหลังขึ้นระบบ คำนวณ Deployment frequency ต่อสัปดาห์และ Change fail rate
• ก4 (เตรียมพื้น) บอก exit status ของ grep -q ERROR app.log.bak, grep -q CRITICAL app.log.bak และ grep ERROR nofile.log

ข. การประยุกต์

• ข1 (LLO 1.1) เลือกสิทธิ์ให้: (1) ไฟล์ log ที่บริการเขียนได้ คนในกลุ่มอ่านได้ คนอื่นห้ามเห็น (2) โฟลเดอร์ที่ทุกคนเข้าไปอ่านไฟล์ได้ แต่สร้างไฟล์ได้เฉพาะเจ้าของ
• ข2 (LLO 1.2) เขียนคำสั่งเดียวนับจำนวนบรรทัดที่เป็น ERROR หรือ WARN ใน app.log.bak
• ข3 (LLO 1.2) เขียนคำสั่งที่พิมพ์ "ระบบปกติ" ถ้า clean.log ไม่มี ERROR โดยใช้ grep -q กับ ||

ค. การวิเคราะห์ปัญหา

• ค1 (LLO 1.1) เพื่อนรัน ./deploy.sh แล้วได้ Permission denied และ echo $? ได้ 126 บอกสาเหตุที่เป็นไปได้ คำสั่งที่ใช้ตรวจ และวิธีแก้
• ค2 (LLO 1.2) เพื่อนใช้ grep -c " 200 " app.log หลังจากรัน C.5 แล้วได้ผลตรงกับ app.log.bak แต่ใช้ grep -c "INFO GET" app.log แล้วได้ 0 อธิบายสาเหตุ
• ค3 (LLO 1.3) เพื่อนบอกว่า ".env อยู่ในโฟลเดอร์ home ซึ่งเป็น 750 อยู่แล้ว ไม่ต้องตั้ง 600 ก็ได้" คุณเห็นด้วยหรือไม่ ให้เหตุผลโดยคิดถึงตอนที่ไฟล์ถูกย้ายไปเซิร์ฟเวอร์จริง

ส่วนที่ 3 ศึกษาด้วยตนเอง

1. อ่านบทความ What DevOps means to me และหน้า DORA metrics แล้วสรุปเป็นภาษาของคุณเองอย่างละ 5 บรรทัด
2. ทำแบบฝึกหัดที่เหลือ และทำ Lab C ซ้ำโดยไม่ดูคำสั่ง
3. เขียนงานที่ต้องส่งให้ครบ
4. เขียน Learning Log ตามหัวข้อในงานข้อ 6
5. (ไม่บังคับ) แผนเดิมของวิชาใช้ awk จัดการ log ด้วย ลองอ่าน คู่มือ GNU awk แล้วหาวิธีพิมพ์เฉพาะคอลัมน์รหัสสถานะ HTTP ของ app.log.bak

งานที่ต้องส่ง

เกณฑ์ให้คะแนน

ข้อ 5 ใช้ rubric 3 ระดับ

สรุปบทและสิ่งที่ส่งต่อไปยัง Capstone

• DevOps คือการที่ทีมพัฒนาและทีมดูแลระบบรับผิดชอบซอฟต์แวร์ร่วมกัน หัวใจคือ CAMS และวัดผลด้วย DORA metrics
• สิทธิ์ไฟล์มี 3 ชุด (เจ้าของ กลุ่ม คนอื่น) × 3 อย่าง (r w x) ไฟล์ความลับต้องเป็น 600 ที่ตัวไฟล์เสมอ
• โฟลเดอร์ทีมต้องตั้งทั้งกลุ่มและ set-group-ID ไม่อย่างนั้นไฟล์ใหม่จะเป็นกลุ่มของผู้สร้าง
• grep, sort, uniq และ pipe ช่วยหาปัญหาจาก log ได้เร็ว ต้อง sort ก่อน uniq เสมอ
• exit status 0 คือสำเร็จ ค่าอื่นคือล้มเหลว สคริปต์ที่ตรวจอะไรไม่ได้ต้องไม่ตอบ 0

สิ่งที่ส่งต่อไปยังโครงงานและ Capstone

สรุปคำสั่งในบทนี้