Cloud Computing ແລະ DevOps: ຄູ່ມືປະຕິບັດຕົວຈິງກ່ຽວກັບ Docker, CI/CD ແລະ ການ Deploy ທີ່ເຊື່ອຖືໄດ້

ການຂຽນໂຄດເປັນພຽງເຄິ່ງໜຶ່ງຂອງການສົ່ງມອບຊອບແວ. ອີກເຄິ່ງໜຶ່ງແມ່ນການ build, ທົດສອບ, ນຳຂຶ້ນເຊີບເວີ ແລະ ດູແລໃຫ້ມັນເຮັດວຽກຕໍ່ເນື່ອງ, ເຊິ່ງໃນອຸດົມຄະຕິຄວນເຮັດໄດ້ຫຼາຍເທື່ອຕໍ່ອາທິດ ໂດຍບໍ່ຕ້ອງອົດນອນແກ້ບັນຫາຕອນເດິກ. DevOps ແມ່ນຊຸດແນວທາງທີ່ເຮັດໃຫ້ເລື່ອງນີ້ເປັນວຽກປົກກະຕິ, ສ່ວນ container, CI/CD pipeline ແລະ ໂຄງສ້າງພື້ນຖານ cloud ແມ່ນເຄື່ອງມືທີ່ເຮັດໃຫ້ມັນເຮັດໄດ້ແທ້.

DevOps ໝາຍເຖິງຫຍັງແທ້

DevOps ບໍ່ແມ່ນຊື່ຕຳແໜ່ງ ຫຼື ເຄື່ອງມື. ມັນແມ່ນແນວຄິດທີ່ວ່າຄົນທີ່ສ້າງຊອບແວ ແລະ ຄົນທີ່ດູແລລະບົບ ຕ້ອງຮັບຜິດຊອບທັງສອງດ້ານຮ່ວມກັນ ໂດຍມີລະບົບອັດຕະໂນມັດຈຳນວນຫຼາຍຄອຍສະໜັບສະໜູນ. ໂຄງການຄົ້ນຄວ້າ DORA ສະຫຼຸບປະສິດທິພາບການສົ່ງມອບໄວ້ດ້ວຍຕົວຊີ້ວັດສີ່ຢ່າງ:

• ຄວາມຖີ່ໃນການ deploy: ທ່ານປ່ອຍວຽກຂຶ້ນ production ເລື້ອຍປານໃດ.
• ໄລຍະເວລາຂອງການປ່ຽນແປງ: commit ໜຶ່ງໃຊ້ເວລາດົນປານໃດກວ່າຈະເຖິງ production.
• ອັດຕາຄວາມລົ້ມເຫຼວຂອງການປ່ຽນແປງ: ການປ່ອຍວຽກເຮັດໃຫ້ເກີດບັນຫາທີ່ຕ້ອງແກ້ໄຂເລື້ອຍປານໃດ.
• ເວລາໃນການກູ້ຄືນບໍລິການ: ທ່ານກູ້ລະບົບຄືນມາໄດ້ໄວປານໃດເມື່ອການປ່ອຍວຽກລົ້ມເຫຼວ.

ທີມທີ່ມີປະສິດທິພາບສູງເຮັດຄະແນນໄດ້ດີທັງສີ່ຢ່າງພ້ອມກັນ. ປາກົດວ່າການປ່ອຍການປ່ຽນແປງນ້ອຍໆເລື້ອຍໆ ທັງໄວກວ່າ ແລະ ປອດໄພກວ່າການປ່ອຍວຽກກ້ອນໃຫຍ່ດົນໆເທື່ອ.

Container ດ້ວຍ Docker

Container image ລວມແອັບຂອງທ່ານເຂົ້າກັບ runtime, ໄລບຣາຣີຂອງລະບົບ ແລະ ຄ່າຕັ້ງຄ່າເລີ່ມຕົ້ນທີ່ແນ່ນອນ. ສ່ວນ container ແມ່ນ instance ຂອງ image ນັ້ນທີ່ກຳລັງເຮັດວຽກ. ເພາະ image ຄືກັນທຸກຢ່າງທັງໃນແລັບທັອບ, ໃນ CI ແລະ ໃນ production, ບັນຫາ "ເຄື່ອງຂ້ອຍແລ່ນໄດ້ເດີ" ຈຶ່ງໝົດໄປ.

Multi-stage build ເຮັດໃຫ້ image ສຳລັບ production ມີຂະໜາດນ້ອຍ ແລະ ປອດໄພ: ການຕິດຕັ້ງ dependency ແລະ ການ compile ແອັບເກີດຂຶ້ນໃນ stage ຊົ່ວຄາວ, ແລ້ວສຳເນົາສະເພາະຜົນລັບໄປໄວ້ໃນ runtime image ທີ່ນ້ອຍທີ່ສຸດ. ນີ້ແມ່ນຕົວຢ່າງສຳລັບແອັບ Next.js ທີ່ build ດ້ວຍ output: 'standalone':

