สรุปความเข้าใจ Docker & Microservice วันที่ 11/10/2020

Microservice, RESTful APIs, API Gateway, Docker

Information and Warning (Note)

This article is created by Sirawich Smitsomboon under Super AI Engineer (22p21c0207)

บทความนี้ได้สร้างขึ้นโดย สิรวิชญ์ สมิทธ์สมบูรณ์ ในโครงการ Super AI Engineer (รหัสโครงการ 22p21c0207)

Microservice

Principles of Microservice

Microservice ควรจะ

• รับผิดชอบกับ Function เดียว, System เดียว, หรือ Process เดียว
• ควรใช้ event หรือ message bus ในการติดต่อสื่อสารกับระบบอื่นๆ เพื่อที่จะ Scale เพิ่มขึ้นได้ง่ายในภายหลัง

Microservice ไม่ควร

• คุยกันกับ Microservice, Service, หรือ Software Components อื่นๆ โดยตรง
• Share Code or Data
• มีข้อบกพร่องใดๆ

นอกจากนี้

• Independence & Autonomy ดีกว่าการทำให้ code reusable

ข้อดีของการใช้ Microservice

CODE

• แยกทุกอย่างเป็น Module ทําให้ง่ายต่อการเข้าใจและพัฒนา
• ลดความซับซ้อนของ Code
• Upgrade ระบบในบาง Function โดยจะไม่กระทบต่อระบบหลัก

TEAM

• ช่วยให้ทีมพัฒนาทํางานร่วมกันระหว่างทีมได้ดียิ่งขึ้น
• ช่วยให้ทีมที่เข้ามาใหม่ทํางานได้ทันที โดยไม่ต้องเรียนรู้ระบบทั้งระบบ

DEPLOYMENT

• ช่วยในการ Continuous Delivery และ Deployment ระบบใหญ่ๆ และมีความซับซ้อน ได้ง่ายขึ้น
• Deploy แต่ละ Service ได้อย่างอิสาระ ไม่ต้องรอขึ้นระบบใหม่ทั้งหมด
• ช่วยในการสร้างสถาปัยตยกรรมที่เป็น Highly Scalable
• ช่วยในการ Deploy ระบบบน Multiple Cloud หรือ On-Premise Infrastructure
• ช่วยในการเปลี่ยนผ่านเทคโนโลยี (Frameworks, Programming Language, Etc.) โดยที่ไม่ต้อง Down ระบบ

ข้อเสียของการใช้ Microservice

• ทุกอย่างทําเป็น Microservice ได้ ยกเว้น Database
• เมื่อระบบใดระบบหนึ่งล่ม อาจำให้ระบบรอบข้างล่มตามไปด้วย

มุมมองในการ Deploy Product บนพื้นฐาน Microservices

RESTful APIs

RESTful APIs คือ Website API/Service ที่ทํางานอยู่บนสถาปัตกรรมในรูปแบบ Representational State Transfer.

• REST คือ Client จะติดต่อไปยัง RESTful API บน HTTP protocol
• Client Request ผ่าน URI (Uniform Resource Identifier)

RESTful APIs จะใช้ HTTP Verbs/Method ใช้สําหรับทํา CRUD (Create, Read, Update, & Delete)

• POST = Create
  - ปลอดภัยกว่า GET (ส่วนใหญ่ใช้กับการ Login)
  - ไม่มีการ Cache Data
  - สามารถส่ง Binary Data
• GET = READ
  - ไม่สามารถส่ง Binary Data ปกติจะมีการแปลงเป็น Base 64 String ก่อน
  - มี Limit ที่ 2048 ตัวอักษร
• PUT = Update Specified Resource
• PATCH = Partial Update Resource
• DELETE = ลบข้อมูล

ทำไมถึงใช้ RESTful APIs กับ Microservice

เนื่องจาก RESTful APIs นั้นทำความเข้าใจได้ง่าย ใช้ HTTP Verbs/Method เพื่อทำ CRUD

นอกจากนี้ ระบบ REST นั้น

• ได้ Design ออกมาในแบบ Stateless (Goggle Translate: ไร้สัญชาติ) และสามารถกระจายงานเป็น Client Server
• สามารถอ่านและ Cache Data ได้ (สำหรับ API ที่ใช้กับ ‘GET’ Method)
• Support Data Format หลากหลาย (เช่น Text, Json, Binary)

บริษัทใหญ่ๆ ใช้ API ในรูปแบบของ RESTful API แล้ว เช่น Google, Amazon, MS

HTTP Status Code

