Asked Oct 2nd, 2019 9:51 AM 327 1 4
  • 327 1 4
+6

Giải pháp đồng bộ source code và database mỗi khi deploy?

Share
  • 327 1 4

Hi all
Mình đang gặp 1 bài toán thế này, và mình không biết có công nghệ nào giải quyết được không?

Hệ thống webapp của mình, có 3 con web. (3 webapp chạy ở 3 server khác nhau), để tăng tính HA.
3 con web này sẽ cùng được đi vào từ 1 con LoadBalancer.
3 con web này dùng chung 1 endpoint database.

Mỗi lần release code, mình thường tách từng con web một ra khỏi LB, sau đó deploy code mới nhất. Deploy xong, lại gắn nó trở lại LB, Để đảm bảo service không bị down.

Nhưng nếu phiên release đó, database có thay đổi, mình phải chạy alter sql, merge sql.
Vấn đề là nếu database và source code không được deploy cùng 1 lúc, đồng thời. Thì sẽ nguy cơ xảy ra lỗi.
Mình đã nghĩ tới cách là database cũng tách ra nhiều endpoint như web, xong cũng switch qua lại. Nhưng nếu trong lúc mình deploy, database có thay đổi về data người dùng, thì làm sao để đồng bộ giữa các database đây?

Mọi người biết có keyword nào để giải quyết vấn đề này không? giới thiệu mình với. Mình cảm ơn 😄

4 ANSWERS


Answered Oct 2nd, 2019 11:16 AM
+3

Em mới thử google với keyword "hot deployment single database" thì có bài này, anh thử đọc xem có áp dụng được không. Hình như có khái niệm "Blue-Green Deployment"

http://blog.dixo.net/2015/02/blue-turquoise-green-deployment/

Còn em thường làm là hạn chế breaking change structure 😄

Share
Oct 2nd, 2019 11:23 AM

Thank cậu 😄 Mình cũng đang tìm hiểu về Blue Green, mà chưa thấy chỗ gãi ngứa, nên cứ post QA cho nó parallel :v Mình tìm hiểu xong sẽ update

0
| Reply
Share
Answered Oct 4th, 2019 7:12 AM
+1

Dùng 1 con chuyên làm nhiệm vụ deploy, vẫn gắn vào LB nhưng dùng file hosts để trỏ trực tiếp đến con đó. Mỗi khi deploy thì deploy trên code chính đó, ok hết thì pull code về trên 2 con kia.

Share
Answered Oct 4th, 2019 10:47 AM
+1

Kubernetes + startup script

Share
Nov 21st, 2019 3:55 PM
Answered Nov 21st, 2019 3:55 PM
0

Mình có tìm hiểu thì biết được 2 cách:

  1. Trong version mới của source code, sẽ tương thích với cả 2 version database => ko cần phải migrate database vội, khi toàn bộ instance deploy xong source code mới, thì mới thực hiện migrate db

  2. Tách database ra thành 2 version độc lập. (Có thể hiểu là 2 database/ 2 schema riêng). Code mới sẽ cho trỏ vào db mới. Code cũ vẫn trỏ vào db cũ. db mới ban đầu là clone của db cũ Tư tưởng là tạo trigger, khi có CRUD gì với db cũ, thì cũng sẽ CRUD tương tự với db mới. Sau khi deploy xong toàn bộ instance, thì xóa db cũ. -> Cái này đi sâu hơn gọi là kỹ thuật Migrate database

Share