# syntax=docker/dockerfile:1
FROM node:24-alpine AS deps
WORKDIR /app
COPY package.json pnpm-lock.yaml ./
RUN corepack enable && pnpm install --frozen-lockfile

FROM node:24-alpine AS build
WORKDIR /app
COPY --from=deps /app/node_modules ./node_modules
COPY . .
RUN corepack enable && pnpm build

FROM node:24-alpine AS runtime
WORKDIR /app
ENV NODE_ENV=production
# Never run the application as root
RUN addgroup -S app && adduser -S app -G app
COPY --from=build --chown=app:app /app/.next/standalone ./
COPY --from=build --chown=app:app /app/.next/static ./.next/static
COPY --from=build --chown=app:app /app/public ./public
USER app
EXPOSE 3000
CMD ["node", "server.js"]

ແນວທາງທີ່ດີສຳລັບ container ທີ່ຄວນນຳໃຊ້ຕັ້ງແຕ່ມື້ທຳອິດ:

• ເພີ່ມໄຟລ໌ .dockerignore ເພື່ອບໍ່ໃຫ້ node_modules, .git ແລະ ຂໍ້ມູນລັບໃນເຄື່ອງ ຫຼຸດເຂົ້າໄປໃນ build context.
• ລະບຸເວີຊັນຂອງ base image ໃຫ້ແນ່ນອນ ແລະ build ໃໝ່ເປັນປະຈຳເພື່ອຮັບແພັດຄວາມປອດໄພ.
• ແລ່ນໜຶ່ງ process ຕໍ່ໜຶ່ງ container ແລະ ຂຽນ log ອອກ standard output ໃຫ້ແພລດຟອມເກັບລວບລວມ.
• ສົ່ງການຕັ້ງຄ່າຜ່ານຕົວແປສະພາບແວດລ້ອມ, ແລະ ເກັບຂໍ້ມູນລັບໄວ້ນອກ image ທັງໝົດ.
• ເກັບຂໍ້ມູນໄວ້ໃນ volume ຫຼື ບໍລິການແບບ managed, ຫ້າມເກັບໃນ container ເຊິ່ງອາດຖືກແທນທີ່ໄດ້ທຸກເວລາ.

ສຳລັບການພັດທະນາໃນເຄື່ອງ ແລະ ການ deploy ຂະໜາດນ້ອຍ, Docker Compose ອະທິບາຍ container ຫຼາຍໂຕ ແລະ ວິທີເຊື່ອມຕໍ່ກັນໄວ້ໃນໄຟລ໌ດຽວ:

services:
  app:
    build: .
    ports:
      - '3000:3000'
    environment:
      DATABASE_URL: postgres://app:${POSTGRES_PASSWORD}@db:5432/app
    depends_on:
      db:
        condition: service_healthy

  db:
    image: postgres:17
    environment:
      POSTGRES_USER: app
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
      POSTGRES_DB: app
    volumes:
      - db-data:/var/lib/postgresql/data
    healthcheck:
      test: ['CMD-SHELL', 'pg_isready -U app']
      interval: 5s
      retries: 10

volumes:
  db-data:

CI/CD Pipeline

Continuous Integration (CI) ໝາຍຄວາມວ່າທຸກເທື່ອທີ່ push ຈະມີການ build ແລະ ທົດສອບອັດຕະໂນມັດ ເພື່ອໃຫ້ບັນຫາປາກົດພາຍໃນບໍ່ເທົ່າໃດນາທີ ແທນທີ່ຈະພົບບໍ່ເທົ່າໃດມື້ກ່ອນປ່ອຍວຽກ. Continuous Delivery (CD) ຕໍ່ຍອດຈາກນັ້ນ: ທຸກການປ່ຽນແປງທີ່ຜ່ານ pipeline ຈະຖືກແພັກພ້ອມ deploy, ແລະ ໃນ Continuous Deployment ມັນຈະຖືກນຳຂຶ້ນ production ໂດຍອັດຕະໂນມັດ.

Pipeline ພື້ນຖານທີ່ໝັ້ນຄົງໃນ GitHub Actions ຈະຕິດຕັ້ງ dependency, ກວດ type, ແລ່ນການທົດສອບ ແລະ build ທຸກ pull request ແລະ ທຸກເທື່ອທີ່ push ເຂົ້າ main:

name: CI

on:
  push:
    branches: [main]
  pull_request:

jobs:
  verify:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v5
      - uses: pnpm/action-setup@v4
        with:
          version: 10
      - uses: actions/setup-node@v5
        with:
          node-version: 24
          cache: pnpm
      - run: pnpm install --frozen-lockfile
      - run: pnpm typecheck
      - run: pnpm test
      - run: pnpm build