• 1xx Information
• 2xx Sucessful
• 3xx Redirection
• 4xx Client Error
• 5xx Server Error
• อ่านเพิ่มเติมได้ที่ https://httpstatuses.com/

API Gateway

API Gateway ทําหน้าที่เป็นทางเข้าก่อนที่จะเข้าถึง API อาจจะทําหน้าที่คล้ายๆ Reverse Proxy มีหน้าที่หลักๆดังนี้

• จําแนก Route ที่จะเข้าถึง API
• ทำงานแบบ Load-Balance สำหรับ API หลังบ้าน
• สามารถตั้งค่า Rate Limit
• สามารถตรวจสอบสถานะ และมี Health Check
• สร้าง HTTPS สำหรับ API ทุกๆตัว
• ตัวอย่าง API Gateway: KONG GATEWAY

Event-Driven Communication Using an Event Bus

Microservice ส่ง Message ไปให้ Event Bus แล้วรอ. จากนั้น Event Bus จะส่งไปให้ Microservice ถัดๆ ไป และจัดการกับระบบ Message ทั้งหมด ระบบ Event Bus ทำงานในระบบ Publish/Subscribe

การจัดการข้อมูลใน Microservices

CQRS คือ Software Design Pattern ที่แยก Command กับ Query ออกจากกัน

• Command -> กระบวนการที่เปลี่ยนแปลง Object หรือข้อมูล (Update/Write Database)
• Query -> กระบวนการที่ Return State ของ Object หรือข้อมูล (Read Database)

ซึ่ง Process พวกนี้สามารถทำได้โดย

• ตัวของ Database เอง
• การออกแบบระบบให้สามารถ Sync Data แยกออกมา 2 replica

สิ่งที่ควรจะทำระหว่างการใช้งาน Microservice (Success Factors)

เราควรจะ Log

• Exceptions
• ทุกๆ Request และ Response (รวมถึง HTTP Status Code ด้วย)
• Response Time
• Event Message ใน Event Bus
• Authentication (การ Login ต่างๆ)

นอกจากนี้เราควรจะ Monitor และเช็ค Service ที่รันอยู่โดยดู

• Uptime
• Response Time
• Success/Fail Ratio
• Resource usage (I think CPU/Memory)
• Access Frequency (req/s)
• Health Check
• If Service is still Running

และเราควรจะ Alert สิ่งที่ไม่ควรจะเกิดขึ้นใน Service และควรจะตั้ง Limit ใน Loadtest

Docker

เนื้อหาใน Section นี้จะเป็นสิ่งที่ผมเรียนเพิ่มจากเมื่อวาน ซึ่งสามารถไปอ่านก่อนได้ที่ https://is.gd/FZVuh7

Summary ของคำสั่งเพิ่มเติมสำหรับวันนี้

Note: คำสั่งหลายๆ คำสั่งไม่ได้มี Example ให้ เนื่องจาก ผมไม่ได้ลง Container และ Image ไว้

Note #2: Notebook นี้รันบนคอมฯ ของผม และ (อาจ) ไม่สามารถนำไปรันบน Cloud เช่น Kaggle หรือ Google Colab ได้ สำหรับคอมฯ ทั่วไปต้อง Install Docker ก่อน

10 อย่างที่ควรหลีกเลี่ยงสำหรับ Docker Container

• อย่าเก็บข้อมูลใน Containers
• อย่าสร้าง Images จาก Containers ที่รันอยู่
• อย่าใช้ “latest” Tag อย่างเดียว
• อย่าเก็บ Credentials ใน Image ให้ใช้ Environment Variables
• อย่ารันหลายๆ Process ใน Container เดียวกัน
• อย่าแบ่ง Application เป็นหลายๆชิ้น
• อย่าสร้าง Images ใหญ่
• อย่าใช้ Single Layer Image
• ให้รัน Processes แบบ Non-Root User
• Don’t rely on IP addresses

Docker-Compose

• Orchestrate Containers Tool
• Compose เป็นเครื่องมือสำหรับการสร้างและ Run Container หลายๆตัวในหนึ่ง Docker applications
• เขียน Config เป็น File .YAML ในการตั้งค่า Application Services
• คุณสามารถเปิดใช้งาน Services ทั้งหมดที่ระบุใน Config ด้วยคำสั่งเดียว

การลง Docker-Compose

เช็ค Version ล่าสุดได้ที่ https://docs.docker.com/compose/install/#install-compose

