[KBTG-GO#05] DevOps

สัปดาห์นี้มาช้านิดนึง ไปลองทำ Fun-Ex มา 55 หัวข้อประมาณนี้

1 .DevOps

- Why DevOps

Flow เดิม Waterfall ทำเสร็จ กว่าจะ Deploy อีกนาน โดยอาจจะให้ Change Approval Board (CAB) อนุมัติ ก่อนให้ทีม Operation ทำงาน กว่าจะแก้ได้ช้า และมีปัญหาเรื่อง Enviroment

DevOps มีคน Idea มาจากฝั่ง Ops ตอนปี 2006-2007 มีคำถาม Migrate ยังแล้วจะรู้ว่าใช้ได้ไหม ทำทีละส่วนและเทส + แนวคิด Agile เกิด #DevOps ปี 2009 โดยมี 3 มุม

  • People - Developer + Operation ทำด้วยกันองค์กร ทำให้เกิด
    - Collective Ownership
    - ลด Silo
    - เพือการ Sync + Communication
  • Process
    - Iterative + Feedback ตอนนี้ Agile
    - MVP Product ได้ Feedback แล้วมาปรับ
    - Tech Continuous Integration / Continuous Delivery / Continuous Deployment / Monitoring + Observability
  • Tools - เครื่องมือมาช่วย People /Process ถ้าสายนี้จะมี CNCF Landscape ในมุมต่างๆ
- CAMS และ CALMS

mindset อะไรที่เสริมให้เกิด DevOps

  • Culture - เรื่องของจนให้ทำงานร่วมกัน
  • Automation - ลดงานมือ อย่างแนวคิด Continuous Integration / Continuous Delivery / Continuous Deployment / Monitoring + OBserability
  • Metric - เห็นว่าตอนนี้ระบบเป็นยังไง มันมี 3 Pillar Obserability
  • Sharing - KM + เสริม idea

นอกจากตัว CAMS พี่ปุ้ยมีแนะนำอีกตัว CALMS ซึ่งจะเพิ่มในส่วนของ L ขึ้นมา โดยคุณ Jez Humble นั้น ซึ่ง L คือ

  • Lean - จัดการพวก waste ทำให้กระบวนการของเรามันกระชับขึ้น

Ref: CALMS Framework | Atlassian

- 4 Keys Metric (Dora Metric)
  • Lead time from commit to change - commit มันบิ้ว แล้ว Deploy ต้องรอนานแต่ไหน
  • Deployment frequency - Deploy บ่อยได้ขนาดไหน รองรับ Change
  • Change failure rate -แก้ไปพังบ่อยไหม พังซ้ำไหม
  • Mean time to recovery - พังไปแล้ว ดับไฟยังไงถอยยังไง

Ref: DORA Metrics: Measuring What Really Matters About Your Software Delivery | Sourced Group

- DevOps Benefit
  • Speed
  • Rapid Delivery
  • Reliability (แก้อะไรแล้วมั่นใจ ระบบไม่พัง)
  • Scale
  • Improved Collaboration - คุยกัน Sync / share km
  • Security - sync กัน ทำตาม policy ได้ แล้วตอนนี้ Shift อีก DevSecOps
- 12 Factor

//เหมือนเคยเขียน เดี๋ยวค่อยไปรวม Blog

  1. Codebase - มีการ Track ได้ ปกติตอนนี้ใช้พวก Git + Deploy ได้บ่อย
  2. Dependencies - กำหนดแบบ Fixed Ver และแยกสำหรับ Dev/Prod อันนี้เพิ่งรู้แยก Env
  3. Config - จัดให้อยู่ตาม ENV จะได้ยัดค่าง่ายๆ
  4. Backing Services - s attached resources อย่างให้มี Coupling มากไป เช่น เอาจะเปลี่ยนอะไร แก้ของ Config อย่าง DB ใส่ URL + Protocal ได้เลย เป็นต้น
  5. Build, Release, Run - แยก Stage ให้ชั้นแจก
  6. Processes - Stateless for scale
  7. Port Binding - แยก Port การใช้งาน
  8. Concurrency - เสริมจาก 6 ทำให้ Scale ได้ง่่าย เกิด แก่เจ็บ ตายเป็นวัฏจักร
  9. Disposability- fast startup + Graceful Shutdown
  10. Dev/Prod Parity- แยก ENV ให้ใกล้เคียง ลดปัญหาตอน Deploy Container มาช่วยตรงนี้
  11. Logs- Event Stream ควรเป็น Standard IO ให้ตัวอื่นมาอ่าน เช่น Fluentd
  12. Admin Process - เพิ่มการ Initial ของ Admin ให้อยู่ใน App เลย

2. Containerized Application

- Docker / Docker Compose

สำหรับ Docker / Docker Compose ของ Ref ไปอีก Blog นะ

Docker benefit

  • Standardization & Efficiently Management เหมือนตู้ Container ยกไปทั้งชุด
  • Speed & Agility
  • Security สิ่งที่ทำข้างในจะไม่กระทบข้างนอก หมายถึงสิทธิของ user ข้างใน
  • Cost Optimization ขึ้นได้ไว้ และถูก จากเดิมใช้ VM มีตัวช่วยจาก
    - namespace - linux kernel เอาไว้ทด แยกพื้นที่การทำงานออกจากกัน userspace
    - cgroup - เอาไว้คตุมการใช้งาน namespace เช่น การใช resource cpu mem
- Docker Compose - Test Sandbox

อันนี้เรียกว่าเป็นเทคนิคใหม่ และกัน ส่วนตัวไม่เคยใช้ท่านี้ ส่วนตัวเอาสร้าง Env แล้วยิงจาก Tools ข้างนอกอีกที เลยมาลองสักหน่อย Docker Compose - Test Sandbox Docker Compose ผูกกับ Dockerfile เพื่อให้มันสร้าง Environment สำหรับการทดสอบ และ Initial DB โดยที่มี 3 ส่วน

FROM golang:1.22.1-alpine3.19 AS build

WORKDIR /app

COPY . ./
RUN go mod download

RUN go build -o /bin/app

FROM alpine:3.19.1

COPY --from=build /bin/app /bin

EXPOSE 1323

RUN adduser -D -u 2024 appuser
USER appuser

CMD [ "/bin/app" ]
FROM golang:1.22.1-alpine3.19

# Set working directory
WORKDIR /go/src/target

EXPOSE 1323

# Run tests
CMD CGO_ENABLED=0 go test -v --tags=integration ./...
  • Dependency ต่างๆ พวก Database
  • Full Compose File
version: '3'

networks:
  integration-test:
    driver: bridge

services:
    walletapi_tests:
        build:
          context: .
          dockerfile: ./Dockerfile.test
        volumes:
            - .:/go/src/target
        depends_on:
            - walletapi
        networks:
            - integration-test
        env_file:
            - ./test.env
    walletapi:
        build:
            context: .
            dockerfile: Dockerfile
        ports:
            - "1323:1323"
        volumes:
            - .:/app
        depends_on:
            db:
                condition: service_healthy
        env_file:
            - ./test.env
        networks:
            - integration-test
    db:
        image: postgres:16.0
        environment:
            POSTGRES_DB: wallet
            POSTGRES_USER: root
            POSTGRES_PASSWORD: password
        volumes:
            - ./init.sql:/docker-entrypoint-initdb.d/init.sql
        ports:
            - "5432:5432"
        networks:
            - integration-test
        healthcheck:
            test: ["CMD-SHELL", "pg_isready"]
  • Command
//Setup and Run Test
docker compose -f docker-compose-integration-test.yaml up --build --abort-on-container-exit --exit-code-from walletapi_tests
//Tear Down
docker compose -f docker-compose-integration-test.yaml down

3. Infrastructure as a Code (IaC)

- IaC คือ อะไร
  • IaC - Infrastructure as a Code เอาไว้สร้าง คุม Stage Create / Change / Destroy
    เอามา สร้าง Infra พอเป็น Text ก็ทำ Versioning
  • IaC มี 2 กลุ่ม
    - Configuration Management ลง SW ใน Infra (VM) ที่มี Chef / Puppet / Ansible
    - Infrastructure Orchestration - สร้าง Infra (VM / Container) Cloud Formation/Terraform / K8S
- Before IaC

โจทย์ ถ้าต้องการลง Nginx บน Ubuntu

Without IaC - กดมือ สร้าง VM (EC2) โดยดึง image จาก AMI จะเอา ubuntu เพียวๆ หรือ ubuntu ที่ pack Nginx
With IaC เขียน Declarative File โดยใช้ Terraform (มันต่อกับ Cloud ได้หลายค่าย) โดย

  • กำหนด Provider ใช้ของ Cloud ค่ายไหน + Resource File กำหนด State ของ Service ต่างๆ เช่น
    - VM (EC2) ว่าจะให้มี Spec อะไร เอา image ตัวไหนมาลง
    - VNET เฮ้ย VPC มี subnet อะไร
    - security group - filter port ไหน
    เป็นต้น
  • Command ที่เกี่ยวข้อง
teraform init
teraform plan    #ลองดูว่า IaC ถ้า Execte จริงสำเร็จไหม
teraform apply   #ลุยจริง เสียเงินจริง

ใน VDO จะอิงจาก AWS จะต้องมี aws account + aws cli + Terraform แล้ว Setup Sonor Community (AMI ของ Bitnami) //ผมดองของ Skooldio 555 ซื้อมาดูอันแรกไป 30% เอง

นอกจากนี้ Terraform มันมี Version Cloud ด้วย Terraform.io by HashiCorp โดย Pattern ใช้ประมาณนี้

  • GitHub คุม Flow โดย GitHub Action
  • Terraform cloud มาคุม State //แอบสงสัย มันสั่งเองได้ โดยไม่ผ่าน GitHub Action หรือ ถ้าประหยัด ใช้ GitHub Action สร้าง VM ลง Terraform
  • ปลายทางอย่าง Cloud มีให้ SECRET กับ Terraform มันจะได้เข้าไปสั่งได้

4. GitOps

- GitOps
  • Declarative -> IaC
  • Versioned and Immutable -> IaC มันเป็น Code นี่ เก็บได้
  • Pulled Automatically มีคนมาปรับ State ให้อีกถึง IaC คนในที่นี้ ArgoCD / terraform.io มีการทำ pull model
    เมือก่อนเราอาจจะให้ Jenkins มาเข้าจัดการ ซึ่งทำให้ตัว Jenkins Overload มาไป และมีความเสี่ยงด้าน Security
  • Continuously Reconciled -> ปรับ Deployment ตาม IaC

State ที่ดูแลเป็นอะไรได้บ้าง Resource ที่อยู่ใน Cloud / K8S

- K8S
  • Container Orchestration + Scale แก้ข้อจำกัดของ docker / docker compose
  • แยก Section ของระบบตาม namespace , service . deployment, pod
    Sample AWS LB > EKS (K8S)
- ArgoCD

Tools ทำ Continuous Delivery มัน Reconciled State ตาม Declarative ที่ประกาศไว้ใน Git pull base / web hook ก็มี (ไม่เคยลองเล่น) และตัว Argo มี Tools อื่นๆ Argo Workflow

5. Continuous Integration / Delivery / Deployment (CI/CD)

- Continuous Integration
  • เดิม เอาชอบเอา Code มาเทรวมกันตู้มเดียว แล้วก็พัง
  • แนวทาง ตอนนี้ พยายามเอาเข้าที่ละนิด (Small Integration) + ทำ Test
    - ทำให้พบปัญหาได้เร็ว
    - ลดความเสี่ยงตอน เทรวม Code
    - ลดเวลา Automate เพิ่ม Deploy ให้ถี่ขึ้น

CI Pipeline - ขั้นตอนการทำงาน มี Action ต่างๆ เช่น Build Test จาก Event ต่างๆ เช่น Push Merge บราๆ

- Continuous Delivery
  • ทำ Software fast feedback การ control business decision แต่ต้องคุยกระบวนการให้เรียบร้อยนะ
  • fast release + rollback พอ Build เสร็จก็ deploy ในทุกๆ Environment นะ เพื่อมาช่วยให้ Business ตัดสินใจเช่น UAT / SIT / Release Prod (Manual)
- Continuous Deployment

Continuous Deployment = Continuous Integration + Continuous Delivery

รายละเอียดเต็มลองดูเพิ่มจาก The Cloud Camp Week#10 (CI/CD – GitHub Action)

6. IaC Tear Down

เอาขึ้นไปแล้ว ตอนถอยควรทำตามลำดับ จะได้ไม่มี Resource ค้าง และกินเงินเราไป โดยลำดับอีกจาก Demo

  1. ArgoCD - Delete Deployment
  2. Terraform - Destroy Plan > Approve > รอ Apply
  3. Cloud

ถ้าใช้ Cloud ดู Cost และใน K8S ผมเอาท่านี้

kubectl delete -f <your_file>.yaml //น่าจะหมดมั้ง 555

ดูหัวข้อแล้ว แอบคล้ายกับ Cloud Camp ตอนนี้เปิดรุ่น 2 แล้วเผื่อไปสมัครครับ Jumpbox - 📣สิ้นสุดการรอคอย เรากลับมาอีกครั้ง ✨✨The Cloud Camp... | Facebook

และมี Fun-Exให้ลองทำ ลุยครับ pingkunga/go-fun-exercise-api (github.com) มีความรู้สึกอย่างนึง

  • แก้อะไรแล้วต้องทำ Test ไม่แน่ใจว่าตัวภาษามา lock หรือป่าว ตอนแรกไปทำ API ให้จบก่อน Test แรก Run ไม่ได้เลย ต้องมาไล่ Implement ให้ครบ
  • Pattern ของ Integration Test สอนไป 2 แบบ อันนี้ผม ทักไปถาม ใน Discord และ เดวรอทีมงานตอบ ฮ่าๆ
  • พวกการทำ Transaction เหมือนยังไม่ได้สอน ลองหาๆดู ทาง Go เองมีเหมือนกัน Executing transactions - The Go Programming Language

จดจาก Sharing Section ผมมีไปแขร์ไปพูดไปเร็วเลย แต่มี Idea จากหลายคน

หนังสือแนะนำ

Discover more from naiwaen@DebuggingSoft

Subscribe to get the latest posts to your email.

Tags

Related Posts