ຈາກນັ້ນເພີ່ມຂັ້ນຕອນສຳລັບເລື່ອງທີ່ທີມຂອງທ່ານພົບບັນຫາຊ້ຳໆ: ສະແກນຊ່ອງໂຫວ່ຂອງ dependency ແລະ container image, end-to-end test ໃນ preview environment, ແລະ job ສຳລັບ deploy ທີ່ແລ່ນສະເພາະໃນ main ຫຼັງຈາກທຸກຢ່າງຜ່ານໝົດແລ້ວ. ຮັກສາ pipeline ໃຫ້ໄວ. Pipeline ສິບນາທີຈະຖືກໃຊ້ແທ້, ແຕ່ pipeline ສີ່ສິບນາທີຈະຖືກຫາທາງຫຼີກລ່ຽງ.

ກົນລະຍຸດການ Deploy

ວິທີປ່ອຍວຽກສຳຄັນບໍ່ແພ້ສິ່ງທີ່ປ່ອຍ. ເປົ້າໝາຍແມ່ນບໍ່ມີ downtime ແລະ ມີທາງຖອຍຫຼັງທີ່ໄວ ແລະ ງ່າຍດາຍເມື່ອມີບັນຫາ:

• Rolling update: ແທນທີ່ instance ເທື່ອລະບໍ່ເທົ່າໃດໂຕ. ງ່າຍດາຍ ແລະ ເປັນຄ່າເລີ່ມຕົ້ນໃນແພລດຟອມສ່ວນໃຫຍ່, ແຕ່ເວີຊັນເກົ່າ ແລະ ໃໝ່ຈະເຮັດວຽກຄູ່ກັນໄລຍະໜຶ່ງ.
• Blue-green: ແລ່ນເວີຊັນໃໝ່ຂ້າງເວີຊັນເກົ່າ, ທົດສອບໃຫ້ຮຽບຮ້ອຍ, ແລ້ວສະຫຼັບຜູ້ໃຊ້ທັງໝົດໄປໃນເທື່ອດຽວ. ການ rollback ຄືການສະຫຼັບກັບຄືນ.
• Canary: ສົ່ງຜູ້ໃຊ້ສ່ວນນ້ອຍ ເຊັ່ນ 5% ໄປຫາເວີຊັນໃໝ່, ຕິດຕາມອັດຕາຂໍ້ຜິດພາດ ແລະ ຄວາມໜ່ວງ, ແລ້ວຄ່ອຍໆເພີ່ມສັດສ່ວນ.
• Feature flag: deploy ໂຄດໃນສະຖານະປິດ ແລ້ວຄ່ອຍເປີດໃຫ້ຜູ້ໃຊ້ທີ່ເລືອກໄວ້ພາຍຫຼັງ. ວິທີນີ້ແຍກການ deploy ອອກຈາກການເປີດໃຊ້ງານ.

ການປ່ຽນແປງຖານຂໍ້ມູນກໍຕ້ອງລະມັດລະວັງບໍ່ແພ້ກັນ. ໃຊ້ຮູບແບບ expand and contract: ເພີ່ມຖັນ ຫຼື ຕາຕະລາງໃໝ່ແບບທີ່ເຂົ້າກັນໄດ້ກັບຂອງເດີມກ່ອນ, deploy ໂຄດທີ່ໃຊ້ຂອງໃໝ່, ແລ້ວຈຶ່ງລຶບໂຄງສ້າງເກົ່າໃນການປ່ອຍວຽກຮອບຕໍ່ໄປ. ວິທີນີ້ເຮັດໃຫ້ແອັບເວີຊັນກ່ອນໜ້າຍັງເຮັດວຽກໄດ້ທັງໃນລະຫວ່າງ deploy ແລະ ເມື່ອ rollback.

ໂຄງສ້າງພື້ນຖານ Cloud ແບບເຂົ້າໃຈງ່າຍ

ຜູ້ໃຫ້ບໍລິການ cloud ມີທາງເລືອກຕັ້ງແຕ່ virtual machine ເປົ່າໆ (IaaS), ຜ່ານແພລດຟອມແບບ managed ແລະ ບໍລິການ container (PaaS), ຈົນເຖິງຟັງຊັນແບບ serverless ທີ່ທ່ານສົ່ງພຽງແຕ່ໂຄດ. ຍິ່ງໄປທາງຫຼັງ, ທ່ານຍິ່ງຕ້ອງດູແລເອງໜ້ອຍລົງ ແລະ ຄວບຄຸມໄດ້ໜ້ອຍລົງ. ສຳລັບທີມສ່ວນໃຫຍ່, ຈຸດທີ່ລົງຕົວແມ່ນໃຊ້ບໍລິການແບບ managed ສຳລັບສ່ວນທີ່ຍາກ (ຖານຂໍ້ມູນ, ຄິວ, object storage ແລະ load balancer) ແລະ ໃຊ້ container ສຳລັບຕົວແອັບ.

