DevOps for Databases
DevOps không còn chỉ là phá vỡ silo giữa các nhà phát triển và hoạt động. Đó là lý do tại sao mọi hoạt động thủ công trong đường ống phân phối của bạn cần phải được đánh giá để xác định xem nó có thể được tự động hóa hay không. Thay đổi cơ sở dữ liệu thực sự là một quá trình tẻ nhạt và do đó xứng đáng được xem xét trong triển khai DevOps của bạn.
Hãy để tôi tạm dừng một chút để bình tĩnh mong đợi của bạn cho bài đăng này trước khi chúng tôi tiếp tục. Tôi sẽ không đưa ra công thức ma thuật sẽ giải quyết mọi vấn đề của bạn. Bất kỳ giải pháp nào cũng sẽ phụ thuộc vào mức độ phức tạp và kết hợp kiến trúc của bạn, chưa kể đến độ cứng của quá trình thay đổi của bạn.
Mục tiêu của tôi là cung cấp cho bạn một góc nhìn khác để tự động hóa các thay đổi cơ sở dữ liệu, không chỉ bằng cách giải thích lý do thay đổi cơ sở dữ liệu có thể khó khăn, mà còn bằng cách hướng dẫn bạn qua một ví dụ thực tế về cách DevOps có thể đơn giản hóa quy trình. Băt đâu nao!
Tạo trường hợp cho cơ sở dữ liệu trong DevOps
Theo truyền thống, các thay đổi đối với cơ sở dữ liệu bắt đầu với các nhà phát triển thực hiện các thay đổi mà họ sẽ sử dụng để ghi các tệp theo định dạng SQL. Những thay đổi này sau đó được xem xét bởi một người có nhiều kinh nghiệm hơn về cơ sở dữ liệu. Thông thường, việc xem xét được thực hiện bởi một quản trị viên cơ sở dữ liệu (DBA), những người giao dịch với cơ sở dữ liệu cả ngày. Người này hiểu rõ hơn bất kỳ ai khác về ý nghĩa của một số thay đổi - không chỉ ở hiệu suất, mà còn trong việc tích hợp dữ liệu.
Âm thanh như một quá trình vững chắc, cần thiết, phải không? Nhưng vấn đề là DBA thường được tham gia ngay trước khi triển khai sản xuất khi quá muộn và tốn kém để thực hiện những thay đổi thích hợp.
Tôi không có ý nói rằng các nhà phát triển cần một người khác để xem lại những gì họ đang làm. Nhưng những gì tôi vừa mô tả là một kịch bản điển hình cho các công ty lớn hơn.
DevOps cho cơ sở dữ liệu đơn giản là về việc chuyển đổi quy trình này sang bên trái , và tự động hóa sẽ làm cho quy trình chạy trơn tru hơn. Nhưng nó không chỉ là về tự động hóa.
Tự động hóa chỉ là một phần của phương trình
Có những dịp bạn sẽ cần phải làm một cái gì đó rất phức tạp mà tự động hóa có thể không được giá trị nó. Nhưng giả sử bạn đã xác định cách cơ sở dữ liệu sẽ được sử dụng và bạn không kiến trúc lại, tôi nghi ngờ bạn sẽ cần phải thực hiện các thay đổi phức tạp rất thường xuyên. Tự động hóa sẽ giúp bạn thực hiện các thay đổi trong tương lai theo cách lặp lại và có thể dự đoán được, miễn là chúng không khác nhau mỗi lần.
Và hãy thành thật. Tự động hóa sự thay đổi của một bảng để thêm một cột mới không phải là khó khăn. Vấn đề thực sự là, trong cơ sở dữ liệu, bạn cần phải chăm sóc của nhà nước. Nếu cơ sở dữ liệu có quá nhiều dữ liệu, việc thực hiện một loại thay đổi nhất định có thể mất quá nhiều thời gian và chặn tất cả các thay đổi sắp tới như chèn, cập nhật hoặc xóa.
Tự động hóa chỉ là một trong nhiều thay đổi bạn cần đưa vào triển khai DevOps của mình. Và tôi thậm chí có thể đi xa như vậy để nói rằng nó có thể là phần dễ nhất. Vì vậy, luôn luôn làm cho trường hợp để tự động thay đổi và tránh thực hiện các thay đổi thủ công thường xuyên nhất có thể.
Thiếu một tiêu chuẩn giữa các cơ sở dữ liệu
Thay đổi cơ sở dữ liệu thiếu một tiêu chuẩn nhất quán bởi vì mọi công cụ đều có cách quản lý chúng khác nhau. Tác động của những thay đổi này cũng thay đổi từ động cơ đến động cơ. Ví dụ, các chỉ mục SQL Server không bị ảnh hưởng theo cùng một cách mà chỉ mục của Oracle hoặc MySQL.
Ngôn ngữ truy vấn có cấu trúc (SQL) có thể là các công cụ cơ sở dữ liệu duy nhất có điểm chung. Nhưng ngay cả sau đó, báo cáo cũng cung cấp các kết quả khác nhau.
Trong tương lai, chúng tôi trong ngành công nghiệp có thể có một thời gian dễ dàng hơn bởi vì chúng tôi đã chuẩn hóa cách chúng ta đối phó với cơ sở dữ liệu. Nhưng trong thời gian chờ đợi, hãy đảm bảo bạn lên kế hoạch trước cho cơ chế cơ sở dữ liệu có thể thay đổi như thế nào. Bạn có thể sử dụng các khung công tác ánh xạ đối tượng-quan hệ ( ORM ) và các công cụ khác để giảm bớt công việc. Tôi sẽ cung cấp cho bạn một số ví dụ trong phần sau của bài đăng này.
Kiến trúc kết hợp chặt chẽ
Hầu hết thời gian, các vấn đề trong cơ sở dữ liệu là do hệ thống được kiến trúc như thế nào.
Khi bạn có một kiến trúc kết hợp chặt chẽ với một cơ sở dữ liệu ở trung tâm… tốt, bạn có nhiều vấn đề nghiêm trọng hơn bao gồm các thay đổi cơ sở dữ liệu trong việc triển khai DevOps của bạn. Ngày nay, với các hệ thống phân tán trở thành chuẩn mực, có những mô hình kiến trúc như các dịch vụ nhỏ đã giải quyết việc ghép nối cơ sở dữ liệu bằng cách cho mỗi microservice cơ sở dữ liệu riêng của nó.
Microservices là một cách tốt để tách riêng cơ sở dữ liệu. Cách duy nhất mà các dịch vụ nhỏ khác tương tác với dữ liệu là sử dụng các phương thức được tiếp xúc từ dịch vụ, thay vì truy cập trực tiếp vào cơ sở dữ liệu — ngay cả khi có thể và “dễ dàng hơn” để thực hiện theo cách đó.
Khi bạn chỉ sử dụng cơ sở dữ liệu cho mục đích lưu trữ, các thay đổi trở nên dễ dàng hơn. Chắc chắn, lý do bạn lưu trữ dữ liệu là phân tích dữ liệu đó. Đó là lý do tại sao, trong một số dự án tôi đã làm việc, chúng tôi đã chuyển dữ liệu đến kho dữ liệu, nơi những thay đổi sẽ rất hiếm. Chúng tôi đã để lại dữ liệu giao dịch chỉ với dữ liệu cần thiết. Những gì tôi vừa mô tả là tốt hơn được gọi là mô hình kiến trúc CQRS . Chúng tôi đã có dữ liệu trong một tuần hoặc một tháng trong một số trường hợp.
Thiếu văn hóa và các quy trình được thiết lập tốt
Một khía cạnh quan trọng khác của DevOps cho cơ sở dữ liệu là sự thay đổi về văn hóa và quy trình cần thiết.
Rời việc xem xét các thay đổi cơ sở dữ liệu ở cuối luồng công việc là dấu hiệu giao tiếp kém giữa các nhóm. Có lẽ đơn giản là các đội không có cùng mục tiêu. Hoặc nó có thể là một vấn đề bản ngã, nơi mọi người nghĩ rằng họ không cần sự giúp đỡ và quá trình này chỉ là một chặn.
Bạn không còn phải chờ DBA xem xét các thay đổi cho đến giai đoạn cuối cùng; họ cần phải được tham gia càng sớm càng tốt trong quá trình này. Thời gian trôi qua, các nhà phát triển, các hoạt động và các DBA sẽ được thỏa thuận về cách thực hiện đúng các thay đổi trong cơ sở dữ liệu. Và càng có nhiều nhóm thực hành quy trình xem xét, nó càng mượt mà.
Khi có sự hợp tác dự đoán giữa các đội, những điều tốt đẹp có thể xuất hiện — và bạn nên làm cho nó trở thành một trong những mục tiêu chính của bạn mà mọi người đều nhận ra điều đó.
Thực hành kỹ thuật cho cơ sở dữ liệu
Chúng ta vừa nói về cách cơ sở dữ liệu có xu hướng là một vấn đề cụ thể trong DevOps và cách mọi thứ có thể tốt hơn. Nhưng cũng có những thực tiễn kỹ thuật sẽ thúc đẩy việc triển khai DevOps của bạn với những thay đổi về cơ sở dữ liệu.
Di chuyển đến cứu hộ
Di chuyển là các tập lệnh bao gồm các thay đổi cơ sở dữ liệu lý tưởng là không có giá trị, có nghĩa là bất kể bạn chạy tập lệnh bao nhiêu lần, các thay đổi sẽ chỉ được áp dụng một lần. Nó cũng tốt hơn để có các kịch bản trong kiểm soát phiên bản, do đó bạn có thể theo dõi các thay đổi và đi qua lại với những thay đổi dễ dàng hơn.
Nói cách khác, di chuyển là những thay đổi cơ sở dữ liệu như mã. Bạn có thể chạy chính xác cùng một di chuyển trong các môi trường khác nhau và kết quả sẽ giống nhau, bắt đầu với môi trường cục bộ — máy của nhà phát triển.
Thực hành trong môi trường giống như sản xuất
Hãy nói về một thực hành kỹ thuật khác dễ thực hiện nhưng có một chút kỷ luật: thử nghiệm.
Bạn cần phải thử nghiệm một thay đổi trước khi áp dụng nó vào một môi trường sản xuất. Nếu dữ liệu bảng rất lớn - quá lớn đến mức phải sao chép nó trong môi trường khác với sản xuất - hãy đảm bảo bạn ít nhất có thể mô phỏng thay đổi với một tập hợp dữ liệu quan trọng. Điều này sẽ giúp đảm bảo thay đổi sẽ không diễn ra mãi mãi và bạn sẽ không chặn bảng trong một thời gian dài.
Container là một cách tốt để thực hành. Chúng dễ dàng và rẻ tiền, và nếu có điều gì sai, bạn có thể vứt bỏ mọi thứ và bắt đầu lại.
Cơ sở dữ liệu
Chúng tôi không thể tiếp tục nói về cơ sở dữ liệu mà không đề cập đến một số công cụ. Có rất nhiều công cụ ở đó và những công cụ mới được phát hành mọi lúc và sau đó. Nhưng một số trong những cái phổ biến nhất và một số tôi đã sử dụng trước đây. Đây là danh sách, không theo thứ tự cụ thể:
- Liquibase (miễn phí)
- Dữ liệu (phiên bản trả tiền của Liquibase)
- Redgate (Microsoft Stack)
- Delphix (không chỉ để thay đổi cơ sở dữ liệu)
- DBmaestro (chúng thực sự được bán dưới dạng DevOps cho cơ sở dữ liệu)
Ngoài các công cụ cho các công cụ cơ sở dữ liệu, cũng có các khung công tác hỗ trợ quá trình di chuyển:
Ví dụ, chúng ta hãy bắt tay với Entity Framework trong .NET Core.
Hướng dẫn thực hành về cách sử dụng Entity Framework Core
Mặc dù có một số công cụ mạnh để tự động thay đổi cơ sở dữ liệu, chúng ta hãy xem xét một cách tiếp cận mà bạn có thể dễ dàng tự động hóa bằng các công cụ như Jenkins hoặc VSTS bằng cách sử dụng Entity Framework (EF) cho các ứng dụng .NET Core.
Tôi đã xây dựng một ứng dụng mẫu bằng cách sử dụng dự án Contoso University mà bạn có thể sao chép từ GitHub . Chúng ta có thể tạo một ứng dụng từ đầu, nhưng hãy sử dụng ứng dụng này để chúng ta có thể tập trung hoàn toàn vào các thay đổi cơ sở dữ liệu.
Chúng tôi sẽ thực hiện một thay đổi đơn giản chỉ để bạn có thể xem cách EF phát huy tác dụng.
Thiết lập dự án của bạn tại địa phương
Hãy bắt đầu bằng cách mở dự án bằng Visual Studio (VS). Bạn sẽ cần phải cài đặt .NET Core , và bạn sẽ chạy ứng dụng bằng tùy chọn IIS Express. Bạn cần một cá thể SQL Server để bạn có thể cài đặt / cấu hình một hoặc sử dụng một cài đặt SQL Server hiện có. Ý tưởng là bạn sẽ có thể thấy các thay đổi đang được áp dụng như thế nào trong cơ sở dữ liệu khi bạn tiến bộ.
Hãy bắt đầu bằng cách thay đổi một số tham số đầu vào để tránh xoay vòng cơ sở dữ liệu khi ứng dụng được khởi chạy. Chúng ta sẽ làm điều đó bằng tay bằng cách sử dụng các lệnh di trú EF. Mở các thuộc tính của dự án bằng cách nhấn chuột phải vào dự án “ContosoUniversity” và thay đổi các tham số gỡ lỗi sao cho chúng giống như sau:
Đảm bảo bạn có cấu hình thích hợp để kết nối với cơ sở dữ liệu, đặc biệt là mật khẩu cơ sở dữ liệu. Bạn có thể thay đổi mật khẩu trong tập tin appsettings.json . Của tôi trông như thế này:
Chọn dự án “ContosoUniversity” và sau đó chạy nó bằng cách nhấp vào nút “Debug”. Ngay cả khi ứng dụng bắt đầu, nó sẽ không hoạt động vì cơ sở dữ liệu không tồn tại — chúng tôi chưa chạy lần di chuyển đầu tiên tạo cơ sở dữ liệu.
Khởi tạo cơ sở dữ liệu
Hãy mở một thiết bị đầu cuối. Bạn thậm chí có thể sử dụng dòng lệnh có trong VS. Chạy lệnh sau trong thư mục gốc của dự án để EF tạo lược đồ cơ sở dữ liệu.
cập nhật cơ sở dữ liệu dotnet ef
Bây giờ bạn có thể kết nối với cơ sở dữ liệu và kiểm tra xem tất cả các bảng cần thiết đã được tạo chưa.
Thực hiện thay đổi trong ứng dụng
Bây giờ chúng ta hãy thực hiện một thay đổi trong ứng dụng bằng cách thêm một cột mới. Để làm như vậy, hãy vào tệp Models / Student.cs và thêm cột. Nó sẽ giống như thế này:
Bây giờ hãy chuyển đến chế độ xem và thêm cột để dễ dàng thấy thay đổi.
Trước khi bạn chạy lại ứng dụng, hãy tạo di chuyển trong EF để lần sau bạn chạy cập nhật cơ sở dữ liệu, EF sẽ chạy bất kỳ di chuyển đang chờ xử lý nào. Để làm như vậy, hãy chạy lệnh sau:
di chuyển dotnet ef thêm AddStudentCollege
Khám phá giải pháp một chút và bạn sẽ thấy rằng một tệp mới được tạo với tất cả các chi tiết của quá trình di chuyển. Và hãy nhớ rằng, quá, mà chúng tôi đã đề cập, chúng tôi cần phải có những thay đổi này được phiên bản.
Chạy lại ứng dụng. Giao diện người dùng sẽ được cập nhật, nhưng nó sẽ không hoạt động vì cơ sở dữ liệu chưa được cập nhật. Hãy chạy lại lệnh cập nhật để áp dụng bất kỳ di chuyển đang chờ xử lý nào.
cập nhật cơ sở dữ liệu dotnet ef
Làm mới ứng dụng. Nó sẽ hoạt động ngay bây giờ.
Lần tới khi bạn hoặc người khác cần thực hiện thay đổi, một lần di chuyển mới sẽ được tạo. Áp dụng nó chỉ là vấn đề chạy lệnh cập nhật EF một lần nữa. Tất nhiên, khi bạn quen với nó, bạn sẽ tốt hơn khi tự động hóa các thay đổi cơ sở dữ liệu. Hãy nhớ rằng, DevOps cho cơ sở dữ liệu liên quan đến nhiều hơn là thực hành kỹ thuật.
Điều gì về rollbacks?
Cũng có thể hoàn nguyên bất kỳ thay đổi nào trong cơ sở dữ liệu sau khi bạn đã cập nhật cơ sở dữ liệu đích với các lần di chuyển gần đây. Để làm như vậy, bạn chỉ cần chạy lệnh sau:
di chuyển dotnet ef xóa
Nó sẽ xóa di chuyển mới nhất. Điều đó có nghĩa rằng nếu nhiều hơn một trong các di chuyển được áp dụng, lệnh này sẽ loại bỏ chỉ một trong những gần đây nhất. Bạn sẽ cần chạy lại lệnh để tiếp tục thay đổi cơ sở dữ liệu.
Điều gì sẽ xảy ra nếu bạn vẫn cần tạo tập lệnh?
Khi bạn vẫn đang điều chỉnh quy trình này, bạn có thể muốn kiểm tra chính xác những gì EF đang làm trong cơ sở dữ liệu trước khi áp dụng bất kỳ thay đổi nào. Vâng, bạn có thể xem lại các thay đổi trong định dạng SQL. EF có một lệnh để tạo ra các kịch bản trong một định dạng SQL mà bất kỳ DBA nào cũng sẽ hiểu được.
Để tạo các di chuyển ở định dạng SQL, hãy chạy lệnh sau:
tập lệnh di chuyển dotnet ef
Tất cả các câu lệnh SQL bạn cần sẽ xuất hiện trong terminal. Sau đó, bạn có thể lưu trữ đầu ra trong một tệp để xem xét sau.
Và đó là nó! Bây giờ bạn đã thực hành điều này trên máy tính của mình, bạn đã sẵn sàng để tự động hóa quy trình mới này bằng cách sử dụng Jenkins hoặc VSTS. Bạn sẽ chỉ cần chạy lệnh cập nhật trong đường dẫn triển khai sau khi ứng dụng đã được triển khai. Các nhà phát triển là những người sẽ sử dụng lệnh khác để tạo ra các di chuyển và đặt chúng dưới sự kiểm soát phiên bản.
Thay đổi cơ sở dữ liệu thay đổi sang bên trái
Như bạn đã thấy, không có công thức phép thuật nào mà tôi có thể cung cấp cho bạn để triển khai DevOps cho cơ sở dữ liệu. Có quá nhiều thứ liên quan. Nhưng bước đầu tiên là sẵn sàng ra khỏi vùng thoải mái của bạn và làm mọi việc tốt hơn.
Chấp nhận sự thay đổi. Tôi biết nó đáng sợ, đặc biệt là khi chúng ta đang nói về dữ liệu. Cố gắng giữ mọi thứ đơn giản nhất có thể từ quy trình đến kiến trúc . Tập trung vào việc có một kiến trúc tách rời cho phép bạn thực hiện các thay đổi mà không có quá nhiều phức tạp. Và giáo dục chính mình! Tôi rất khuyên bạn nên đăng bài này bởi Martin Fowler như là một nơi để bắt đầu.
Những thay đổi trong cơ sở dữ liệu không khó cho mỗi người; vấn đề là hàm ý của khả năng mất / làm hỏng tất cả hoặc một phần dữ liệu. Sự lặp lại và nhất quán là chìa khóa, đó là lý do tại sao bạn cần phải thực hành trước khi phát trực tiếp — không chỉ trước khi triển khai vào sản xuất.