Install ด้วยคำสั่ง
Note: สำหรับ Windows จะติดมากับ Docker Desktop อยู่แล้ว ไม่ต้องลงเพิ่ม

sudo curl -L “https://github.com/docker/compose/releases/download/1.26.2/\
docker-compose-$(uname -s)-$(uname -m)” -o /usr/local/bin/docker-compose
sudo chmod +x /usr/local/bin/docker-compose
docker-compose — version

Note: ใน Part นี้เราใช้ Docker-Compose Syntax Version 2

Docker Compose จะเขียนใน Format YAML และ Filename จะต้องชื่อ docker-compost.yml (หรือ docker-compost.yaml)

Note: YAML นั้น Strict ด้าน indentation และ Space
Note #2: Docker-Compose มี Command ในการ Check Syntax

บรรทัศแรก ต้องเขียน

version: '2'

จากนั้น เราสามารถกำหนด Service, Networks, หรือ Volumes ได้

Note: ไม่ต้องใส่ทั้ง 3 อย่างก็ได้ เราสามารถใส่เท่าที่จะใช้

Service

เราสามารถตั้งได้ว่าจะให้ Container เริ่มทำงานได้อย่างไร

Parameter

• build กำหนด Path ของ Docker
  หากอยากใส่ Parameter อื่นๆ เช่น dockerfile ต้องใส่ Path ใน context เช่น

• image กำหนด Image หากมี build จะเป็นการตั้งชื่อ Image ถ้าไม่มี build จะเป็นการดึง Image มาใช้

• depends_on เป็น parameter ที่ใส่ใน build ทำให้ Docker-compose จะ Start Image ที่อยู่ใน List ก่อนที่จะ Start ตัวเอง

• environment กำหนด Environment Variable

• expose เป็นการเปิดเผยพอร์ตโดยที่ไม่ต้องเผยแพร่ไปยัง Host สามารถเข้าถึงได้เฉพาะกับบริการที่เชื่อมโยงเท่านั้น และสามารถระบุได้เฉพาะพอร์ตภายในเท่านั้น

• port เป็นการ Map Port จาก Container ไปหา Host
  (Syntax <Host>:<Container>)

• logging ใช้ในการ log

• network ใช้ในการ join network

• volume ใช้ในการ Map Volume
  (Syntax <Host>:<Target>)

• restart ใช้ในการบอกว่าจะ restart ไหมหลังจากที่โปรแกรม exit
  no = ไม่ Restart
  always = Restart ตลอด
  on-failure = Restart เมื่อ Exit Code ไม่ใช่ 0

• Limit Resource (ไม่ใช้ชื่อ Parameter)
  Note: ใช้ได้ syntax 2.2 ขึ้นไป
  สามารถ limit CPU หรือ Memory ได้ โดย…

• command ใช้รัน command ใน Container

Network

สร้าง Network เปรียบเสมือนสร้าง Vlan ขึ้นมา 1 group subset

Driver

• bridge = Bridge network จาก Host ไป Container
• Overlay = Connect Container บน network ใน docker swarm

Volumn

กำหนด Data-Volume

Docker-compose command

• docker-compose config
  ใช้ในการ Check Syntax
• docker-compose up
  ใช้ในการ Build, สร้าง, แล้ว Attach ไปที่ Container
  หากใส้ -d ด้วยจะเป็นการ Detach หลังจากการรัน
• docker-compose down
  หยุดทำงาน Docker-compose และลบ Container, Network, และ Image ที่สร้างโดย docker-compose up
• docker-compose scale <Parameter>
  ทำให้รันแต่ละ Container ได้หลายๆ ตัว
  หมายเหตุ: ห้ามกำหนด Container Name หรือ Parameter อื่นๆ ในโปรแกรมที่ทำให้ Start Process มาหลายๆ ตัว ไม่ได้ (เช่น Port การรัน)
• docker-compose logs <Option> <Service>
  แสดง log
  ใส่ -f เพื่อ follow log
  ใส่ --tail=n เพื่อให้ Show มา n บรรทัศสุดท้าย
• docker-compose ps
  แสดง Docker-Compose Container ทั้งหมด

The End

ขอขอบคุณสำหรับคนที่อ่านจนจบ
หากมีข้อผิดพลาดประการใด ขออภัยมา ณ ที่นี้ด้วยครับ ขอบคุณครับ

อ่านต่อที่ Dashboard Design

สรุปความเข้าใจ Dashboard Design (10/17/2020)

ย้อนกลับไปหา Deployment & Docker

สรุปความเข้าใจ Deployment & Docker (10/10/2020)