ກຳນົດໂຄງສ້າງພື້ນຖານເຫຼົ່ານັ້ນເປັນໂຄດດ້ວຍເຄື່ອງມືເຊັ່ນ Terraform, OpenTofu ຫຼື Pulumi. ແລ້ວເຊີບເວີ, ເຄືອຂ່າຍ ແລະ DNS ຂອງທ່ານຈະຢູ່ໃນລະບົບຄວບຄຸມເວີຊັນ, ຖືກກວດຄືນຄືກັບໂຄດ ແລະ ສ້າງໃໝ່ໄດ້ໃນບໍ່ເທົ່າໃດນາທີ, ລວມທັງ staging environment ທີ່ຄືກັບ production ແທ້ໆ.

ຫຼັກສຳຄັນໃນການດູແລ ແລະ ຮັກສາຄວາມປອດໄພເຊີບເວີ

• ສິດຂັ້ນຕ່ຳ: ທຸກຄົນ, ທຸກບໍລິການ ແລະ ທຸກ job ໃນ CI ໄດ້ຮັບສິດເທົ່າທີ່ຈຳເປັນເທົ່ານັ້ນ.
• ຂໍ້ມູນລັບຕ້ອງຢູ່ໃນ secrets manager ຫຼື ການຕັ້ງຄ່າທີ່ເຂົ້າລະຫັດຂອງແພລດຟອມ, ຫ້າມຢູ່ໃນ repository ຫຼື image.
• ອັບເດດແພັດຂອງລະບົບປະຕິບັດການ, base image ແລະ dependency ຕາມຮອບ, ແລະ ເຮັດໃຫ້ອັດຕະໂນມັດເທົ່າທີ່ເຮັດໄດ້.
• ເຄືອຂ່າຍສ່ວນຕົວ: ບໍ່ເປີດຖານຂໍ້ມູນສູ່ອິນເຕີເນັດສາທາລະນະ, ເປີດສະເພາະ load balancer.
• ໃຊ້ HTTPS ທຸກບ່ອນ ພ້ອມຕໍ່ອາຍຸໃບຢັ້ງຢືນອັດຕະໂນມັດ.
• ຂໍ້ມູນສຳຮອງຈະມີຄ່າກໍຕໍ່ເມື່ອກູ້ຄືນໄດ້ແທ້: ເຮັດໃຫ້ອັດຕະໂນມັດ, ເຂົ້າລະຫັດ, ເກັບໄວ້ອີກບ່ອນໜຶ່ງ ແລະ ທົດລອງກູ້ຄືນເປັນປະຈຳ.
• ລະບົບຕິດຕາມ ແລະ ແຈ້ງເຕືອນ ກ່ຽວກັບຄວາມພ້ອມໃຊ້ງານ, ອັດຕາຂໍ້ຜິດພາດ ແລະ ຄວາມໜ່ວງ, ພ້ອມເວນຮັບເຫດ ແລະ ຄູ່ມືຮັບມື (runbook) ສຳລັບເຫດການທີ່ພົບເລື້ອຍ.

ປະເດັນສຳຄັນ

• Container ເຮັດໃຫ້ການ build ເຮັດຊ້ຳໄດ້ຄືເກົ່າ. ໃຊ້ multi-stage build, base image ຂະໜາດນ້ອຍ ແລະ ຜູ້ໃຊ້ທີ່ບໍ່ແມ່ນ root.
• ເຮັດເສັ້ນທາງສູ່ production ໃຫ້ເປັນອັດຕະໂນມັດ: ທຸກການປ່ຽນແປງຖືກ build, ທົດສອບ ແລະ ສະແກນດ້ວຍວິທີດຽວກັນ.
• ປ່ອຍການປ່ຽນແປງນ້ອຍໆເລື້ອຍໆ, ແລະ ໃຊ້ blue-green, canary ຫຼື feature flag ເພື່ອຫຼຸດຄວາມສ່ຽງໃນການປ່ອຍວຽກ.
• ຈັດການໂຄງສ້າງພື້ນຖານເປັນໂຄດ, ໃຊ້ບໍລິການແບບ managed ກັບສ່ວນທີ່ມີສະຖານະ, ແລະ ຝຶກກູ້ຄືນຂໍ້ມູນສຳຮອງ.

ອ່ານເພີ່ມເຕີມ

• ສະຖາປັດຕະຍະກຳ Backend: REST API, Microservices ແລະ ຖານຂໍ້ມູນທີ່ຂະຫຍາຍໄດ້
• ພັດທະນາເວັບສະໄໝໃໝ່ດ້ວຍ Next.js, React ແລະ TypeScript