mirror of
https://github.com/MichaelCade/90DaysOfDevOps.git
synced 2024-12-22 15:43:11 +07:00
added vi translation w13
This commit is contained in:
Quang Mau
parent
257ada16de
commit
06beb0eaca
73
2022/vi/Days/day84.md
Normal file
73
2022/vi/Days/day84.md
Normal file
@ -0,0 +1,73 @@
|
||||
---
|
||||
title: '#90DaysOfDevOps - Bức tranh toàn cảnh: Quản lý dữ liệu - Ngày 84'
|
||||
published: false
|
||||
description: 90DaysOfDevOps - Bức tranh toàn cảnh: Quản lý dữ liệu
|
||||
tags: 'devops, 90daysofdevops, learning'
|
||||
cover_image: null
|
||||
canonical_url: null
|
||||
id: 1048747
|
||||
---
|
||||
|
||||
## Bức tranh toàn cảnh: Quản lý dữ liệu
|
||||
|
||||
|
||||
|
||||
Quản lý dữ liệu không phải là một vấn đề mới, mặc dù chúng ta biết rằng dữ liệu ngày nay quan trọng hơn rất nhiều so với vài năm trước. Dữ liệu có giá trị và luôn thay đổi, nhưng đồng thời cũng có thể gây phiền toái lớn khi nói đến tự động hóa và tích hợp, kiểm tra và triển khai các bản phát hành phần mềm thường xuyên. Dữ liệu lưu trữ và các dịch vụ dữ liệu cơ bản thường là nguyên nhân chính khi xảy ra sự cố.
|
||||
|
||||
Trước khi đi vào Quản lý Dữ liệu Trên Đám Mây, chúng ta cần đi cao hơn một chút. Chúng ta đã đề cập đến nhiều nền tảng khác nhau trong nhiều tuần nay. Cho dù là Vật lý, Ảo hoá, cloud hay cloud native, bao gồm cả Kubernetes, không có nền tảng nào không yêu cầu quản lý dữ liệu.
|
||||
|
||||
Dù là loại hình kinh doanh nào, rất có thể bạn sẽ tìm thấy một cơ sở dữ liệu ẩn nằm đâu đó trong môi trường, dù là cho hệ thống quan trọng nhất của doanh nghiệp hay ít nhất là một phần quan trọng lưu trữ dữ liệu liên tục tại một mức độ nào đó trong hệ thống.
|
||||
|
||||
### DevOps và Dữ Liệu
|
||||
|
||||
Giống như những bài đầu tiên của loạt bài này nói về nguyên lý DevOps, để có quy trình tốt hơn đối với dữ liệu, bạn cần có đúng những người phù hợp. Có thể là các DBA nhưng cũng có thể là những người quan tâm đến việc sao lưu các dịch vụ dữ liệu đó.
|
||||
|
||||
Thứ hai, chúng ta cũng cần xác định các loại dữ liệu khác nhau, các domain và ranh giới mà chúng ta liên kết với dữ liệu của mình. Điều này giúp chúng ta không chỉ xử lý dữ liệu một cách đơn lẻ trong các phạm vi của các DBA, kỹ sư lưu trữ hay kỹ sư tập trung vào sao lưu. Điều này giúp toàn bộ nhóm có thể quyết định con đường hành động tốt nhất khi phát triển và lưu trữ ứng dụng cho doanh nghiệp rộng hơn và tập trung vào kiến trúc dữ liệu thay vì đây là một điều bị bỏ qua.
|
||||
|
||||
Điều này có thể bao gồm nhiều domain khác nhau của vòng đời dữ liệu, từ quá trình nạp dữ liệu, nơi và cách thức dữ liệu được nạp vào dịch vụ hoặc ứng dụng của chúng ta? Làm thế nào để dịch vụ, ứng dụng hoặc người dùng truy cập dữ liệu này? Nhưng điều quan trọng là chúng ta cần hiểu là làm thế nào để bảo vệ dữ liệu và bảo vệ dữ liệu đó.
|
||||
|
||||
### Quản Lý Dữ Liệu 101
|
||||
|
||||
Quản lý dữ liệu theo [Data Management Body of Knowledge](https://www.dama.org/cpages/body-of-knowledge) là "sự phát triển, thực thi và giám sát các kế hoạch, chính sách, chương trình và thực tiễn để kiểm soát, bảo vệ, cung cấp và nâng cao giá trị của tài sản dữ liệu và thông tin."
|
||||
|
||||
- Dữ liệu là mặt hàng quan trọng nhất của doanh nghiệp của bạn - Dữ liệu chỉ là một phần của tổng thể doanh nghiệp của bạn. Tôi đã nghe câu "Dữ liệu là mạch máu của doanh nghiệp" và điều này có lẽ là đúng. Điều này khiến tôi nghĩ đến máu rất quan trọng đối với cơ thể nhưng một mình nó không có giá trị, chúng ta vẫn cần các thành phần khác của cơ thể để biến nó thành một thứ gì đó không chỉ là chất lỏng.
|
||||
|
||||
- Chất lượng dữ liệu quan trọng hơn bao giờ hết - Chúng ta phải xem xét dữ liệu như một tài sản kinh doanh, điều này đòi hỏi chúng ta phải cân nhắc những yếu tố mà dữ liệu cần và yêu cầu để làm việc với các nguyên tắc tự động hóa và DevOps của chúng ta.
|
||||
|
||||
- Truy cập dữ liệu đúng lúc - Không ai có thể kiên nhẫn không có truy cập vào dữ liệu phù hợp vào thời điểm phù hợp để đưa ra các quyết định hiệu quả. Dữ liệu phải có sẵn một cách trơn tru và kịp thời mà không phụ thuộc vào cách trình bày.
|
||||
|
||||
- Quản lý dữ liệu phải là một công cụ hỗ trợ cho DevOps - Tôi đã đề cập đến việc tinh giản trước đó, chúng ta phải bao gồm yêu cầu quản lý dữ liệu vào chu kỳ của chúng ta và đảm bảo không chỉ sự sẵn có của dữ liệu mà còn bao gồm các chính sách bảo vệ quan trọng của những điểm dữ liệu đó cùng với các mô hình phục hồi đã được kiểm tra đầy đủ.
|
||||
|
||||
### DataOps
|
||||
|
||||
Cả DataOps và DevOps áp dụng các thực tiễn tốt nhất của phát triển công nghệ và hoạt động để cải thiện chất lượng, tăng tốc độ, giảm thiểu mối đe dọa bảo mật, làm hài lòng khách hàng và cung cấp công việc ý nghĩa và thách thức cho các chuyên gia có kỹ năng. DevOps và DataOps chia sẻ mục tiêu gia tăng việc cung cấp sản phẩm bằng cách tự động hóa nhiều bước quy trình nhất có thể. Đối với DataOps, mục tiêu là một đường ống dữ liệu vững chắc và những thông tin đáng tin cậy từ phân tích dữ liệu.
|
||||
|
||||
Một số phần cao hơn và phổ biến nhất tập trung vào DataOps sẽ là Học máy, Dữ liệu lớn và Phân tích Dữ liệu bao gồm Trí tuệ nhân tạo.
|
||||
|
||||
### Quản Lý Dữ Liệu là Quản Lý Thông Tin
|
||||
|
||||
Bài viết này sẽ không nói về Học máy hoặc Trí tuệ nhân tạo nhưng tập trung vào việc bảo vệ dữ liệu, tiêu đề của phần này là "Quản lý dữ liệu là quản lý thông tin" và chúng ta có thể coi thông tin = dữ liệu.
|
||||
|
||||
Ba yếu tố chính chúng ta nên xem xét phần này với dữ liệu là:
|
||||
|
||||
- Chính xác - Đảm bảo dữ liệu sản xuất chính xác, bên cạnh đó chúng ta cần đảm bảo rằng dữ liệu của chúng ta dưới dạng sao lưu cũng hoạt động và đã được kiểm tra để khôi phục chắc chắn nếu xảy ra sự cố hoặc lý do gì đó, chúng ta cần phải có thể hoạt động trở lại một cách nhanh chóng.
|
||||
|
||||
- Nhất quán - Nếu dịch vụ dữ liệu của chúng ta bao gồm nhiều hệ thống thì chúng ta cần đảm bảo rằng chúng ta có sự nhất quán trên tất cả các vị trí dữ liệu để chúng ta có được dữ liệu chính xác, điều này cũng bao gồm bảo vệ dữ liệu, đặc biệt là các dịch vụ dữ liệu chúng ta cần đảm bảo sự nhất quán ở các mức khác nhau để đảm bảo rằng chúng ta có một bản sao dữ liệu sạch cho dữ liệu được sao lưu, bản sao replica vv.
|
||||
|
||||
- Bảo mật - Kiểm soát truy cập dữ liệu, nói chung, là một chủ đề nóng hiện nay trên toàn cầu. Đảm bảo rằng chỉ những người có quyền truy cập vào dữ liệu của bạn là rất quan trọng, một lần nữa chúng ta phải đảm bảo rằng chỉ những nhân viên cần thiết có quyền truy cập vào sao lưu và khả năng khôi phục từ chúng cũng như sao chép và cung cấp các phiên bản khác của dữ liệu doanh nghiệp.
|
||||
|
||||
Dữ liệu tốt = Quyết định tốt hơn
|
||||
|
||||
### Tuần về Quản Lý Dữ Liệu
|
||||
|
||||
Trong 6 bài viết tiếp theo, chúng ta sẽ xem xét kỹ hơn về Cơ sở dữ liệu, Sao lưu & Phục hồi, Khôi phục thảm họa, tất cả đều đi kèm với các yếu tố minh họa và thực hành.
|
||||
|
||||
## Tài liệu tham khảo
|
||||
|
||||
- [Kubernetes Backup and Restore made easy!](https://www.youtube.com/watch?v=01qcYSck1c4&t=217s)
|
||||
- [Kubernetes Backups, Upgrades, Migrations - with Velero](https://www.youtube.com/watch?v=zybLTQER0yY)
|
||||
- [7 Database Paradigms](https://www.youtube.com/watch?v=W2Z7fbCLSTw&t=520s)
|
||||
- [Disaster Recovery vs. Backup: What's the difference?](https://www.youtube.com/watch?v=07EHsPuKXc0)
|
||||
- [Veeam Portability & Cloud Mobility](https://www.youtube.com/watch?v=hDBlTdzE6Us&t=3s)
|
||||
|
||||
Hẹn gặp lại vào [ngày 85](day85.md)
|
||||
152
2022/vi/Days/day85.md
Normal file
152
2022/vi/Days/day85.md
Normal file
@ -0,0 +1,152 @@
|
||||
---
|
||||
title: '#90DaysOfDevOps - Dịch vụ dữ liệu - Ngày 85'
|
||||
published: false
|
||||
description: 90DaysOfDevOps - Dịch vụ dữ liệu
|
||||
tags: 'devops, 90daysofdevops, learning'
|
||||
cover_image: null
|
||||
canonical_url: null
|
||||
id: 1048781
|
||||
---
|
||||
|
||||
## Dịch vụ dữ liệu
|
||||
|
||||
Cơ sở dữ liệu là loại dịch vụ dữ liệu phổ biến nhất mà chúng ta gặp phải trong môi trường của chúng ta. Tôi muốn dành bài viết này để khám phá một số loại cơ sở dữ liệu khác nhau và một số trường hợp sử dụng của chúng. Một số trong số chúng đã được sử dụng trong các bài viết trước đây.
|
||||
|
||||
Từ quan điểm phát triển ứng dụng, việc chọn dịch vụ dữ liệu hoặc cơ sở dữ liệu phù hợp sẽ là một quyết định quan trọng đối với hiệu suất và khả năng mở rộng của ứng dụng của bạn.
|
||||
|
||||
https://www.youtube.com/watch?v=W2Z7fbCLSTw
|
||||
|
||||
### Cơ sở dữ liệu Key-Value
|
||||
|
||||
Cơ sở dữ liệu Key-Value là loại cơ sở dữ liệu phi quan hệ sử dụng phương pháp key-value đơn giản để lưu trữ dữ liệu. Cơ sở dữ liệu key-value lưu trữ dữ liệu dưới dạng một bộ các cặp key-value, trong đó key là một định danh duy nhất. Cả key và value có thể là bất cứ thứ gì, từ đối tượng đơn giản đến đối tượng phức tạp. Cơ sở dữ liệu key-value có khả năng phân tán cao và cho phép mở rộng ngang ở các quy mô mà các loại cơ sở dữ liệu khác không thể đạt được.
|
||||
|
||||
Một ví dụ về cơ sở dữ liệu Key-Value là Redis.
|
||||
|
||||
_Redis là một in-memory data structure store, được sử dụng như một cơ sở dữ liệu phân tán, cơ sở dữ liệu key-value trong bộ nhớ, bộ nhớ đệm và message broker. Redis hỗ trợ các cấu trúc dữ liệu trừu tượng khác nhau, như strings, lists, maps, sets, sorted sets, HyperLogLogs, bitmaps, streams và spatial indices._
|
||||
|
||||
|
||||
|
||||
Như bạn có thể thấy từ mô tả về Redis, điều này có nghĩa là cơ sở dữ liệu của chúng ta nhanh nhưng chúng ta có hạn chế về không gian như một sự đánh đổi. Ngoài ra, không có truy vấn hoặc liên kết nào, điều đó có nghĩa là các tùy chọn mô hình hóa dữ liệu rất hạn chế.
|
||||
|
||||
Thích hợp cho:
|
||||
|
||||
- Bộ nhớ đệm (Caching)
|
||||
- Đăng ký tin nhắn (Pub/Sub)
|
||||
- Bảng xếp hạng (Leaderboards)
|
||||
- Giỏ hàng mua sắm (Shopping carts)
|
||||
|
||||
Thường được sử dụng như một bộ nhớ đệm trên một lớp dữ liệu cố định khác.
|
||||
|
||||
### Cột rộng (Wide Column)
|
||||
|
||||
Cơ sở dữ liệu cột rộng là một cơ sở dữ liệu NoSQL sắp xếp lưu trữ dữ liệu vào các cột linh hoạt có thể được phân tán trên nhiều máy chủ hoặc nút cơ sở dữ liệu, sử dụng ánh xạ đa chiều để tham chiếu dữ liệu theo cột, hàng và timestamp.
|
||||
|
||||
_Cassandra là một hệ thống quản lý cơ sở dữ liệu NoSQL cột rộng, phân tán, mã nguồn mở, miễn phí được thiết kế để xử lý lượng lớn dữ liệu trên nhiều máy chủ, cung cấp tính sẵn có cao mà không có single point of failure._
|
||||
|
||||
|
||||
|
||||
Không có schame đồng nghĩa là có thể xử lý dữ liệu không cấu trúc và điều này có thể được coi là một điểm mạnh đối với một số workload.
|
||||
|
||||
Thích hợp cho:
|
||||
|
||||
- Dữ liệu chuỗi thời gian (Time-Series)
|
||||
- Hồ sơ lịch sử (Historical Records)
|
||||
- Ghi cao, Đọc thấp (High-Write, Low-Read)
|
||||
|
||||
### Tài liệu (Document)
|
||||
|
||||
Cơ sở dữ liệu tài liệu (còn được gọi là cơ sở dữ liệu hướng tài liệu hoặc kho lưu trữ tài liệu) là một cơ sở dữ liệu lưu trữ thông tin dưới dạng tài liệu.
|
||||
|
||||
_MongoDB là một cơ sở dữ liệu hướng tài liệu cross-platform. Được phân loại là cơ sở dữ liệu NoSQL, MongoDB sử dụng các tài liệu giống JSON với các schema tùy chọn. MongoDB được phát triển bởi MongoDB Inc. và được cấp phép theo Server Side Public License._
|
||||
|
||||
|
||||
|
||||
Các cơ sở dữ liệu tài liệu NoSQL cho phép các doanh nghiệp lưu trữ dữ liệu đơn giản mà không cần sử dụng mã SQL phức tạp. Lưu trữ nhanh chóng mà không làm giảm độ tin cậy.
|
||||
|
||||
Thích hợp cho:
|
||||
|
||||
- Hầu hết các ứng dụng
|
||||
- Trò chơi (Games)
|
||||
- Internet of Things (IoT)
|
||||
|
||||
### Quan hệ (Relational)
|
||||
|
||||
Nếu bạn là người mới với cơ sở dữ liệu nhưng bạn đã biết về chúng, tôi đoán rằng bạn đã từng sử dụng một cơ sở dữ liệu quan hệ.
|
||||
|
||||
Cơ sở dữ liệu quan hệ là một cơ sở dữ liệu số dựa trên mô hình dữ liệu quan hệ, như đề xuất bởi E. F. Codd vào năm 1970. Một hệ thống được sử dụng để duy trì các cơ sở dữ liệu quan hệ là hệ thống quản lý cơ sở dữ liệu quan hệ. Nhiều hệ thống cơ sở dữ liệu quan hệ có tùy chọn sử dụng SQL để truy vấn và duy trì cơ sở dữ liệu.
|
||||
|
||||
_MySQL là một hệ thống quản lý cơ sở dữ liệu quan hệ mã nguồn mở. Tên của nó là sự kết hợp của "My", tên của cô con gái của người đồng sáng lập Michael Widenius, và "SQL", viết tắt của Structured Query Language._
|
||||
|
||||
MySQL là một ví dụ về cơ sở dữ liệu quan hệ, có nhiều lựa chọn khác.
|
||||
|
||||
|
||||
|
||||
Trong khi nghiên cứu về cơ sở dữ liệu quan hệ, thuật ngữ hay viết tắt **ACID** đã được đề cập nhiều lần, (atomicity, consistency, isolation, durability) là một bộ tính chất của transaction cơ sở dữ liệu nhằm đảm bảo tính hợp lệ của dữ liệu dù có lỗi, mất điện và sự cố khác. Trong ngữ cảnh của cơ sở dữ liệu, một chuỗi các thao tác cơ sở dữ liệu thỏa mãn các tính chất ACID (có thể được coi như một thao tác logic đơn trên dữ liệu) được gọi là một transaction. Ví dụ, việc chuyển tiền từ một tài khoản ngân hàng sang một tài khoản khác, thậm chí liên quan đến nhiều thay đổi như giảm số dư tài khoản này và tăng số dư tài khoản kia, là một transaction duy nhất.
|
||||
|
||||
Thích hợp cho:
|
||||
|
||||
- Hầu hết các ứng dụng (Nó đã tồn tại từ nhiều năm, nhưng không có nghĩa là nó là tốt nhất)
|
||||
|
||||
Nó không phù hợp cho dữ liệu không cấu trúc hoặc yêu cần khả năng mở rộng tốt, khi đó NoSQL cung cấp khả năng mở rộng tốt hơn cho một số workload.
|
||||
|
||||
### Đồ thị (Graph)
|
||||
|
||||
Cơ sở dữ liệu đồ thị lưu trữ các node và mối quan hệ thay vì các bảng hoặc tài liệu. Dữ liệu được lưu trữ giống như bạn có thể vẽ ý tưởng trên một bảng trắng. Dữ liệu của bạn được lưu trữ mà không bị giới hạn bởi một mô hình được xác định trước, cho phép một cách linh hoạt để sử dụng.
|
||||
|
||||
_Neo4j là một hệ thống quản lý cơ sở dữ liệu đồ thị được phát triển bởi Neo4j, Inc. Được mô tả bởi các nhà phát triển của nó là một cơ sở dữ liệu ACID tuân thủ với lưu trữ đồ thị và xử lý dữ liệu tự nhiên._
|
||||
|
||||
Thích hợp cho:
|
||||
|
||||
- Đồ thị (Graphs)
|
||||
- Đồ thị tri thức (Knowledge Graphs)
|
||||
- Công cụ đề xuất (Recommendation Engines)
|
||||
|
||||
### Công cụ tìm kiếm (Search Engine)
|
||||
|
||||
Ở phần cuối cùng, chúng ta đã sử dụng một cơ sở dữ liệu công cụ tìm kiếm dưới dạng Elasticsearch.
|
||||
|
||||
Cơ sở dữ liệu công cụ tìm kiếm là loại cơ sở dữ liệu phi quan hệ được dành riêng cho việc tìm kiếm nội dung dữ liệu. Các cơ sở dữ liệu công cụ tìm kiếm sử dụng các chỉ số để phân loại các đặc điểm tương tự nhau của dữ liệu và tạo điều kiện cho khả năng tìm kiếm.
|
||||
|
||||
_Elasticsearch là một công cụ tìm kiếm dựa trên thư viện Lucene. Nó cung cấp một công cụ tìm kiếm toàn văn bản phân tán, đa khách hàng với giao diện web HTTP và JSON documents không cần schema._
|
||||
|
||||
Thích hợp cho:
|
||||
|
||||
- Công cụ tìm kiếm (Search Engines)
|
||||
- Tìm kiếm động (Typeahead)
|
||||
- Tìm kiếm log (Log search)
|
||||
|
||||
### Đa mô hình (Multi-model)
|
||||
|
||||
Một cơ sở dữ liệu đa mô hình là một hệ thống quản lý cơ sở dữ liệu được thiết kế để hỗ trợ nhiều mô hình dữ liệu trên một backend tích hợp duy nhất. Ngược lại, hầu hết các hệ thống quản lý cơ sở dữ liệu được tổ chức xung quanh một mô hình dữ liệu duy nhất quy định cách dữ liệu có thể được tổ chức, lưu trữ và điều chỉnh. Mô hình tài liệu, đồ thị, quan hệ và key-value là các ví dụ về các mô hình dữ liệu có thể được hỗ trợ bởi một cơ sở dữ liệu đa mô hình.
|
||||
|
||||
_Fauna là một cơ sở dữ liệu linh hoạt, thân thiện với nhà phát triển, cơ sở dữ liệu transactional qua một cloud API an toàn và mở rộng với native GraphQL._
|
||||
|
||||
Thích hợp cho:
|
||||
|
||||
- Bạn không bị giới hạn bởi việc phải chọn một mô hình dữ liệu
|
||||
- Tuân thủ ACID
|
||||
- Nhanh
|
||||
- Không khó khăn trong việc khởi tạo
|
||||
- Bạn muốn sử dụng dữ liệu của bạn như thế nào và để cloud xử lý những tác vụ nặng
|
||||
|
||||
Chúng ta sẽ kết thúc bài viết giới thiệu cơ sở dữ liệu này, bất kể bạn đang hoạt động trong ngành nghề nào bạn cũng sẽ gặp phải cơ sở dữ liệu. Chúng ta sẽ xem xét một số ví dụ và tìm hiểu cách quản lý dữ liệu, đặc biệt là bảo vệ và lưu trữ các dịch vụ dữ liệu này sau này trong phần tiếp theo.
|
||||
|
||||
Dưới đây là các tài liệu tham khảo, bạn có thể dành 90 năm để tìm hiểu sâu về tất cả các loại cơ sở dữ liệu và mọi thứ đi kèm với nó.
|
||||
|
||||
## Tài liệu tham khảo
|
||||
|
||||
- [Redis Crash Course - the What, Why and How to use Redis as your primary database](https://www.youtube.com/watch?v=OqCK95AS-YE)
|
||||
- [Redis: How to setup a cluster - for beginners](https://www.youtube.com/watch?v=GEg7s3i6Jak)
|
||||
- [Redis on Kubernetes for beginners](https://www.youtube.com/watch?v=JmCn7k0PlV4)
|
||||
- [Intro to Cassandra - Cassandra Fundamentals](https://www.youtube.com/watch?v=YjYWsN1vek8)
|
||||
- [MongoDB Crash Course](https://www.youtube.com/watch?v=ofme2o29ngU)
|
||||
- [MongoDB in 100 Seconds](https://www.youtube.com/watch?v=-bt_y4Loofg)
|
||||
- [What is a Relational Database?](https://www.youtube.com/watch?v=OqjJjpjDRLc)
|
||||
- [Learn PostgreSQL Tutorial - Full Course for Beginners](https://www.youtube.com/watch?v=qw--VYLpxG4)
|
||||
- [MySQL Tutorial for Beginners [Full Course]](https://www.youtube.com/watch?v=7S_tz1z_5bA)
|
||||
- [What is a graph database? (in 10 minutes)](https://www.youtube.com/watch?v=REVkXVxvMQE)
|
||||
- [What is Elasticsearch?](https://www.youtube.com/watch?v=ZP0NmfyfsoM)
|
||||
- [FaunaDB Basics - The Database of your Dreams](https://www.youtube.com/watch?v=2CipVwISumA)
|
||||
- [Fauna Crash Course - Covering the Basics](https://www.youtube.com/watch?v=ihaB7CqJju0)
|
||||
|
||||
Hẹn gặp lại vào [ngày 86](day86.md)
|
||||
180
2022/vi/Days/day86.md
Normal file
180
2022/vi/Days/day86.md
Normal file
@ -0,0 +1,180 @@
|
||||
---
|
||||
title: '#90DaysOfDevOps - Sao lưu tất cả các nền tảng - Ngày 86'
|
||||
published: false
|
||||
description: 90DaysOfDevOps - Sao lưu tất cả các nền tảng
|
||||
tags: 'devops, 90daysofdevops, learning'
|
||||
cover_image: null
|
||||
canonical_url: null
|
||||
id: 1049058
|
||||
---
|
||||
|
||||
## Sao lưu tất cả các nền tảng
|
||||
|
||||
Trong suốt quá trình học, chúng ta đã thảo luận về nhiều nền tảng và môi trường khác nhau. Một điểm chung giữa chúng là tất cả đều cần một mức độ bảo vệ dữ liệu nào đó.
|
||||
|
||||
Bảo vệ dữ liệu đã tồn tại từ rất lâu, nhưng lượng dữ liệu khổng lồ mà chúng ta có ngày nay và giá trị của dữ liệu này khiến chúng ta phải đảm bảo rằng chúng ta không chỉ có khả năng chịu đựng sự cố hạ tầng bằng cách có nhiều nodes và khả năng sẵn sàng cao trên các ứng dụng, mà còn phải xem xét rằng chúng ta cần có một bản sao của dữ liệu đó, dữ liệu quan trọng, ở một vị trí an toàn và bảo mật nếu xảy ra sự cố.
|
||||
|
||||
Chúng ta nghe rất nhiều về tội phạm mạng và ransomware ngày nay, và đừng hiểu lầm, đây là một mối đe dọa lớn và tôi khẳng định rằng bạn sẽ bị tấn công bởi ransomware. Vấn đề không phải là nếu mà là khi nào. Vì vậy, càng có lý do để đảm bảo rằng bạn đã bảo vệ dữ liệu của mình cho khi điều đó xảy ra. Tuy nhiên, nguyên nhân phổ biến nhất gây mất dữ liệu không phải là ransomware hay tội phạm mạng mà đơn giản là xóa nhầm!
|
||||
|
||||
Chúng ta đều đã từng làm điều đó, xóa một thứ gì đó mà không nên xoá và ngay lập tức hối hận.
|
||||
|
||||
Với tất cả công nghệ và tự động hóa mà chúng ta đã thảo luận trong thử thách, yêu cầu bảo vệ bất kỳ dữ liệu trạng thái nào hoặc thậm chí cấu hình không trạng thái phức tạp vẫn tồn tại, bất kể nền tảng nào.
|
||||
|
||||
|
||||
|
||||
Nhưng chúng ta nên có khả năng thực hiện việc bảo vệ dữ liệu đó với tư duy tự động hóa và có thể tích hợp nó vào quy trình làm việc của chúng ta.
|
||||
|
||||
Nếu chúng ta nhìn vào sao lưu là gì:
|
||||
|
||||
_Trong công nghệ thông tin, sao lưu, hay sao lưu dữ liệu, là một bản sao của dữ liệu máy tính được lấy và lưu trữ ở nơi khác để có thể sử dụng để khôi phục bản gốc sau sự cố mất dữ liệu. Dạng động từ, chỉ quá trình thực hiện, là "back up", trong khi dạng danh từ và tính từ là "backup"._
|
||||
|
||||
Nếu chúng ta chia nhỏ điều này thành dạng đơn giản nhất, sao lưu là copy and paste dữ liệu vào một vị trí mới. Đơn giản tôi có thể sao lưu ngay bây giờ bằng cách sao chép một tệp từ ổ C: của tôi sang ổ D: và tôi sẽ có một bản sao trong trường hợp có sự cố xảy ra với ổ C: hoặc có gì đó bị chỉnh sửa sai trong các tệp. Tôi có thể khôi phục từ bản sao tôi có trên ổ D:. Bây giờ nếu máy tính của tôi chết nơi cả ổ C & D thì tôi không được bảo vệ, vì vậy tôi phải xem xét một giải pháp hoặc một bản sao dữ liệu ngoài hệ thống của tôi có thể vào một ổ NAS trong nhà tôi? Nhưng sau đó điều gì xảy ra nếu có gì đó xảy ra với nhà tôi, có lẽ tôi cần xem xét lưu trữ nó trên một hệ thống khác ở một vị trí khác, có thể cloud là một lựa chọn. Có lẽ tôi có thể lưu trữ một bản sao của các tệp quan trọng của mình ở nhiều vị trí để giảm thiểu rủi ro sự cố?
|
||||
|
||||
### Phương pháp sao lưu 3-2-1
|
||||
|
||||
Bây giờ có vẻ là thời điểm tốt để nói về quy tắc hoặc phương pháp sao lưu 3-2-1. Tôi đã có một [bài nói nhanh](https://www.youtube.com/watch?v=5wRt1bJfKBw) về chủ đề này.
|
||||
|
||||
Chúng ta đã đề cập trước đây một số lý do cực đoan về việc tại sao chúng ta cần bảo vệ dữ liệu của mình nhưng dưới đây là một vài lý do nữa:
|
||||
|
||||
|
||||
|
||||
Điều này cho phép tôi nói về phương pháp 3-2-1. Bản sao hoặc bản sao lưu đầu tiên của dữ liệu của tôi nên càng gần với môi trường sản xuất của tôi càng tốt, lý do cho điều này dựa trên tốc độ khôi phục và lại trở lại với điểm ban đầu về xóa nhầm, đây sẽ là lý do phổ biến nhất cho khôi phục. Nhưng tôi muốn lưu trữ nó trên một phương tiện thứ hai phù hợp bên ngoài môi trường sản xuất ban đầu.
|
||||
|
||||
Sau đó, chúng ta muốn đảm bảo rằng chúng ta cũng gửi một bản sao dữ liệu của mình ra ngoài hoặc ngoài site, đây là nơi mà vị trí thứ hai xuất hiện, có thể là một ngôi nhà khác, tòa nhà, trung tâm dữ liệu hoặc public cloud.
|
||||
|
||||
|
||||
|
||||
### Trách nhiệm sao lưu
|
||||
|
||||
Chúng ta có thể đã nghe tất cả các huyền thoại khi nói đến không cần sao lưu, những điều như "Mọi thứ đều là stateless". Nếu mọi thứ đều stateless thì công việc là gì? không có cơ sở dữ liệu? tài liệu word? Có một mức độ trách nhiệm đối với mỗi cá nhân trong doanh nghiệp để đảm bảo rằng họ được bảo vệ nhưng có lẽ đội ngũ vận hành sẽ phải đảm bảo quá trình sao lưu cho các ứng dụng và dữ liệu quan trọng.
|
||||
|
||||
Một câu chuyện khác nữa là "Đảm bảo khả năng sẵn sàng cao chính là phương án backup tốt nhất, chúng tôi đã tích hợp nhiều nodes vào cụm của mình, không có cách nào cụm này bị hỏng!" nhưng khi bạn mắc lỗi đối với cơ sở dữ liệu và lỗi được sao chép trên tất cả các nodes trong cụm, hoặc khi bị cháy, lũ lụt, có nghĩa là cụm không còn khả dụng và cùng với đó là dữ liệu quan trọng. Đó không phải là về việc cứng đầu mà là về việc nhận thức về dữ liệu và dịch vụ, mọi người có thể tính đến khả năng sẵn sàng cao và chịu lỗi trong kiến trúc của họ nhưng điều đó không thay thế yêu cầu sao lưu dữ liệu!
|
||||
|
||||
Sao chép dữ liệu cũng có thể khiến chúng ta cảm thấy an toàn khi có bản sao ngoài site của dữ liệu và có thể cụm được đề cập ở trên được đặt ở nhiều vị trí. Tuy nhiên, lỗi vận hành sẽ vẫn được sao chép nếu nó xảy ra. Nhưng một yêu cầu sao lưu nên đi kèm với với sao chép ứng dụng hoặc sao chép hệ thống trong cùng môi trường.
|
||||
|
||||
Bây giờ bạn có thể cực đoan và bắt đầu gửi bản sao dữ liệu đến quá nhiều vị trí sẽ không chỉ tốn kém mà còn tăng nguy cơ bị tấn công vì diện tích bề mặt của bạn bây giờ đã mở rộng đáng kể.
|
||||
|
||||
Dù sao, ai là người đảm nhận việc sao lưu? Nó sẽ khác nhau trong mỗi doanh nghiệp nhưng ai đó nên tự mình hiểu các yêu cầu sao lưu và cũng phải hiểu kế hoạch khôi phục!
|
||||
|
||||
### Không ai quan tâm cho đến khi mọi người đều quan tâm
|
||||
|
||||
Sao lưu là một ví dụ điển hình, không ai quan tâm đến sao lưu cho đến khi bạn cần khôi phục một cái gì đó. Cùng với yêu cầu sao lưu dữ liệu của chúng ta, chúng ta cũng cần xem xét cách chúng ta khôi phục!
|
||||
|
||||
Với ví dụ về tài liệu văn bản của chúng ta, chúng ta đang nói về các tệp rất nhỏ nên khả năng sao chép qua lại rất dễ dàng và nhanh chóng. Nhưng nếu chúng ta có các tệp trên 100GB thì điều này sẽ mất thời gian. Ngoài ra, chúng ta phải xem xét mức độ mà chúng ta cần khôi phục nếu chúng ta lấy một máy ảo làm ví dụ.
|
||||
|
||||
Chúng ta có toàn bộ Máy Ảo, chúng ta có Hệ Điều Hành, cài đặt Ứng Dụng và sau đó nếu đây là một máy chủ cơ sở dữ liệu chúng ta sẽ có một số tệp cơ sở dữ liệu. Nếu chúng ta mắc lỗi và chèn sai dòng mã vào cơ sở dữ liệu của mình, có lẽ tôi không cần khôi phục toàn bộ máy ảo, tôi muốn khôi phục lại một cách chi tiết những gì tôi cần.
|
||||
|
||||
### Kịch bản sao lưu
|
||||
|
||||
Tôi muốn bây giờ bắt đầu xây dựng một kịch bản để bảo vệ một số dữ liệu, cụ thể, tôi muốn bảo vệ một số tệp trên máy cục bộ của tôi (trong trường hợp này là Windows nhưng công cụ tôi sẽ sử dụng không chỉ miễn phí và mã nguồn mở mà còn đa nền tảng) Tôi muốn đảm bảo rằng chúng được bảo vệ đến một thiết bị NAS tôi có tại nhà nhưng cũng vào Object Storage bucket trên cloud.
|
||||
|
||||
Tôi muốn sao lưu dữ liệu quan trọng này, nó tình cờ là 90DaysOfDevOps repository, dù nó cũng đang được gửi lên GitHub - nơi mà bạn có lẽ đang đọc bài viết này ngay bây giờ nhưng điều gì sẽ xảy ra nếu máy của tôi bị chết và GitHub bị hỏng? Làm thế nào để ai đó có thể đọc nội dung nhưng cũng làm thế nào tôi có thể khôi phục dữ liệu đó sang dịch vụ khác?
|
||||
|
||||
|
||||
|
||||
Có rất nhiều công cụ có thể giúp chúng ta đạt được điều này nhưng tôi sẽ sử dụng một công cụ có tên [Kopia](https://kopia.io/) một công cụ sao lưu mã nguồn mở sẽ cho phép chúng ta mã hóa, dedupe và nén các bản sao lưu của mình trong khi vẫn có thể gửi chúng đến nhiều vị trí.
|
||||
|
||||
Bạn sẽ tìm thấy các bản phát hành để tải xuống [tại đây](https://github.com/kopia/kopia/releases) tại thời điểm viết tôi sẽ sử dụng v0.10.6.
|
||||
|
||||
### Cài đặt Kopia
|
||||
|
||||
Có một Kopia CLI và GUI, chúng ta sẽ sử dụng GUI nhưng biết rằng bạn cũng có thể có phiên bản CLI của điều này cho các máy chủ Linux không cung cấp GUI.
|
||||
|
||||
Tôi sẽ sử dụng `KopiaUI-Setup-0.10.6.exe`
|
||||
|
||||
Việc cài đặt tiếp theo sẽ rất nhanh chóng và sau đó khi bạn mở ứng dụng bạn sẽ được chào đón với lựa chọn loại lưu trữ bạn muốn sử dụng làm kho lưu trữ sao lưu của mình.
|
||||
|
||||
|
||||
|
||||
### Thiết lập kho lưu trữ
|
||||
|
||||
Trước tiên, chúng ta muốn thiết lập một kho lưu trữ sử dụng thiết bị NAS cục bộ và chúng ta sẽ làm điều này bằng cách sử dụng SMB, nhưng tôi tin là cũng có thể sử dụng NFS.
|
||||
|
||||
|
||||
|
||||
Trên màn hình tiếp theo, chúng ta sẽ xác định một mật khẩu, mật khẩu này được sử dụng để mã hóa nội dung kho lưu trữ.
|
||||
|
||||
|
||||
|
||||
Bây giờ chúng ta đã cấu hình kho lưu trữ, chúng ta có thể kích hoạt một snapshot tạm thời để bắt đầu ghi dữ liệu vào đó.
|
||||
|
||||
|
||||
|
||||
Đầu tiên chúng ta cần nhập một đường dẫn đến những gì chúng ta muốn snapshot và trong trường hợp này, chúng ta muốn sao chép thư mục `90DaysOfDevOps`. Chúng ta sẽ trở lại việc lập lịch sau.
|
||||
|
||||
|
||||
|
||||
Chúng ta có thể xác định giữ lại snapshot của mình.
|
||||
|
||||
|
||||
|
||||
Có lẽ có những tệp hoặc loại tệp mà chúng ta muốn loại trừ.
|
||||
|
||||
|
||||
|
||||
Nếu chúng ta muốn xác định một lịch trình, chúng ta có thể làm điều này trên màn hình tiếp theo, khi bạn lần đầu tiên tạo snapshot này đây là trang mở để xác định.
|
||||
|
||||
|
||||
|
||||
Và bạn sẽ thấy một số cài đặt khác có thể được xử lý tại đây.
|
||||
|
||||
|
||||
|
||||
Chọn snapshot ngay và dữ liệu sẽ được ghi vào kho lưu trữ của bạn.
|
||||
|
||||
|
||||
|
||||
### Sao lưu ngoài site đến S3
|
||||
|
||||
Với Kopia chúng ta có thể thông qua giao diện người dùng dường như chỉ có một kho lưu trữ được cấu hình tại một thời điểm. Nhưng thông qua giao diện người dùng, chúng ta có thể sáng tạo và có nhiều tệp cấu hình kho lưu trữ để lựa chọn để đạt được mục tiêu của chúng ta là có một bản sao cục bộ và ngoài site trong Object Storate.
|
||||
|
||||
Object Storate service tôi đang chọn để gửi dữ liệu của mình đến sẽ là Google Cloud Storage. Tôi đã đăng nhập vào tài khoản Google Cloud Platform của mình và tạo một storage bucket. Tôi đã cài đặt Google Cloud SDK trên hệ thống của mình và chạy lệnh `gcloud auth application-default login` đã xác thực tôi với tài khoản của tôi.
|
||||
|
||||
|
||||
|
||||
Sau đó, tôi đã sử dụng CLI của Kopia để hiển thị trạng thái hiện tại của kho lưu trữ sau khi chúng ta thêm kho lưu trữ SMB trong các bước trước. Tôi đã làm điều này bằng cách sử dụng lệnh `"C:\Program Files\KopiaUI\resources\server\kopia.exe" --config-file=C:\Users\micha\AppData\Roaming\kopia\repository.config repository status`.
|
||||
|
||||
|
||||
|
||||
Chúng ta bây giờ đã sẵn sàng để thay thế cho bản demo cấu hình của kho lưu trữ, những gì chúng ta có thể làm nếu chúng ta muốn một giải pháp lâu dài để đánh cả hai kho lưu trữ này là chúng ta sẽ tạo một tệp `smb.config` và một tệp `object.config` và có thể chạy cả hai lệnh này để gửi các bản sao dữ liệu của chúng ta đến mỗi vị trí. Để thêm kho lưu trữ của chúng ta chúng ta đã chạy lệnh `"C:\Program Files\KopiaUI\resources\server\kopia.exe" --config-file=C:\Users\micha\AppData\Roaming\kopia\repository.config repository create gcs --bucket 90daysofdevops`.
|
||||
|
||||
Lệnh trên xem xét rằng storage bucket trên Google Cloud mà chúng ta tạo là `90daysofdevops`.
|
||||
|
||||
|
||||
|
||||
Bây giờ chúng ta đã tạo kho lưu trữ mới của mình, chúng ta có thể chạy lại lệnh `"C:\Program Files\KopiaUI\resources\server\kopia.exe" --config-file=C:\Users\micha\AppData\Roaming\kopia\repository.config repository status` và bây giờ sẽ hiển thị cấu hình kho lưu trữ GCS.
|
||||
|
||||
|
||||
|
||||
Bước tiếp theo chúng ta cần làm là tạo một snapshot và gửi nó đến kho lưu trữ vừa tạo của chúng ta. Sử dụng lệnh `"C:\Program Files\KopiaUI\resources\server\kopia.exe" --config-file=C:\Users\micha\AppData\Roaming\kopia\repository.config kopia snapshot create "C:\Users\micha\demo\90DaysOfDevOps"` chúng ta có thể bắt đầu quá trình này. Bạn có thể thấy trong trình duyệt dưới đây rằng storage bucket trên Google Cloud của chúng ta bây giờ có các tệp kopia dựa trên bản sao lưu của chúng ta.
|
||||
|
||||
|
||||
|
||||
Với quy trình trên, chúng ta có thể hoàn thành yêu cầu của mình là gửi dữ liệu quan trọng của chúng ta đến 2 vị trí khác nhau, một trong số đó là ngoài site trong Google Cloud Storage và tất nhiên chúng ta vẫn có bản sao sản xuất của dữ liệu của mình trên một loại phương tiện khác.
|
||||
|
||||
### Khôi phục
|
||||
|
||||
Khôi phục là một cân nhắc khác và rất quan trọng, Kopia cho phép chúng ta không chỉ khôi phục về vị trí hiện tại mà còn cả vị trí mới.
|
||||
|
||||
Nếu chúng ta chạy lệnh `"C:\Program Files\KopiaUI\resources\server\kopia.exe" --config-file=C:\Users\micha\AppData\Roaming\kopia\repository.config snapshot list` điều này sẽ liệt kê các snapshot mà chúng ta hiện có trong kho lưu trữ được cấu hình (GCS).
|
||||
|
||||
|
||||
|
||||
Chúng ta sau đó có thể gắn các snapshot đó trực tiếp từ GCS bằng cách sử dụng lệnh `"C:\Program Files\KopiaUI\resources\server\kopia.exe" --config-file=C:\Users\micha\AppData\Roaming\kopia\repository.config mount all Z:`.
|
||||
|
||||
|
||||
|
||||
Chúng ta cũng có thể khôi phục nội dugn của snapshot bằng lệnh `kopia snapshot restore kdbd9dff738996cfe7bcf99b45314e193`
|
||||
|
||||
Các lệnh trên rất dài và điều này là do tôi đang sử dụng phiên bản KopiaUI của kopia.exe như được giải thích ở đầu hướng dẫn, bạn có thể tải xuống kopia.exe và đặt nó vào một thư mục path để bạn chỉ cần sử dụng lệnh `kopia `.
|
||||
|
||||
Trong bài viết tiếp theo, chúng ta sẽ tập trung vào việc bảo vệ các dữ liệu trong Kubernetes.
|
||||
## Tài liệu tham khảo
|
||||
|
||||
- [Kubernetes Backup and Restore made easy!](https://www.youtube.com/watch?v=01qcYSck1c4&t=217s)
|
||||
- [Kubernetes Backups, Upgrades, Migrations - with Velero](https://www.youtube.com/watch?v=zybLTQER0yY)
|
||||
- [7 Database Paradigms](https://www.youtube.com/watch?v=W2Z7fbCLSTw&t=520s)
|
||||
- [Disaster Recovery vs. Backup: What's the difference?](https://www.youtube.com/watch?v=07EHsPuKXc0)
|
||||
- [Veeam Portability & Cloud Mobility](https://www.youtube.com/watch?v=hDBlTdzE6Us&t=3s)
|
||||
|
||||
Hẹn gặp lại vào [ngày 87](day87.md)
|
||||
190
2022/vi/Days/day87.md
Normal file
190
2022/vi/Days/day87.md
Normal file
@ -0,0 +1,190 @@
|
||||
---
|
||||
title: '#90DaysOfDevOps - Thực hành Sao lưu & Khôi phục - Ngày 87'
|
||||
published: false
|
||||
description: 90DaysOfDevOps - Thực hành Sao lưu & Khôi phục
|
||||
tags: 'devops, 90daysofdevops, learning'
|
||||
cover_image: null
|
||||
canonical_url: null
|
||||
id: 1048717
|
||||
---
|
||||
|
||||
## Thực hành Sao lưu & Khôi phục
|
||||
|
||||
Trong bài viết trước, chúng ta đã nhắc đến [Kopia](https://kopia.io/), một công cụ sao lưu mã nguồn mở mà chúng ta đã sử dụng để sao lưu một số dữ liệu quan trọng vào một thiết bị NAS cục bộ và lưu trữ đối tượng dựa trên đám mây.
|
||||
|
||||
Trong phần này, tôi muốn đi sâu vào thế giới sao lưu Kubernetes. Đây là một nền tảng mà chúng ta đã đề cập đến trong [Bức tranh toàn cảnh: Kubernetes](day49.md) trước đó.
|
||||
|
||||
Chúng ta sẽ tiếp tục sử dụng minikube cluster của mình nhưng lần này chúng ta sẽ tận dụng một số addon có sẵn.
|
||||
|
||||
### Thiết lập Kubernetes clust
|
||||
|
||||
Để thiết lập minikube cluster, chúng ta sẽ thực hiện lệnh `minikube start --addons volumesnapshots,csi-hostpath-driver --apiserver-port=6443 --container-runtime=containerd -p 90daysofdevops --kubernetes-version=1.21.2`. Bạn sẽ nhận thấy rằng chúng ta đang sử dụng `volumesnapshots` và `csi-hostpath-driver` vì chúng ta sẽ tận dụng đầy đủ chúng khi chúng ta thực hiện sao lưu.
|
||||
|
||||
Tại thời điểm này, tôi biết rằng chúng ta chưa triển khai Kasten K10 nhưng chúng ta muốn thực hiện lệnh sau khi cụm của bạn đã sẵn sàng, chúng ta muốn chú thích volumesnapshotclass để Kasten K10 có thể sử dụng nó.
|
||||
|
||||
```Shell
|
||||
kubectl annotate volumesnapshotclass csi-hostpath-snapclass \
|
||||
k10.kasten.io/is-snapshot-class=true
|
||||
```
|
||||
|
||||
Chúng ta cũng sẽ thay đổi storageclass mặc định từ storageclass tiêu chuẩn mặc định sang storageclass csi-hostpath bằng cách sử dụng các lệnh sau.
|
||||
|
||||
```Shell
|
||||
kubectl patch storageclass csi-hostpath-sc -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'
|
||||
|
||||
kubectl patch storageclass standard -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"false"}}}'
|
||||
```
|
||||
|
||||
|
||||
|
||||
### Triển khai Kasten K10
|
||||
|
||||
Thêm repository Helm của Kasten
|
||||
|
||||
`helm repo add kasten https://charts.kasten.io/`
|
||||
|
||||
Chúng ta có thể sử dụng `arkade kasten install k10` ở đây nhưng cho demo này, chúng ta sẽ thực hiện các bước sau. [Chi tiết thêm]((https://blog.kasten.io/kasten-k10-goes-to-the-arkade))
|
||||
|
||||
Tạo namespace và triển khai K10, điều này sẽ mất khoảng 5 phút
|
||||
|
||||
`helm install k10 kasten/k10 --namespace=kasten-io --set auth.tokenAuth.enabled=true --set injectKanisterSidecar.enabled=true --set-string injectKanisterSidecar.namespaceSelector.matchLabels.k10/injectKanisterSidecar=true --create-namespace`
|
||||
|
||||
|
||||
|
||||
Bạn có thể xem các pod xuất hiện bằng cách chạy lệnh sau.
|
||||
|
||||
`kubectl get pods -n kasten-io -w`
|
||||
|
||||
|
||||
|
||||
Chuyển tiếp cổng để truy cập bảng điều khiển K10, mở một terminal mới để chạy lệnh dưới đây
|
||||
|
||||
`kubectl --namespace kasten-io port-forward service/gateway 8080:8000`
|
||||
|
||||
Bảng điều khiển Kasten sẽ khả dụng tại `http://127.0.0.1:8080/k10/#/`
|
||||
|
||||
|
||||
|
||||
Để xác thực với bảng điều khiển, chúng ta cần token mà chúng ta có thể lấy bằng các lệnh sau.
|
||||
|
||||
```Shell
|
||||
TOKEN_NAME=$(kubectl get secret --namespace kasten-io|grep k10-k10-token | cut -d " " -f 1)
|
||||
TOKEN=$(kubectl get secret --namespace kasten-io $TOKEN_NAME -o jsonpath="{.data.token}" | base64 --decode)
|
||||
|
||||
echo "Token value: "
|
||||
echo $TOKEN
|
||||
```
|
||||
|
||||
|
||||
|
||||
Bây giờ chúng ta lấy token này và nhập vào trình duyệt, sau đó bạn sẽ được yêu cầu nhập email và tên công ty.
|
||||
|
||||
|
||||
|
||||
Sau đó, chúng ta sẽ truy cập được vào bảng điều khiển Kasten K10.
|
||||
|
||||
|
||||
|
||||
### Triển khai ứng dụng stateful
|
||||
|
||||
Sử dụng ứng dụng stateful mà chúng ta đã sử dụng trong phần Kubernetes.
|
||||
|
||||
|
||||
|
||||
Bạn có thể tìm thấy tệp cấu hình YAML cho ứng dụng này tại đây -> [pacman-stateful-demo.yaml](../../Days/Kubernetes/pacman-stateful-demo.yaml)
|
||||
|
||||
|
||||
|
||||
Chúng ta có thể sử dụng kubectl get all -n pacman để kiểm tra các pod của chúng ta đang lên.
|
||||
|
||||
|
||||
|
||||
Trong một terminal mới, chúng ta có thể chuyển tiếp cổng cho giao diện Pacman. `kubectl port-forward svc/pacman 9090:80 -n pacman`
|
||||
|
||||
Mở một tab khác trên trình duyệt của bạn với http://localhost:9090/
|
||||
|
||||
|
||||
|
||||
Dành thời gian để ghi lại một số high score trong cơ sở dữ liệu MongoDB ở backend.
|
||||
|
||||
|
||||
|
||||
### Bảo vệ bảng điểm high score
|
||||
|
||||
Bây giờ chúng ta có một số dữ liệu quan trọng trong cơ sở dữ liệu của mình và chúng ta không muốn mất nó. Chúng ta có thể sử dụng Kasten K10 để bảo vệ toàn bộ ứng dụng này.
|
||||
|
||||
Nếu chúng ta quay lại tab bảng điều khiển Kasten K10, bạn sẽ thấy rằng số lượng ứng dụng của chúng ta đã tăng từ 1 lên 2 với việc thêm ứng dụng Pacman vào cụm Kubernetes của chúng ta.
|
||||
|
||||
|
||||
|
||||
Nếu bạn nhấp vào thẻ Applications, bạn sẽ thấy các ứng dụng được tự động phát hiện trong cụm của chúng ta.
|
||||
|
||||
|
||||
|
||||
Với Kasten K10, chúng ta có thể tận dụng các snapshot dựa trên lưu trữ cũng như xuất các bản sao của chúng ta ra các tùy chọn lưu trữ đối tượng.
|
||||
|
||||
Cho demo này, chúng ta sẽ tạo một snapshot lưu trữ thủ công trong cụm của chúng ta và sau đó chúng ta có thể thêm một số dữ liệu sai vào bảng high score để mô phỏng một lỗi ngẫu nhiên đã xảy ra hay không?
|
||||
|
||||
Trước tiên, chúng ta có thể sử dụng tùy chọn snapshot thủ công dưới đây.
|
||||
|
||||
|
||||
|
||||
Cho demo này, tôi sẽ để mọi thứ mặc định
|
||||
|
||||
|
||||
|
||||
Trở lại bảng điều khiển, bạn sẽ nhận được báo cáo trạng thái về công việc khi nó đang chạy và khi hoàn thành, nó sẽ trông giống như thành công như thế này.
|
||||
|
||||
|
||||
|
||||
### Kịch bản sự cố
|
||||
|
||||
Chúng ta bây giờ có thể thực hiện thay đổi nguy hiểm đó đối với dữ liệu quan trọng của chúng ta bằng cách đơn giản thêm vào một thay đổi xấu được dự kién vào ứng dụng của chúng ta.
|
||||
|
||||
Như bạn có thể thấy dưới đây, chúng ta có hai inputs mà có lẽ chúng ta không muốn trong cơ sở dữ liệu quan trọng của mình.
|
||||
|
||||
|
||||
|
||||
### Khôi phục dữ liệu
|
||||
|
||||
Đây là một demo đơn giản và theo một cách nào đó không thực tế mặc dù bạn đã thấy dễ dàng như thế nào để xóa cơ sở dữ liệu?
|
||||
|
||||
Bây giờ chúng ta muốn làm cho danh sách high score trông gọn hơn và quay về lúc trước khi những sai lầm xảy ra.
|
||||
|
||||
Quay lại thẻ Applications và trên tab Pacman, chúng ta hiện có 1 điểm khôi phục mà chúng ta có thể sử dụng để khôi phục.
|
||||
|
||||
|
||||
|
||||
Khi bạn chọn khôi phục, bạn có thể thấy tất cả các snapshot và xuất liên quan đến ứng dụng đó.
|
||||
|
||||
|
||||
|
||||
Chọn khôi phục và một cửa sổ bên sẽ xuất hiện, chúng ta sẽ giữ các cài đặt mặc định và nhấn khôi phục.
|
||||
|
||||
|
||||
|
||||
Xác nhận rằng bạn muốn thực hiện điều này.
|
||||
|
||||
|
||||
|
||||
Sau đó, bạn có thể quay lại bảng điều khiển và xem tiến trình của khôi phục. Bạn sẽ thấy điều gì đó như thế này.
|
||||
|
||||
|
||||
|
||||
Nhưng quan trọng hơn, danh sách high score của chúng ta trong ứng dụng quan trọng của chúng ta trông như thế nào. Bạn sẽ phải bắt đầu lại chuyển tiếp cổng đến Pacman như chúng ta đã đề cập trước đó.
|
||||
|
||||
|
||||
|
||||
Một demo siêu đơn giản và chỉ thực sự ở lớp bề mặt của những gì Kasten K10 có thể đạt được khi nói đến sao lưu. Tôi sẽ tạo một số nội dung video chi tiết hơn về một số lĩnh vực này trong tương lai. Chúng ta cũng sẽ sử dụng Kasten K10 để làm nổi bật một số lĩnh vực nổi bật khác về Quản lý Dữ liệu khi nói đến Khôi phục Thảm họa và khả năng di chuyển dữ liệu của bạn.
|
||||
|
||||
Tiếp theo, chúng ta sẽ xem xét sự nhất quán của Ứng dụng.
|
||||
|
||||
## Tài liệu tham khảo
|
||||
|
||||
- [Kubernetes Backup and Restore made easy!](https://www.youtube.com/watch?v=01qcYSck1c4&t=217s)
|
||||
- [Kubernetes Backups, Upgrades, Migrations - with Velero](https://www.youtube.com/watch?v=zybLTQER0yY)
|
||||
- [7 Database Paradigms](https://www.youtube.com/watch?v=W2Z7fbCLSTw&t=520s)
|
||||
- [Disaster Recovery vs. Backup: What's the difference?](https://www.youtube.com/watch?v=07EHsPuKXc0)
|
||||
- [Veeam Portability & Cloud Mobility](https://www.youtube.com/watch?v=hDBlTdzE6Us&t=3s)
|
||||
|
||||
Hẹn gặp lại vào [ngày 88](day88.md)
|
||||
294
2022/vi/Days/day88.md
Normal file
294
2022/vi/Days/day88.md
Normal file
@ -0,0 +1,294 @@
|
||||
---
|
||||
title: '#90DaysOfDevOps - Sao lưu theo hướng tập trung vào ứng dụng - Ngày 88'
|
||||
published: false
|
||||
description: 90DaysOfDevOps - Application Focused Backups
|
||||
tags: 'devops, 90daysofdevops, learning'
|
||||
cover_image: null
|
||||
canonical_url: null
|
||||
id: 1048749
|
||||
---
|
||||
|
||||
## Sao lưu theo hướng tập trung vào ứng dụng
|
||||
|
||||
Chúng ta đã dành thời gian nói về các dịch vụ dữ liệu hoặc các ứng dụng đòi hỏi nhiều dữ liệu như cơ sở dữ liệu vào [Ngày 85](day85.md). Đối với các dịch vụ dữ liệu này, chúng ta phải xem xét cách quản lý tính nhất quán, đặc biệt khi nói đến tính nhất quán của ứng dụng.
|
||||
|
||||
Trong bài viết này, chúng ta sẽ đi sâu vào yêu cầu bảo vệ dữ liệu ứng dụng một cách nhất quán.
|
||||
|
||||
Để làm điều này, công cụ chúng ta chọn sẽ là [Kanister](https://kanister.io/)
|
||||
|
||||
|
||||
|
||||
### Giới thiệu về Kanister
|
||||
|
||||
Kanister là một dự án mã nguồn mở của Kasten, cho phép chúng ta quản lý (sao lưu và khôi phục) dữ liệu ứng dụng trên Kubernetes. Bạn có thể triển khai Kanister như một ứng dụng helm vào cụm Kubernetes của mình.
|
||||
|
||||
Kanister sử dụng các tài nguyên tùy chỉnh của Kubernetes, các tài nguyên tùy chỉnh chính được cài đặt khi Kanister được triển khai là
|
||||
|
||||
- `Profile` - là một vị trí mục tiêu để lưu trữ các bản sao lưu và khôi phục từ đó. Thông thường nhất, đây sẽ là lưu trữ đối tượng.
|
||||
- `Blueprint` - các bước cần thực hiện để sao lưu và khôi phục cơ sở dữ liệu nên được duy trì trong Blueprint.
|
||||
- `ActionSet` - là hành động để chuyển bản sao lưu của chúng ta đến `Profile` của chúng ta cũng như các hành động khôi phục.
|
||||
|
||||
### Hướng dẫn Thực hiện
|
||||
|
||||
Trước khi thực hành, chúng ta nên xem qua quy trình mà Kanister thực hiện để bảo vệ dữ liệu ứng dụng. Đầu tiên, controller được triển khai bằng helm vào cụm Kubernetes, Kanister sống trong namespace của nó. Chúng ta lấy Blueprint của mình, có nhiều blueprint hỗ trợ cộng đồng có sẵn, chúng ta sẽ trình bày chi tiết hơn về điều này ngay sau đây. Sau đó, chúng ta có workload cơ sở dữ liệu của mình.
|
||||
|
||||
|
||||
|
||||
Chúng ta sau đó tạo ActionSet của mình.
|
||||
|
||||
|
||||
|
||||
ActionSet cho phép chúng ta chạy các hành động được định nghĩa trong blueprint với dịch vụ dữ liệu cụ thể.
|
||||
|
||||
|
||||
|
||||
ActionSet lần lượt sử dụng các chức năng của Kanister (KubeExec, KubeTask, Resource Lifecycle) và đẩy bản sao lưu của chúng ta đến kho lưu trữ mục tiêu của chúng ta (Profile).
|
||||
|
||||
|
||||
|
||||
Nếu hành động đó hoàn thành/thất bại, trạng thái tương ứng được cập nhật trong ActionSet.
|
||||
|
||||
|
||||
|
||||
### Triển khai Kanister
|
||||
|
||||
Một lần nữa, chúng ta sẽ sử dụng cụm minikube để thực hiện sao lưu ứng dụng này. Nếu bạn vẫn chạy nó từ phiên trước, chúng ta có thể tiếp tục sử dụng.
|
||||
|
||||
Tại thời điểm viết bài này, chúng ta đang ở image version `0.75.0`, với lệnh helm sau, chúng ta sẽ cài đặt kanister vào cụm Kubernetes của mình.
|
||||
|
||||
`helm install kanister --namespace kanister kanister/kanister-operator --set image.tag=0.75.0 --create-namespace`
|
||||
|
||||
|
||||
|
||||
Chúng ta có thể sử dụng `kubectl get pods -n kanister` để đảm bảo pod đang chạy và sau đó chúng ta cũng có thể kiểm tra các định nghĩa tài nguyên tùy chỉnh của chúng ta hiện có sẵn (Nếu bạn chỉ cài đặt Kanister thì bạn sẽ thấy 3 mục được đánh dấu)
|
||||
|
||||
|
||||
|
||||
### Triển khai một Cơ sở dữ liệu
|
||||
|
||||
Triển khai MySQL qua helm:
|
||||
|
||||
```Shell
|
||||
APP_NAME=my-production-app
|
||||
kubectl create ns ${APP_NAME}
|
||||
helm repo add bitnami https://charts.bitnami.com/bitnami
|
||||
helm install mysql-store bitnami/mysql --set primary.persistence.size=1Gi,volumePermissions.enabled=true --namespace=${APP_NAME}
|
||||
kubectl get pods -n ${APP_NAME} -w
|
||||
```
|
||||
|
||||
|
||||
|
||||
Nạp dữ liệu ban đầu vào cơ sở dữ liệu MySQL, chạy lệnh sau:
|
||||
|
||||
```Shell
|
||||
MYSQL_ROOT_PASSWORD=$(kubectl get secret --namespace ${APP_NAME} mysql-store -o jsonpath="{.data.mysql-root-password}" | base64 --decode)
|
||||
MYSQL_HOST=mysql-store.${APP_NAME}.svc.cluster.local
|
||||
MYSQL_EXEC="mysql -h ${MYSQL_HOST} -u root --password=${MYSQL_ROOT_PASSWORD} -DmyImportantData -t"
|
||||
echo MYSQL_ROOT_PASSWORD=${MYSQL_ROOT_PASSWORD}
|
||||
```
|
||||
### Tạo MySQL CLIENT
|
||||
|
||||
Chúng ta sẽ chạy một container image như một client
|
||||
```Shell
|
||||
APP_NAME=my-production-app
|
||||
kubectl run mysql-client --rm --env APP_NS=${APP_NAME} --env MYSQL_EXEC="${MYSQL_EXEC}" --env MYSQL_ROOT_PASSWORD=${MYSQL_ROOT_PASSWORD} --env MYSQL_HOST=${MYSQL_HOST} --namespace ${APP_NAME} --tty -i --restart='Never' --image docker.io/bitnami/mysql:latest --command -- bash
|
||||
```
|
||||
|
||||
```Shell
|
||||
Note: nếu bạn đã có một pod client MySQL đang chạy, hãy xóa với lệnh
|
||||
|
||||
kubectl delete pod -n ${APP_NAME} mysql-client
|
||||
```
|
||||
|
||||
### Thêm Dữ liệu vào MySQL
|
||||
```Shell
|
||||
echo "create database myImportantData;" | mysql -h ${MYSQL_HOST} -u root --password=${MYSQL_ROOT_PASSWORD}
|
||||
MYSQL_EXEC="mysql -h ${MYSQL_HOST} -u root --password=${MYSQL_ROOT_PASSWORD} -DmyImportantData -t"
|
||||
echo "drop table Accounts" | ${MYSQL_EXEC}
|
||||
echo "create table if not exists Accounts(name text, balance integer); insert into Accounts values('nick', 0);" | ${MYSQL_EXEC}
|
||||
echo "insert into Accounts values('albert', 112);" | ${MYSQL_EXEC}
|
||||
echo "insert into Accounts values('alfred', 358);" | ${MYSQL_EXEC}
|
||||
echo "insert into Accounts values('beatrice', 1321);" | ${MYSQL_EXEC}
|
||||
echo "insert into Accounts values('bartholomew', 34);" | ${MYSQL_EXEC}
|
||||
echo "insert into Accounts values('edward', 5589);" | ${MYSQL_EXEC}
|
||||
echo "insert into Accounts values('edwin', 144);" | ${MYSQL_EXEC}
|
||||
echo "insert into Accounts values('edwina', 233);" | ${MYSQL_EXEC}
|
||||
echo "insert into Accounts values('rastapopoulos', 377);" | ${MYSQL_EXEC}
|
||||
echo "select * from Accounts;" | ${MYSQL_EXEC}
|
||||
exit
|
||||
```
|
||||
|
||||
Bạn sẽ có thể thấy một số dữ liệu như hình dưới đây.
|
||||
|
||||
|
||||
|
||||
### Tạo Kanister Profile
|
||||
|
||||
Kanister cung cấp một CLI, `kanctl` và một tiện ích khác `kando` được sử dụng để tương tác với nhà cung cấp lưu trữ đối tượng của bạn từ blueprint và cả hai tiện ích này.
|
||||
|
||||
[Tải xuống CLI](https://docs.kanister.io/tooling.html#tooling)
|
||||
|
||||
Tôi đã tạo một AWS S3 bucket mà chúng ta sẽ sử dụng làm profile target và restore location. Tôi sẽ sử dụng các biến môi trường để tôi có thể vẫn hiển thị cho bạn các lệnh tôi đang chạy với `kanctl` để tạo kanister profile.
|
||||
|
||||
`kanctl create profile s3compliant --access-key $ACCESS_KEY --secret-key $SECRET_KEY --bucket $BUCKET --region eu-west-2 --namespace my-production-app`
|
||||
|
||||
|
||||
|
||||
|
||||
### Tạo Blueprint
|
||||
|
||||
Đừng lo lắng bạn không cần phải tạo blueprint của riêng mình từ đầu trừ khi dịch vụ dữ liệu của bạn không được liệt kê ở trong [Kanister Examples](https://github.com/kanisterio/kanister/tree/master/examples) nhưng bằng mọi cách, đóng góp cộng đồng là cách dự án này nâng cao nhận thức.
|
||||
|
||||
Blueprint mà chúng ta sẽ sử dụng là dưới đây.
|
||||
|
||||
```Shell
|
||||
apiVersion: cr.kanister.io/v1alpha1
|
||||
kind: Blueprint
|
||||
metadata:
|
||||
name: mysql-blueprint
|
||||
actions:
|
||||
backup:
|
||||
outputArtifacts:
|
||||
mysqlCloudDump:
|
||||
keyValue:
|
||||
s3path: "{{ .Phases.dumpToObjectStore.Output.s3path }}"
|
||||
phases:
|
||||
- func: KubeTask
|
||||
name: dumpToObjectStore
|
||||
objects:
|
||||
mysqlSecret:
|
||||
kind: Secret
|
||||
name: '{{ index .Object.metadata.labels "app.kubernetes.io/instance" }}'
|
||||
namespace: '{{ .StatefulSet.Namespace }}'
|
||||
args:
|
||||
image: ghcr.io/kanisterio/mysql-sidecar:0.75.0
|
||||
namespace: "{{ .StatefulSet.Namespace }}"
|
||||
command:
|
||||
- bash
|
||||
- -o
|
||||
- errexit
|
||||
- -o
|
||||
- pipefail
|
||||
- -c
|
||||
- |
|
||||
s3_path="/mysql-backups/{{ .StatefulSet.Namespace }}/{{ index .Object.metadata.labels "app.kubernetes.io/instance" }}/{{ toDate "2006-01-02T15:04:05.999999999Z07:00" .Time | date "2006-01-02T15-04-05" }}/dump.sql.gz"
|
||||
root_password="{{ index .Phases.dumpToObjectStore.Secrets.mysqlSecret.Data "mysql-root-password" | toString }}"
|
||||
mysqldump --column-statistics=0 -u root --password=${root_password} -h {{ index .Object.metadata.labels "app.kubernetes.io/instance" }} --single-transaction --all-databases | gzip - | kando location push --profile '{{ toJson .Profile }}' --path ${s3_path} -
|
||||
kando output s3path ${s3_path}
|
||||
restore:
|
||||
inputArtifactNames:
|
||||
- mysqlCloudDump
|
||||
phases:
|
||||
- func: KubeTask
|
||||
name: restoreFromBlobStore
|
||||
objects:
|
||||
mysqlSecret:
|
||||
kind: Secret
|
||||
name: '{{ index .Object.metadata.labels "app.kubernetes.io/instance" }}'
|
||||
namespace: '{{ .StatefulSet.Namespace }}'
|
||||
args:
|
||||
image: ghcr.io/kanisterio/mysql-sidecar:0.75.0
|
||||
namespace: "{{ .StatefulSet.Namespace }}"
|
||||
command:
|
||||
- bash
|
||||
- -o
|
||||
- errexit
|
||||
- -o
|
||||
- pipefail
|
||||
- -c
|
||||
- |
|
||||
s3_path="{{ .ArtifactsIn.mysqlCloudDump.KeyValue.s3path }}"
|
||||
root_password="{{ index .Phases.restoreFromBlobStore.Secrets.mysqlSecret.Data "mysql-root-password" | toString }}"
|
||||
kando location pull --profile '{{ toJson .Profile }}' --path ${s3_path} - | gunzip | mysql -u root --password=${root_password} -h {{ index .Object.metadata.labels "app.kubernetes.io/instance" }}
|
||||
delete:
|
||||
inputArtifactNames:
|
||||
- mysqlCloudDump
|
||||
phases:
|
||||
- func: KubeTask
|
||||
name: deleteFromBlobStore
|
||||
args:
|
||||
image: ghcr.io/kanisterio/mysql-sidecar:0.75.0
|
||||
namespace: "{{ .Namespace.Name }}"
|
||||
command:
|
||||
- bash
|
||||
- -o
|
||||
- errexit
|
||||
- -o
|
||||
- pipefail
|
||||
- -c
|
||||
- |
|
||||
s3_path="{{ .ArtifactsIn.mysqlCloudDump.KeyValue.s3path }}"
|
||||
kando location delete --profile '{{ toJson .Profile }}' --path ${s3_path}
|
||||
```
|
||||
|
||||
Để thêm điều này, chúng ta sẽ sử dụng lệnh `kubectl create -f mysql-blueprint.yml -n kanister`
|
||||
|
||||
|
||||
|
||||
### Tạo ActionSet và Bảo vệ ứng dụng
|
||||
|
||||
Chúng ta sẽ bây giờ thực hiện sao lưu dữ liệu MySQL bằng cách tạo một ActionSet định nghĩa sao lưu cho ứng dụng này. Tạo một ActionSet trong cùng namespace với controller.
|
||||
|
||||
`kubectl get profiles.cr.kanister.io -n my-production-app` Lệnh này sẽ hiển thị profile mà chúng ta đã tạo trước đó, chúng ta có thể có nhiều profile được cấu hình ở đây vì vậy chúng ta có thể muốn sử dụng các profile cụ thể cho các ActionSet khác nhau
|
||||
|
||||
Chúng ta sau đó sẽ tạo ActionSet của mình với lệnh sau sử dụng `kanctl`
|
||||
|
||||
`kanctl create actionset --action backup --namespace kanister --blueprint mysql-blueprint --statefulset my-production-app/mysql-store --profile my-production-app/s3-profile-dc5zm --secrets mysql=my-production-app/mysql-store`
|
||||
|
||||
Bạn có thể thấy từ lệnh trên chúng ta đang định nghĩa blueprint mà chúng ta đã thêm vào namespace, statefulset trong namespace `my-production-app` của chúng ta và cả các secrét để truy cập vào ứng dụng MySQL.
|
||||
|
||||
|
||||
|
||||
Kiểm tra trạng thái của ActionSet bằng cách lấy tên ActionSet và sử dụng lệnh này `kubectl --namespace kanister describe actionset backup-qpnqv`
|
||||
|
||||
Cuối cùng, chúng ta có thể đi và xác nhận rằng hiện đang có dữ liệu trong bucket AWS S3 của mình.
|
||||
|
||||
|
||||
|
||||
### Khôi phục
|
||||
|
||||
Chúng ta cần gây ra một số thiệt hại trước khi có thể khôi phục bất cứ thứ gì, chúng ta có thể làm điều này bằng cách xóa bảng của mình, có thể đó là một tai nạn, có thể không phải.
|
||||
|
||||
Kết nối với pod MySQL của chúng ta.
|
||||
|
||||
```Shell
|
||||
APP_NAME=my-production-app
|
||||
kubectl run mysql-client --rm --env APP_NS=${APP_NAME} --env MYSQL_EXEC="${MYSQL_EXEC}" --env MYSQL_ROOT_PASSWORD=${MYSQL_ROOT_PASSWORD} --env MYSQL_HOST=${MYSQL_HOST} --namespace ${APP_NAME} --tty -i --restart='Never' --image docker.io/bitnami/mysql:latest --command -- bash
|
||||
```
|
||||
|
||||
Bạn có thể thấy rằng cơ sở dữ liệu importantdata của chúng ta ở đó với `echo "SHOW DATABASES;" | ${MYSQL_EXEC}`
|
||||
|
||||
Sau đó để xóa chúng ta chạy `echo "DROP DATABASE myImportantData;" | ${MYSQL_EXEC}`
|
||||
|
||||
Và xác nhận rằng nó đã biến mất với một vài lần thử để hiển thị cơ sở dữ liệu của chúng ta.
|
||||
|
||||
|
||||
|
||||
Chúng ta bây giờ có thể sử dụng Kanister để lấy lại dữ liệu quan trọng của chúng ta bằng cách sử dụng `kubectl get actionset -n kanister` để tìm tên ActionSet mà chúng ta đã lấy trước đó. Sau đó, chúng ta sẽ tạo một ActionSet khôi phục để khôi phục dữ liệu của mình bằng cách sử dụng `kanctl create actionset -n kanister --action restore --from "backup-qpnqv"`
|
||||
|
||||
|
||||
|
||||
Chúng ta có thể xác nhận dữ liệu của mình đã quay lại bằng cách sử dụng lệnh dưới đây để kết nối với cơ sở dữ liệu của mình.
|
||||
|
||||
```Shell
|
||||
APP_NAME=my-production-app
|
||||
kubectl run mysql-client --rm --env APP_NS=${APP_NAME} --env MYSQL_EXEC="${MYSQL_EXEC}" --env MYSQL_ROOT_PASSWORD=${MYSQL_ROOT_PASSWORD} --env MYSQL_HOST=${MYSQL_HOST} --namespace ${APP_NAME} --tty -i --restart='Never' --image docker.io/bitnami/mysql:latest --command -- bash
|
||||
```
|
||||
|
||||
Bây giờ chúng ta đang ở trong MySQL Client, chúng ta có thể thực hiện lệnh `echo "SHOW DATABASES;" | ${MYSQL_EXEC}` và chúng ta có thể thấy cơ sở dữ liệu đã quay lại. Chúng ta cũng có thể thực hiện lệnh `echo "select * from Accounts;" | ${MYSQL_EXEC}` để kiểm tra nội dung của cơ sở dữ liệu và dữ liệu quan trọng của chúng ta đã được khôi phục.
|
||||
|
||||
|
||||
|
||||
Trong bài viết tiếp theo, chúng ta sẽ xem xét Khôi phục Thảm họa trong Kubernetes.
|
||||
|
||||
## Tài liệu tham khảo
|
||||
|
||||
- [Kanister Overview - An extensible open-source framework for app-lvl data management on Kubernetes](https://www.youtube.com/watch?v=wFD42Zpbfts)
|
||||
- [Application Level Data Operations on Kubernetes](https://community.cncf.io/events/details/cncf-cncf-online-programs-presents-cncf-live-webinar-kanister-application-level-data-operations-on-kubernetes/)
|
||||
- [Kubernetes Backup and Restore made easy!](https://www.youtube.com/watch?v=01qcYSck1c4&t=217s)
|
||||
- [Kubernetes Backups, Upgrades, Migrations - with Velero](https://www.youtube.com/watch?v=zybLTQER0yY)
|
||||
- [7 Database Paradigms](https://www.youtube.com/watch?v=W2Z7fbCLSTw&t=520s)
|
||||
- [Disaster Recovery vs. Backup: What's the difference?](https://www.youtube.com/watch?v=07EHsPuKXc0)
|
||||
- [Veeam Portability & Cloud Mobility](https://www.youtube.com/watch?v=hDBlTdzE6Us&t=3s)
|
||||
|
||||
Hẹn gặp lại vào [ngày 89](day89.md)
|
||||
223
2022/vi/Days/day89.md
Normal file
223
2022/vi/Days/day89.md
Normal file
@ -0,0 +1,223 @@
|
||||
---
|
||||
title: '#90DaysOfDevOps - Khôi phục thảm họa (DR) - Ngày 89'
|
||||
published: false
|
||||
description: 90DaysOfDevOps - Khôi phục thảm họa (DR)
|
||||
tags: 'devops, 90daysofdevops, learning'
|
||||
cover_image: null
|
||||
canonical_url: null
|
||||
id: 1048718
|
||||
---
|
||||
|
||||
## Khôi phục thảm họa (DR)
|
||||
|
||||
Chúng ta đã đề cập đến các kịch bản sự cố khác nhau sẽ đòi hỏi các yêu cầu khôi phục khác nhau. Khi nói đến các kịch bản Lửa, Lũ lụt và Máu, chúng ta có thể xem đây là các tình huống thảm họa mà chúng ta cần phải có các ứng dụng của mình hoạt động ở một vị trí hoàn toàn khác càng nhanh càng tốt hoặc ít nhất với mục tiêu thời gian khôi phục gần như bằng không (RTO).
|
||||
|
||||
Điều này chỉ có thể đạt được ở quy mô lớn khi bạn tự động hóa việc sao chép toàn bộ stack ứng dụng sang một môi trường dự phòng.
|
||||
|
||||
Điều này cho phép việc chuyển đổi nhanh chóng giữa các cloud regions, nhà cung cấp cloud hoặc giữa on-premise và cloud.
|
||||
|
||||
Tiếp tục với chủ đề này, chúng ta sẽ tập trung vào việc làm sao có thể đạt được điều này bằng cách sử dụng Kasten K10 với cụm minikube mà chúng ta đã triển khai và cấu hình trong các bài viết trước.
|
||||
|
||||
Chúng ta sẽ sau đó tạo một cụm minikube khác với Kasten K10 cũng được cài đặt để đóng vai trò là cụm dự phòng của chúng ta, mà về lý thuyết có thế đặt tại bất cứ đâu.
|
||||
|
||||
Kasten K10 cũng có chức năng tích hợp để đảm bảo rằng nếu có gì đó xảy ra với cụm Kubernetes mà nó đang chạy, dữ liệu danh mục sẽ được sao chép và có sẵn trong một cụm mới [K10 Khôi phục Thảm họa](https://docs.kasten.io/latest/operating/dr.html).
|
||||
|
||||
### Thêm object storage vào K10
|
||||
|
||||
Điều đầu tiên chúng ta cần làm là thêm một object storage bucket làm target location để các bản sao lưu của chúng ta đến. Điều này không chỉ đóng vai trò như một vị trí ngoài site mà chúng ta còn có thể tận dụng nó làm nguồn dữ liệu khôi phục thảm họa.
|
||||
|
||||
Tôi đã dọn sạch bucket S3 mà chúng ta đã tạo cho bản demo Kanister trong phiên trước.
|
||||
|
||||
|
||||
|
||||
Chuyển tiếp cổng để truy cập bảng điều khiển K10, mở một terminal mới để chạy lệnh dưới đây:
|
||||
|
||||
`kubectl --namespace kasten-io port-forward service/gateway 8080:8000`
|
||||
|
||||
Bảng điều khiển Kasten sẽ khả dụng tại `http://127.0.0.1:8080/k10/#/`
|
||||
|
||||
|
||||
|
||||
Để xác thực với bảng điều khiển, chúng ta cần token mà chúng ta có thể lấy bằng các lệnh sau.
|
||||
|
||||
```Shell
|
||||
TOKEN_NAME=$(kubectl get secret --namespace kasten-io|grep k10-k10-token | cut -d " " -f 1)
|
||||
TOKEN=$(kubectl get secret --namespace kasten-io $TOKEN_NAME -o jsonpath="{.data.token}" | base64 --decode)
|
||||
|
||||
echo "Token value: "
|
||||
echo $TOKEN
|
||||
```
|
||||
|
||||
|
||||
|
||||
Bây giờ chúng ta lấy token này và nhập vào trình duyệt, sau đó bạn sẽ được yêu cầu nhập email và tên công ty.
|
||||
|
||||
|
||||
|
||||
|
||||
Sau đó, chúng ta sẽ truy cập được vào bảng điều khiển Kasten K10.
|
||||
|
||||
|
||||
|
||||
Bây giờ khi chúng ta đã quay lại bảng điều khiển Kasten K10, chúng ta có thể thêm hồ sơ vị trí của mình, chọn "Settings" ở đầu trang và "New Profile".
|
||||
|
||||
|
||||
|
||||
Bạn có thể thấy như hình dưới rằng chúng ta có nhiều lựa chọn về vị trí của hồ sơ này, chúng ta sẽ chọn Amazon S3 và thêm vào thông tin đăng nhập, region và tên bucket.
|
||||
|
||||
|
||||
|
||||
Nếu chúng ta cuộn xuống trong cửa sổ tạo New Profile, bạn sẽ thấy rằng chúng ta cũng có thể bật các bản sao lưu không thể thay đổi bằng cách sử dụng API Object Lock của S3. Trong bản demo này, chúng ta sẽ không sử dụng tính năng đó.
|
||||
|
||||
|
||||
|
||||
Nhấn "Save Profile" và bạn sẽ thấy hồ sơ vị trí vừa được tạo hoặc thêm của chúng ta như bên dưới.
|
||||
|
||||
|
||||
|
||||
### Tạo policy để bảo vệ ứng dụng Pac-Man trong object storage
|
||||
|
||||
Trong phiên trước, chúng ta chỉ tạo một bản snapshot ngẫu nhiên của ứng dụng Pac-Man, vì vậy chúng ta cần tạo một chính sách sao lưu sẽ gửi các bản sao lưu ứng dụng của chúng ta đến vị trí obeject strorage mới tạo của chúng ta.
|
||||
|
||||
Nếu bạn quay lại bảng điều khiển và chọn thẻ Chính sách, bạn sẽ thấy một màn hình như bên dưới. Chọn "Create New Policy".
|
||||
|
||||
|
||||
|
||||
Đầu tiên, chúng ta có thể đặt tên và mô tả hữu ích cho chính sách của mình. Chúng ta cũng có thể xác định tần suất sao lưu của mình cho mục đích demo, tôi đang sử dụng theo yêu cầu.
|
||||
|
||||
|
||||
|
||||
Tiếp theo, chúng ta muốn bật sao lưu qua xuất Snapshot có nghĩa là chúng ta muốn gửi dữ liệu của mình đến location profile. Nếu bạn có nhiều profile, bạn có thể chọn profile nào bạn muốn gửi các bản sao lưu của mình đến.
|
||||
|
||||
|
||||
|
||||
Tiếp theo, chúng ta chọn ứng dụng theo tên hoặc nhãn, tôi sẽ chọn theo tên và tất cả các tài nguyên.
|
||||
|
||||
|
||||
|
||||
Dưới Advanced settings, chúng ta sẽ không sử dụng bất kỳ cài đặt nào trong số này nhưng dựa trên [hướng dẫn của Kanister trong bài viết trước](day88.md), chúng ta có thể tận dụng Kanister như một phần của Kasten K10 để lấy các bản sao nhất quán của dữ liệu của chúng ta.
|
||||
|
||||
|
||||
|
||||
Cuối cùng, chọn "Create Policy" và bạn sẽ thấy chính sách trong cửa sổ Policy.
|
||||
|
||||
|
||||
|
||||
Ở cuối chính sách được tạo, bạn sẽ thấy "Show import details", chúng ta cần chuỗi này để có thể nhập vào cụm dự phòng của mình. Sao chép nó vào nơi an toàn ngay bây giờ.
|
||||
|
||||
|
||||
|
||||
Trước khi tiếp tục, chúng ta chỉ cần chọn "run once" để gửi một bản sao lưu đến object storage bucket.
|
||||
|
||||
|
||||
|
||||
Dưới đây là ảnh chụp màn hình để hiển thị bản sao lưu thành công và xuất dữ liệu của chúng ta.
|
||||
|
||||
|
||||
|
||||
### Tạo cụm MiniKube mới & triển khai K10
|
||||
|
||||
Sau đó, chúng ta cần triển khai một cụm Kubernetes thứ hai dùng bất kỳ phiên bản Kubernetes nào được hỗ trợ, bao gồm cả OpenShift, cho mục đích học tập, chúng ta sẽ sử dụng phiên bản MiniKube miễn phí với một tên khác.
|
||||
|
||||
Sử dụng `minikube start --addons volumesnapshots,csi-hostpath-driver --apiserver-port=6443 --container-runtime=containerd -p standby --kubernetes-version=1.21.2`, chúng ta có thể tạo cụm mới của mình.
|
||||
|
||||
|
||||
|
||||
Sau đó, chúng ta có thể triển khai Kasten K10 trong cụm này bằng cách sử dụng:
|
||||
|
||||
`helm install k10 kasten/k10 --namespace=kasten-io --set auth.tokenAuth.enabled=true --set injectKanisterSidecar.enabled=true --set-string injectKanisterSidecar.namespaceSelector.matchLabels.k10/injectKanisterSidecar=true --create-namespace`
|
||||
|
||||
Điều này sẽ mất một thời gian nhưng trong khi chờ đợi, chúng ta có thể sử dụng `kubectl get pods -n kasten-io -w` để theo dõi tiến trình của các pod đến khi hoàn tất.
|
||||
|
||||
Đáng lưu ý rằng vì chúng ta đang sử dụng MiniKube, ứng dụng của chúng ta sẽ chỉ chạy khi chúng ta chạy chính sách nhập của mình, storageclass của chúng ta là như nhau trên cụm dự phòng này. Tuy nhiên, một điều chúng ta sẽ đề cập trong phiên cuối là tính di động và biến đổi.
|
||||
|
||||
Khi các pod đã chạy, chúng ta có thể theo dõi các bước mà chúng ta đã thực hiện trong các bước trước đó trong cụm khác.
|
||||
|
||||
Chuyển tiếp cổng để truy cập bảng điều khiển K10, mở một terminal mới để chạy lệnh dưới đây
|
||||
|
||||
`kubectl --namespace kasten-io port-forward service/gateway 8080:8000`
|
||||
|
||||
Bảng điều khiển Kasten sẽ khả dụng tại `http://127.0.0.1:8080/k10/#/`
|
||||
|
||||
|
||||
|
||||
|
||||
Để xác thực với bảng điều khiển, chúng ta cần token mà chúng ta có thể lấy bằng các lệnh sau.
|
||||
|
||||
```Shell
|
||||
TOKEN_NAME=$(kubectl get secret --namespace kasten-io|grep k10-k10-token | cut -d " " -f 1)
|
||||
TOKEN=$(kubectl get secret --namespace kasten-io $TOKEN_NAME -o jsonpath="{.data.token}" | base64 --decode)
|
||||
|
||||
echo "Token value: "
|
||||
echo $TOKEN
|
||||
```
|
||||
|
||||
|
||||
|
||||
Bây giờ chúng ta lấy token này và nhập vào trình duyệt, sau đó bạn sẽ được yêu cầu nhập email và tên công ty.
|
||||
|
||||
|
||||
|
||||
Sau đó, chúng ta sẽ truy cập được vào bảng điều khiển Kasten K10.
|
||||
|
||||
|
||||
|
||||
### Import Pac-Man vào cụm MiniKube mới
|
||||
|
||||
Tại thời điểm này, chúng ta có thể tạo một chính sách import vào cụm dự phòng đó và kết nối với các bản sao lưu trên object storage bucket và xác định những gì và cách chúng ta muốn điều này trông như thế nào.
|
||||
|
||||
Đầu tiên, chúng ta thêm Location Profile mà chúng ta đã thực hiện trong cụm khác, dark mode ở đây để hiển thị sự khác biệt giữa hệ thống sản xuất của chúng ta và vị trí dự phòng DR của chúng ta.
|
||||
|
||||
|
||||
|
||||
Bây giờ chúng ta quay lại bảng điều khiển và vào tab policy để tạo một policy mới.
|
||||
|
||||
|
||||
|
||||
Tạo import policy như hình dưới. Khi hoàn tất, chúng ta có thể tạo một policy. Có các tùy chọn ở đây để khôi phục sau khi import và một số người có thể muốn tùy chọn này, điều này sẽ được khôi phục vào cụm dự phòng của chúng ta sau khi hoàn tất. Chúng ta cũng có thể thay đổi cấu hình của ứng dụng khi nó được khôi phục và đây là những gì tôi đã ghi lại trong [Ngày 90](day90.md).
|
||||
|
||||
|
||||
|
||||
Tôi đã chọn import theo yêu cầu, nhưng bạn có thể đặt lịch khi bạn muốn nhập này diễn ra. Vì điều này, tôi sẽ chạy một lần.
|
||||
|
||||
|
||||
|
||||
Bạn có thể thấy bên dưới import policy job thành công.
|
||||
|
||||
|
||||
|
||||
Nếu chúng ta quay lại bảng điều khiển và vào thẻ Applications, chúng ta có thể chọn thả xuống nơi bạn thấy bên dưới "Removed" bạn sẽ thấy ứng dụng của chúng ta ở đây. Chọn Restore
|
||||
|
||||
|
||||
|
||||
Tại đây, chúng ta có thể thấy các điểm khôi phục mà chúng ta có sẵn; đây là công việc sao lưu mà chúng ta đã chạy trên cụm chính đối với ứng dụng Pac-Man của chúng ta.
|
||||
|
||||
|
||||
|
||||
Tôi sẽ không thay đổi bất kỳ mặc định nào vì tôi muốn trình bày chi tiết hơn về điều này trong bài viết tiếp theo.
|
||||
|
||||
|
||||
|
||||
Khi bạn nhấn "Restore" nó sẽ yêu cầu bạn xác nhận.
|
||||
|
||||
|
||||
|
||||
Chúng ta có thể thấy bên dưới rằng chúng ta đang ở trong cụm dự phòng và nếu chúng ta kiểm tra các pod của mình, chúng ta có thể thấy rằng chúng ta đã có ứng dụng đang chạy.
|
||||
|
||||
|
||||
|
||||
Chúng ta có thể sau đó chuyển tiếp cổng (trong các môi trường thực tế / sản xuất, bạn sẽ không cần bước này để truy cập ứng dụng, bạn sẽ sử dụng ingress)
|
||||
|
||||
|
||||
|
||||
Tiếp theo, chúng ta sẽ xem xét tính di động và biến đổi của ưng dụng.
|
||||
|
||||
## Tài liệu tham khảo
|
||||
|
||||
- [Kubernetes Backup and Restore made easy!](https://www.youtube.com/watch?v=01qcYSck1c4&t=217s)
|
||||
- [Kubernetes Backups, Upgrades, Migrations - with Velero](https://www.youtube.com/watch?v=zybLTQER0yY)
|
||||
- [7 Database Paradigms](https://www.youtube.com/watch?v=W2Z7fbCLSTw&t=520s)
|
||||
- [Disaster Recovery vs. Backup: What's the difference?](https://www.youtube.com/watch?v=07EHsPuKXc0)
|
||||
- [Veeam Portability & Cloud Mobility](https://www.youtube.com/watch?v=hDBlTdzE6Us&t=3s)
|
||||
|
||||
Hẹn gặp lại vào [ngày 90](day90.md)
|
||||
127
2022/vi/Days/day90.md
Normal file
127
2022/vi/Days/day90.md
Normal file
@ -0,0 +1,127 @@
|
||||
---
|
||||
title: '#90DaysOfDevOps - Dữ liệu & ứng dụng: Tính di động - Ngày 90'
|
||||
published: false
|
||||
description: '90DaysOfDevOps - Dữ liệu & ứng dụng: Tính di động'
|
||||
tags: 'devops, 90daysofdevops, learning'
|
||||
cover_image: null
|
||||
canonical_url: null
|
||||
id: 1048748
|
||||
---
|
||||
|
||||
## Tính di động của Dữ liệu & Ứng dụng
|
||||
|
||||
Ngày 90 của Thử thách #90DaysOfDevOps! Trong bài viết cuối này, tôi sẽ trình bày về tính di động của dữ liệu và ứng dụng. Tôi sẽ tập trung cụ thể vào Kubernetes nhưng yêu cầu trên đa nền tảng ngày càng tăng và gặp nhiều trong thực tế.
|
||||
|
||||
Trường hợp là "Tôi muốn di chuyển khối lượng công việc, ứng dụng và dữ liệu của mình từ một vị trí đến vị trí khác" vì nhiều lý do khác nhau, có thể là chi phí, rủi ro hoặc để cung cấp dịch vụ tốt hơn cho doanh nghiệp.
|
||||
|
||||
Trong bài viết này, chúng ta sẽ di chuyển một workload trên Kubernetes từ một cụm đến một cụm khác, nhưng trong quá trình đó, chúng ta sẽ thay đổi cách ứng dụng hoạt động ở vị trí đích.
|
||||
|
||||
Nó sử dụng nhiều đặc điểm mà chúng ta đã thảo luận trong [Khôi phục Thảm họa](day89.md)
|
||||
|
||||
### **Yêu cầu**
|
||||
|
||||
Cụm Kubernetes hiện tại của chúng ta không thể xử lý nhu cầu và chi phí của chúng ta đang tăng vọt, dẫn đến quyết định kinh doanh rằng chúng ta muốn di chuyển cụm Kubernetes sản xuất của mình đến DR site của chúng ta, nằm trên một đám mây công cộng khác sẽ cung cấp khả năng mở rộng nhưng cũng với chi phí rẻ hơn. Chúng ta cũng có thể tận dụng một số dịch vụ cloud native có sẵn.
|
||||
|
||||
Ứng dụng quan trọng của chúng ta (Pac-Man) có một cơ sở dữ liệu (MongoDB) và đang chạy trên lưu trữ có tốc độ chậm, chúng ta muốn di chuyển đến một tier lưu trữ mới nhanh hơn.
|
||||
|
||||
Giao diện Pac-Man hiện tại (NodeJS) không có tính mở rộng tốt, và chúng ta muốn tăng số lượng pod có sẵn ở chỗ mới.
|
||||
|
||||
### Bắt đầu
|
||||
|
||||
Chúng ta đã có mô tả và thực tế là chúng ta đã có các bản import trên cụm Kubernetes Khôi phục Thảm họa (DR).
|
||||
|
||||
Công việc đầu tiên chúng ta cần làm là xóa thao tác khôi phục mà chúng ta đã thực hiện vào Ngày 89 để kiểm tra Khôi phục Thảm họa.
|
||||
|
||||
Chúng ta có thể làm điều này bằng cách sử dụng lệnh `kubectl delete ns pacman` trên cụm minikube "dự phòng".
|
||||
|
||||
|
||||
|
||||
Để bắt đầu, hãy vào Bảng điều khiển Kasten K10 và chọn thẻ Applications. Từ trình đơn thả xuống chọn "Removed"
|
||||
|
||||
|
||||
|
||||
Sau đó, chúng ta sẽ nhận được danh sách các điểm khôi phục có sẵn. Chúng ta sẽ chọn điểm có sẵn vì nó chứa dữ liệu quan trọng của chúng ta. (Trong ví dụ này, chúng ta chỉ có một điểm khôi phục.)
|
||||
|
||||
|
||||
|
||||
Khi chúng ta thực hiện quy trình Khôi phục Thảm họa, chúng ta để mọi thứ mặc định. Tuy nhiên, các tùy chọn khôi phục bổ sung này có sẵn nếu bạn có quy trình Khôi phục Thảm họa yêu cầu chuyển đổi ứng dụng của bạn. Trong trường hợp này, chúng ta có yêu cầu thay đổi lưu trữ và số lượng bản sao.
|
||||
|
||||
|
||||
|
||||
Chọn tùy chọn "Apply transforms to restored resources".
|
||||
|
||||
|
||||
|
||||
May mắn thay, hai ví dụ tích hợp sẵn cho việc chuyển đổi mà chúng ta muốn thực hiện là những gì chúng ta cần cho yêu cầu của mình.
|
||||
|
||||
|
||||
|
||||
Yêu cầu đầu tiên là trên cụm chính của chúng ta, chúng ta đang sử dụng một Storage Class gọi là `csi-hostpath-sc` và trong cụm mới của chúng ta, chúng ta muốn sử dụng `standard` vì vậy chúng ta có thể thực hiện thay đổi đó ở đây.
|
||||
|
||||
|
||||
|
||||
Trông ổn, nhấn nút tạo chuyển đổi ở dưới cùng.
|
||||
|
||||
|
||||
|
||||
Yêu cầu tiếp theo là chúng ta muốn mở rộng front-end deployment của Pac-Man lên "5"
|
||||
|
||||
|
||||
|
||||
Nếu bạn đang theo dõi, bạn sẽ thấy cả hai chuyển đổi của chúng ta như bên dưới.
|
||||
|
||||
|
||||
|
||||
Bây giờ bạn có thể thấy từ hình ảnh dưới rằng chúng ta sẽ khôi phục tất cả các hiện vật được liệt kê bên dưới, nếu chúng ta muốn, chúng ta cũng có thể chi tiết về những gì chúng ta muốn khôi phục. Nhấn nút "Restore"
|
||||
|
||||
|
||||
|
||||
Một lần nữa, chúng ta sẽ được yêu cầu xác nhận các hành động.
|
||||
|
||||
|
||||
|
||||
Điều cuối cùng cần hiển thị bây giờ là nếu chúng ta quay lại terminal và kiểm tra cụm của mình, bạn có thể thấy rằng chúng ta có 5 pod cho các pod Pacman và storageclass của chúng ta bây giờ được đặt thành standard thay vì csi-hostpath-sc
|
||||
|
||||
|
||||
|
||||
Nhiều tùy chọn khác nhau có thể đạt được thông qua chuyển đổi. Điều này không chỉ bao gồm di chuyển mà còn cả các kịch bản Khôi phục Thảm họa, thử nghiệm và phát triển và nhiều hơn nữa.
|
||||
|
||||
### API và Tự động hóa
|
||||
|
||||
Tôi chưa đề cập đến khả năng tận dụng API và tự động hóa một số tác vụ này, nhưng các tùy chọn này có sẵn và trong giao diện người dùng, có một số chỉ dẫn cung cấp các bộ lệnh để tận dụng các API cho các tác vụ tự động hóa.
|
||||
|
||||
Điều quan trọng cần lưu ý về Kasten K10 là khi triển khai, nó được triển khai bên trong cụm Kubernetes và sau đó có thể được gọi thông qua API Kubernetes.
|
||||
|
||||
Và vậy là chúng ta đãkết thúc phần về Lưu trữ và Bảo vệ dữ liệu của bạn.
|
||||
|
||||
## Tài liệu tham khảo
|
||||
|
||||
- [Kubernetes Backup and Restore made easy!](https://www.youtube.com/watch?v=01qcYSck1c4&t=217s)
|
||||
- [Kubernetes Backups, Upgrades, Migrations - with Velero](https://www.youtube.com/watch?v=zybLTQER0yY)
|
||||
- [7 Database Paradigms](https://www.youtube.com/watch?v=W2Z7fbCLSTw&t=520s)
|
||||
- [Disaster Recovery vs. Backup: What's the difference?](https://www.youtube.com/watch?v=07EHsPuKXc0)
|
||||
- [Veeam Portability & Cloud Mobility](https://www.youtube.com/watch?v=hDBlTdzE6Us&t=3s)
|
||||
|
||||
### **Kết thúc**
|
||||
|
||||
Khi tôi kết thúc loạt bài viết này, tôi muốn tiếp tục có phải hồi để đảm bảo rằng thông tin luôn được cập nhật.
|
||||
|
||||
Tôi cũng nhận ra rằng có rất nhiều chủ đề mà tôi chưa thể đề cập hoặc không thể đi sâu vào các chủ đề của DevOps.
|
||||
|
||||
Điều này có nghĩa là chúng ta luôn có thể thực hiện một nỗ lực khác vào năm sau và tìm thêm 90 ngày nội dung và hướng dẫn cùng tìm hiểu.
|
||||
|
||||
### Tiếp theo là gì?
|
||||
|
||||
Đầu tiên, tôi sẽ nghỉ ngơi một thời gian ngắn. Tôi bắt đầu thử thách này vào ngày 1 tháng 1 năm 2022 và tôi đã hoàn thành vào ngày 31 tháng 3 năm 2022 lúc 19:50 BST! Đó là một chặng đường dài. Nhưng như tôi đã nói và đã nói từ lâu, nếu nội dung này giúp được một người, thì công khai quá trình học luôn đánh làm!
|
||||
|
||||
Tôi có một số ý tưởng về việc đưa điều này ra ngoài và hy vọng, nó có một cuộc sống ngoài một GitHub repository và chúng ta có thể xem xét việc tạo một cuốn eBook và thậm chí có thể là một cuốn sách thực tế.
|
||||
|
||||
Tôi cũng biết rằng chúng ta cần xem xét lại từng bài viết và đảm bảo mọi thứ đều đúng ngữ pháp trước khi thực hiện bất kỳ điều gì như thế. Nếu ai biết cách chuyển đổi markdown sang bản in hoặc eBook, thì phản hồi của bạn sẽ rất đáng trân trọng.
|
||||
|
||||
Như mọi khi, hãy tiếp tục gửi các issues và PR.
|
||||
|
||||
Cảm ơn!
|
||||
@MichaelCade1
|
||||
|
||||
- [GitHub](https://github.com/MichaelCade)
|
||||
- [Twitter](https://twitter.com/MichaelCade1)
|
||||
@ -141,12 +141,12 @@ Cách nhanh nhất để liên lạc với tôi là thông qua Twitter tại [@M
|
||||
|
||||
### Lưu trữ & Bảo vệ Dữ liệu
|
||||
|
||||
- [✔️] 🗃️ 84 > [Bức tranh toàn cảnh: Data Management](Days/day84.md)
|
||||
- [✔️] 🗃️ 84 > [Bức tranh toàn cảnh: Quản lý dữ liệu](Days/day84.md)
|
||||
- [✔️] 🗃️ 85 > [Dịch vụ dữ liệu](Days/day85.md)
|
||||
- [✔️] 🗃️ 86 > [Sao lưu tất cả các nền tảng](Days/day86.md)
|
||||
- [✔️] 🗃️ 87 > [Thực hành với sao lưu & phục hồi](Days/day87.md)
|
||||
- [✔️] 🗃️ 88 > [Sao lưu theo hướng tập trung vào ứng dụng](Days/day88.md)
|
||||
- [✔️] 🗃️ 89 > [Khắc phục thảm họa (DR)](Days/day89.md)
|
||||
- [✔️] 🗃️ 89 > [Khôi phục thảm họa (DR)](Days/day89.md)
|
||||
- [✔️] 🗃️ 90 > [Dữ liệu & ứng dụng: Tính di động](Days/day90.md)
|
||||
|
||||
## License
|
||||
|
||||
Loading…
Reference in New Issue
Block a user