mirror of
https://github.com/MichaelCade/90DaysOfDevOps.git
synced 2025-02-03 12:55:46 +07:00
vi translation add d40-44
This commit is contained in:
Mau
parent
08dd4c7164
commit
1f3736a6bb
@ -18,11 +18,11 @@ Git không phải là hệ thống quản lý phên bản duy nhất, vì vậy
|
||||
|
||||
Lợi ích rõ ràng nhất và lớn nhất của quản lý phiên bản là khả năng theo dõi lịch sử của dự án. Chúng ta có thể xem lại kho lưu trữ (repository) bằng cách sử dụng `git log` và xem lại toàn bộ các commit cũng như comments cũng như những gì đã diễn ra trong toàn bộ dự án. Đừng lo, chúng ta sẽ đi vào cách lệnh ở phần sau. Bây giờ, hãy tưởng tượng đây là một dự án phần mềm thực tế với rất nhiều mã nguồn và có nhiều người đang làm việc chung để phát triển sản phẩn tại các thời điểm khác nhau, tất cả các kỹ sư đã đóng góp code, và tất cả những người review code đều được ghi lại ở đây để cho chúng ta biết điều gì đã xảy ra, khi nào, bởi ai và ai đã review.
|
||||
|
||||
|
||||
|
||||
|
||||
Quản lý phiên bản trước đây sẽ giống như việc tạo một bản sao phiên bản code của bạn theo cách thủ công trước khi bạn thực hiện các thay đổi. CÓ thể bạn cũng không cần sử dụng những phiên bản cũ nữa nhưng nó được tạo ra để bạn có thể yên tâm hơn, nhỡ đâu...
|
||||
|
||||
|
||||
|
||||
|
||||
Tôi đã bắt đầu áp dụng quản lý phiên bản không chỉ đối với mã nguồn mà hầu hết mọi thứ, ví dụ như dự án này (90DaysOfDevOps). Tại sao lại không sử dụng các tính năng như khôi phục, ghi lại mọi thứ đã diễn ra.
|
||||
|
||||
@ -34,11 +34,11 @@ Một lợi ích khác của quản lý phiên bản là khả năng quản lý
|
||||
|
||||
Cách chúng ta có thể làm được điều này trong quản lý phiên bản là thông qua phân nhánh (branching)
|
||||
|
||||
|
||||
|
||||
|
||||
Phân nhánh cho phép hai luồng mã cùng tồn tại cho một ứng dụng như chúng ta đã nói ở trên. Nhưng chúng ta vẫn muốn các tính năm mới có trong phiên bản miễn phí có trong phiên bản trả phí, để làm được điều này, chúng ta có một thứ gọi là merge.
|
||||
|
||||
|
||||
|
||||
|
||||
Bây giờ, điều này có vẻ dễ dàng nhưng việc merge có thể phức tạp vì bạn có thể có một nhóm làm việc trên phiên bản miễn phí và một nhóm khác làm việc với phiên bản trả phí và điều gì sẽ xảy ra nếu cả hai cùng thay đổi đến cấu trúc tổng thể của mã. CÓ thể một biến được cập nhật và làm hỏng phần nào đó. Sau đó, bạn có các conflict làm một chức năng không chạy được. Quản lý phiên bản không thể khắc phục được các conflict do bạn tạo ra. Nhưng quản lý phiên bản cho phép điều này được quản lý một cách dễ dàng.
|
||||
|
||||
@ -48,7 +48,7 @@ Nếu không có quản lý phiên bản, làm thể nào các nhóm phát tri
|
||||
|
||||
Với quản lý phiên bản, chúng ta có một nguồn sự thật duy nhất (single source of truth). Chúng ta có thể làm việc trên các module khác nhau nhưng nó cho phép chúng ta cộng tác tốt hơn.
|
||||
|
||||
|
||||
|
||||
|
||||
Một việc khác cần đề cập tới là không chỉ các nhà phát triển có thể hưởng lợi từ quản lý phiên bản, tất cả các thành viên và các công cụ có thể nhìn rõ dự án và tận dụng, các công cụ quản lý dự án có thể được liên kết và theo dõi tiến độ công việc. Chúng ta cũng có thể có một máy build, chẳng hạn như là một Jenkins server mà chúng ta sẽ nói trong phần sau. Một công cụ xây dựng mà nguồn và đóng gói hệ thống, tự động hoá quá trình kiểm thử và các metrics liên quan tới mã nguồn.
|
||||
|
||||
@ -62,59 +62,59 @@ Bây giờ chúng ta sẽ xem qua một cách tổng quát trước khi cài đ
|
||||
|
||||
Hãy sử dụng thư mục mà chúng ta đã tạo trước đó.
|
||||
|
||||
|
||||
|
||||
|
||||
Để sử dụng thư mục này với quản lý phiên bản, trước tiên chúng ta cần khởi tạo thư mục nào bằng lệnh `git init`. Hiện tại, chỉ cần nghĩ rằng lệnh này đặt thư mục của chúng ta làm kho lưu trữ trong cơ sở dữ liệu ở đâu đó trên máy tính của chúng ta.
|
||||
|
||||
|
||||
|
||||
|
||||
Bây giờ chúng ta có thể tạo một số tệp và thư mục cho mã nguồn hoặc cũng có thể đã có sẵn từ trước đó. Sử dụng lệnh `git add .` sẽ đặt tất cả cá tệp và thư mục trong thư mục của chúng ta vào một chiếc hộp nhưng chúng ta chưa commit bất cứ thứ gì vào cơ sở dữ liệu đó. Thao tác này chỉ có nghĩ là tất cả các tệp có `.` đã sẵn sàng để được thêm vào.
|
||||
|
||||
|
||||
|
||||
|
||||
Sau đó, chúng ta có thể muốn tiếp tục và commit các tệp của mình, việc này có thể thực hiện bằng lệnh `git commit -m "My First Commit"`. Chúng ta có thể đưa ra lý do cho commit của mình, điều này được khuyến khích để chúng ta có thể biết điều gì xảy ra trong mỗi commit.
|
||||
|
||||
|
||||
|
||||
|
||||
Bây giờ chúng ta có thể thấy những gì xảy ra trong lịch sử của dự án. Sử dụng lệnh `git log`
|
||||
|
||||
|
||||
|
||||
|
||||
Nếu chugns ta tạo một tệp bổ sung có tên là `samplecode.ps1`, thì trạng thái sẽ bị thay đổi. Chúng ta cũng có thể kiểm tra trạng thái của kho lưu trữ của mình bằng cách sử dụng `git status`, lệnh này cho chúng ta thấy không có gì để commit và chúng ta có thể thêm một tệp mới có thên samplecode.ps1. Sau đó, nếu chạy lại lệnh `git status` một lần nữa bạn sẽ thấy file mà chúng ta có thể commit.
|
||||
|
||||
|
||||
|
||||
|
||||
Thêm tệp mới của chúng ta bằng lệnh `git add samplecode.ps1` và sau đó chạy lại lệnh `git status` một lần nữa và thấy tệp này đã được sẵn sàng để commit.
|
||||
|
||||
|
||||
|
||||
|
||||
Sau đó dùng lệnh `git commit -m "My Second Commit"`.
|
||||
|
||||
|
||||
|
||||
|
||||
`git status` bây giờ cũng thể hiện rằng chúng ta đã dọn dẹp mọi thứ.
|
||||
|
||||
|
||||
|
||||
|
||||
Sau đó, chúng ta có thể sử dụng lệnh `git log` để hiện thị các commit mới nhất và commit đầu tiên.
|
||||
|
||||
|
||||
|
||||
|
||||
Nếu chúng ta muốn xem các thay đổi giữa các lần commit của mình, tức là những tệp nào đã được thêm hoặc sửa đổi, chúng ta có thể sử dụng `git diff b8f8 709a`
|
||||
|
||||
|
||||
|
||||
|
||||
Nó sẽ hiển thị những gì đã thay đổi, trong trường hợp của chúng ta, một tệp mới đã được thêm vào.
|
||||
|
||||
|
||||
|
||||
|
||||
Chúng ta sẽ đi sâu hơn vào vấn đề này sau nhưng chúng ta có thể nhảy giữa các commit của mình, đại loại là chúng ta có thể du hành thời gian! Bằng cách sử dụng hash của commit, có thể sử dụng lệnh `git checkout 709a` để nhảy ngược thời gian mà không làm mất tệp mới của chúng ta.
|
||||
|
||||
|
||||
|
||||
|
||||
Nhưng sau đó, chúng ta cũng sẽ muốn tiếp tục và có thể thực hiện điều này theo cách tương tự với hash của commit hoặc bạn có thể thấy như ở đây chúng ta sử dụng `git switch -` câu lệnh hoàn tác thao tác trước đó.
|
||||
|
||||
|
||||
|
||||
|
||||
TLDR:
|
||||
|
||||
|
||||
@ -24,11 +24,11 @@ Bạn cũng có thể sử dụng `winget` trên máy tính Windows của mình,
|
||||
|
||||
Trước khi chúng ta cài đặt bất cứ thứ gì, hãy kiểm tra phiên bản hiện tại trên máy của bạn. Mởi cửa sổ PowerShell và chạy `git --version`
|
||||
|
||||
|
||||
|
||||
|
||||
Chúng ta cũng có thể kiểm tra phiên bản Git trên WSL Ubuntu của mình.
|
||||
|
||||
|
||||
|
||||
|
||||
Tại thời điểm viết bài, bản phát hành mới nhất trên Windows là `2.35.1`, vì vậy tôi sẽ hướng dẫn việc update một vài thứ. Linux cũng có thể tương tự như vậy.
|
||||
|
||||
@ -38,33 +38,33 @@ Có nghĩ là quy trình bên dưới cũng là quy trình mà chúng ta phải
|
||||
|
||||
Đây là một cài đặt khá đơn giản. Sau khi tài xuống, click đúp và bắt đầu. Đọc qua thoả thuận về giấy phép GNU. Nhưng hãy nhớ đây là phần mềm mã nguồn mở và miễn phí.
|
||||
|
||||
|
||||
|
||||
|
||||
Bây giờ chúng ta có thể chọn các thành phần bổ sung mà chúng ta muốn cài đặt cũng như liên kết với git. Trên Windows, tôi luôn đảm bảo rằng mình đã cài đặt Git Bash vì điều này cho phép chúng ta chạy các lệnh bash trên Windows.
|
||||
|
||||
|
||||
|
||||
|
||||
Sau đó, chúng ta có thể chọn phần mềm SSH mà chúng ta muốn sử dụng. Tôi chọn OpenSSH như bản có thể thấy trong phần tìm hiểu về Linux.
|
||||
|
||||
|
||||
|
||||
|
||||
Chúng ta cũng có thể bật các tính năng thử nghiệm, đối với tôi, tôi không cần chúng nên đã không bật chúng, bạn luôn có thể quay lại việc cài đặt để bật các tính năng này.
|
||||
|
||||
|
||||
|
||||
|
||||
Cài đặt hoàn tất, bây giờ chúng ta có thể chọn mở Git Bash hoặc đọc bản ghi chú cho bản phát hành mới nhất.
|
||||
|
||||
|
||||
|
||||
|
||||
Bước kiểm tra cuối cùng là mở PowerShell và thử lại câu lệnh kiểm tra phiên bản git.
|
||||
|
||||
|
||||
|
||||
|
||||
Sau các bước siêu đơn giản ở trên, chúng ta sẽ có phiên bản mới nhất của git. Đối với Linux, quá trình có thể sẽ mất thời gian hơn một chúng nhưng tôi cũng muốn nói qua về nó.
|
||||
|
||||
Tôi chỉ cần chạy lệnh `sudo apt-get install git`.
|
||||
|
||||
|
||||
|
||||
|
||||
Bạn cũng có thể chạy các câu lệnh dưới dây để add thêm git repository cho các cài đặt phần mềm.
|
||||
|
||||
@ -101,11 +101,11 @@ bây giờ, nếu chúng ta muốn kiểm tra tất cả các cầu hình git th
|
||||
|
||||
`git config --global -e`
|
||||
|
||||
|
||||
|
||||
|
||||
Trên tất cả các máy, tệp này sẽ được đặt tên là `.gitconfig`. Trên máy Windows của tôi, bạn sẽ tìm thấy tệp này trong thư mục người dùng của mình.
|
||||
|
||||
|
||||
|
||||
|
||||
### Lý thuyết Git
|
||||
|
||||
@ -117,15 +117,15 @@ Trước khi git xuất hiện, Client-Server là phương thức chính để q
|
||||
|
||||
Trong mô hình quản lý phiên bản Client-Server này, bước đầu tiên nhà phát triểu cần làm là tải xuống mã nguồn và các tệp từ máy chủ. Điều này không giải quyết các xung đột nhưng nó loại bỏ sự phức tạp của các xung đột và cách giải quyết chúng.
|
||||
|
||||
|
||||
|
||||
|
||||
Bây giờ, giả sử chúng ta có hai nhà phát triển làm việc trên cùng một tệp và một người xong trước, upload file của họ lên server trước với những thay đổi của họ. Khi người thứ hai cập nhật file đó, xung đột sẽ xảy ra.
|
||||
|
||||
|
||||
|
||||
|
||||
Vì vậy, bây giờ người thứ hai cần kéo thay đổi mã của người đầu tiên xuống và giải quyết các xung đột trong mã nguồn rồi sau đó mới commit lên máy chủ.
|
||||
|
||||
|
||||
|
||||
|
||||
### Distributed Version Control
|
||||
|
||||
@ -140,7 +140,7 @@ Một số lợi ích chính của Git là:
|
||||
|
||||
Khác với mô hình kiểm soát phiên bản Client-Server, mỗi nhà phát triển tải xuống một repository thì nó sẽ bao gồm tất cả mọi thứ. Lịch sử các commit, tất cả các nhánh,...
|
||||
|
||||
|
||||
|
||||
|
||||
## Tài liệu tham khảo
|
||||
|
||||
|
||||
@ -22,15 +22,15 @@ Google hoặc bất kỳ công cụ tìm kiểm nào có thể là điểm đế
|
||||
|
||||
Tiếp sau đó có thể là trang chính thức của git và tài liệu. [git-scm.com/docs](http://git-scm.com/docs) Tại đây, bạn sẽ không những chỉ tìm thấy tài liệu tham khảo tốt cho tất cả các câu lệnh, mà còn có rất nhiều các tài nguyên khác.
|
||||
|
||||
|
||||
|
||||
|
||||
Chúng ta cũng có thể truy cập tài liệu tương tự sau, điều này cực kỳ hữu ích nếu bạn không có kết nối nào từ terminal. Ví dụ: nếu chúng ta sử dụng lệnh `git add`, chúng ta có thể chạy `git add --help` và đọc hướng dẫn dưới đây.
|
||||
|
||||
|
||||
|
||||
|
||||
Chúng ta cũng có thể dụng `git add -h` để cung cấp tống hợp các tuỳ chọn có sẵn mà chúng ta có thể sử dụng.
|
||||
|
||||
|
||||
|
||||
|
||||
### Những câu chuyện xung quanh Git
|
||||
|
||||
@ -156,7 +156,7 @@ Tôi đã lấy những câu lệnh từ [atlassian](https://www.atlassian.com/g
|
||||
| git push <remote> --all | `git push <remote> --all` | Đẩy tất cả các nhánh ở local đến một remote xác định. |
|
||||
| git push <remote> --tags | `git push <remote> --tags` | Tage không được tự động đẩy lên khi bạn đẩy một nhánh hay sử dụng --all. --tags sẽ gửi tất cả những local tags lên remote repo. |
|
||||
|
||||
## Resources
|
||||
## Tài liệu tham khảo
|
||||
|
||||
- [What is Version Control?](https://www.youtube.com/watch?v=Yc8sCSeMhi4)
|
||||
- [Types of Version Control System](https://www.youtube.com/watch?v=kr62e_n6QuQ)
|
||||
|
||||
@ -14,11 +14,11 @@ Chúng ta đã đề cập đến một số điều cơ bản nhưng việc đ
|
||||
|
||||
Chúng ta sẽ lấy thư mục dự án mà chúng ta đã tạo ở bài dầu tiên về git và đi qua lần lượt các bước với git. Chúng ta tạo một thư mục trên máy của mình và khởi tạo git với lệnh `git init`.
|
||||
|
||||
|
||||
|
||||
|
||||
Chúng ta cũng có thể thấy rằng thư mục đã được khởi tạo có một thư mục ẩn.
|
||||
|
||||
|
||||
|
||||
|
||||
Đây là nơi lưu trữ thông tin chi tết về git repository cũng như thông tin liên quan đến các nhánh và commit của chúng ta.
|
||||
|
||||
@ -26,15 +26,15 @@ Chúng ta cũng có thể thấy rằng thư mục đã được khởi tạo c
|
||||
|
||||
Chúng ta bắt đầu làm việc với thư mục rỗng hoặc có thể chúng ta có một số mã nguồn vào những ngày làm việc trước đó. Đầu tiên, chúng ta tạo tệp readme.md và có thể thấy tệp đó trong thư mục, tiếp theo chúng ta kiểm tra với `git status` và git đã biết về tệp readme.md nhưng chúng ta chưa commit tệp đó.
|
||||
|
||||
|
||||
|
||||
|
||||
Chúng ta có thể stage tệp readme.md với lệnh `git add README.md` và có thể thấy thay đổi có thể được commit mà trước đó cũng ta không có và một tệp mới màu xanh lá cây.
|
||||
|
||||
|
||||
|
||||
|
||||
Tiếp theo chúng ta sẽ commit tệp này với commit đầu tiên của chúng ta. Chúng ta có thể làm điều này với lệnh `git commit -m "Meaningful message"` để có thể dễ dàng hiểu rằng mỗi commit đã thay đổi điều gì. Ngoài ra, hãy chú ý rằng chữ thập màu vàng bây giờ đã thay đổi thành dấu tính màu xanh lá cây. Đây là thứ tôi có trong terminal của mình với theme mà tôi sử dụng, thứ mà chúng ta đã đề cập trong phần nói về Linux.
|
||||
|
||||
|
||||
|
||||
|
||||
### Commit các thay đổi
|
||||
|
||||
@ -44,11 +44,11 @@ Chúng ta có thể lặp lại các quy trình của mình như trước đó,
|
||||
|
||||
Nếu chúng ta chạy `git commit` sau khi chạy `git add`, git sẽ mở trình soạn thảo văn bản mặc định của chúng ta, trong trường hợp của tôi là nano. Dưới đây là các bước tôi đã thực hiện để thêm một số thay đổi vào tệp, chạy `git status` để thấy những thứ đã được staged và chưa được staged. Sau đó, tôi đã sử dụng `git add` để thêm tệp vào khu vực staging, cuối cùng là lệnh `git commit` để mở nano.
|
||||
|
||||
|
||||
|
||||
|
||||
Khi nano mở ra, bạn có thể thêm mô tả ngắn hoặc dài của mình rồi lưu lại tệp.
|
||||
|
||||
|
||||
|
||||
|
||||
### Best Practices khi Commit
|
||||
|
||||
@ -64,7 +64,7 @@ Có phải chúng ta luôn phải stage các thay đổi của mình trước kh
|
||||
|
||||
Câu trả lời là có nhưng đừng coi đây là một lối tắt, bạn phải chắc chắn 100% rằng bạn không cần một snapshot để quay lại, đó là một việc làm mạo hiểm.
|
||||
|
||||
|
||||
|
||||
|
||||
### Xoá tệp
|
||||
|
||||
@ -72,21 +72,21 @@ Còn việc xoá tệp khỏi dự án của chúng tôi thì sao, có thể ch
|
||||
|
||||
Chỉ vì chúng ta xoá tệp đó khỏi thư mục, git vẫn biết tệp này và chúng ta cũng cần xoá tệp khỏi repository. Bạn có thể thấy workflow như bên dưới.
|
||||
|
||||
|
||||
|
||||
|
||||
Nó có thể hơi khó nhớ hoặc khó thực hiện nếu bạn có một dự án lớn với nhiều tệp và thư mục cần xoá. Chúng ta có thể làm điều này với một lệnh duy nhất `git rm oldcode.ps1`.
|
||||
|
||||
|
||||
|
||||
|
||||
### Đổi tên hoặc Di chuyển tệp
|
||||
|
||||
Trong hệ điều hành của chúng ta, chúng ta có thể đổi tên và di chuyển các tệp của mình. Chúng ta chắc chắn sẽ cần phải làm điều này rất nhiều lần trong dự án của chúng ta. Tương tự như xoá, quy trình sẽ gồn 2 bước, chúng ta thay đổi các tệp trên hệ điều hành của mình, sau đó sửa đổi và đảm bảo rằng khu vực staging hoặc các tệp được thêm vào một các chính xác. Các bước như sau:
|
||||
|
||||
|
||||
|
||||
|
||||
Tuy nhiên, giống như xoá các tệp khỏi hệ điều hành và sau đó là git repository, chúng ta có thể thực hiện việc đổi tên này bằng cách sử dụng lệnh git.
|
||||
|
||||
|
||||
|
||||
|
||||
### Bỏ qua tệp (ignore files)
|
||||
|
||||
@ -94,15 +94,15 @@ Chugns ta có thể có yêu cầu bỏ qua các tệp hoặc thư mục trong d
|
||||
|
||||
Chúng ta có thể bỏ qua các tệp bằng cách thêm các thư mục hoặc tệp vào tệp `.gitignore` trong thư mục dự án của chúng ta.
|
||||
|
||||
|
||||
|
||||
|
||||
Bạn có thể mở tệp `.gitignore` và thấy rằng chúng ta có thư mục log/. Nhưng chúng ta vẫn có thể thêm các tệp và thư mục tại đây để chúng được bỏ qua.
|
||||
|
||||
|
||||
|
||||
|
||||
Sau đó chúng ta có thể kiểm tra `git status` và xem điều gì đã xảy ra.
|
||||
|
||||
|
||||
|
||||
|
||||
Cũng có những ách mà bạn có thể cần quay lại và bỏ qua các tệp và thư mục, có thể bạn muốn chia sẻ thư mục logs nhưng sau đó nhận ra bạn không muốn. Bạn sẽ phải dùng lệnh `git rm --cached ` để xoá tệp và thư mục khỏi khu vực staging nếu bạn có một thư mục đã theo dõi trước đó mà bây giờ bạn muốn bỏ qua.
|
||||
|
||||
@ -110,7 +110,7 @@ Cũng có những ách mà bạn có thể cần quay lại và bỏ qua các t
|
||||
|
||||
Chúng ta đã sử dụng `git status` rất nhiều để hiểu những gì chúng ta có trong khu vực staging của mình và những gì chúng ta không có, đây là một lệnh rất toàn diện với nhiều thông tin chi tiết. Dần dần, hầu hết những gì bạn muốn biết là cái gì đã được sửa đổi hoặc có gì mới. Chúng ta có thể sử dụng `git status -s` cho một bản tóm tắt ngắn của các chi tiết này. Tôi thường đặt một phím tắt trên hệ thống của mình để chỉ sử dụng `git status -s` so với lệnh chi tiết đầy đủ
|
||||
|
||||
|
||||
|
||||
|
||||
Trong bài đăng ngài mai, chúng ta sẽ tiếp tục xem qua các ví dụ ngắn về các lệnh git phổ biến.
|
||||
|
||||
|
||||
@ -16,21 +16,21 @@ Tiếp tục với ngày hôm qua sau khi đã thực hành một số lệnh c
|
||||
|
||||
Bạn nên xem các đoạn mã đã đước staged và chưa được staged trước khi commit. Chúng ta có thể làm điều này với lệnh `git diff --staged`
|
||||
|
||||
|
||||
|
||||
|
||||
Điều này sau đó cho chúng ta thấyt tất cả những thay đổi chúng ta đã thực hiện và tất cả các tệp mới mà chúng ta đã thêm hoặc xoá.
|
||||
|
||||
Các thay đổi trong các tệp được biểu thị bằng `---` hoặc `+++` bạn có thể thấy như dưới dây, chúng ta vừa thêm dòng mới "+add some text".
|
||||
|
||||
|
||||
|
||||
|
||||
Chúng ta cũng có thể chạy `git diff` để so sánh khu vực staging với thư mục làm việc của chúng ta. Nếu như thực hiện một số thay đổi với tệp code.txt mới được thêm vào và thêm một số dòng.
|
||||
|
||||
|
||||
|
||||
|
||||
Nếu sau đó chúng ta chạy lệnh `git diff`, chúng ta sẽ so sánh và có kết quả như dưới đây.
|
||||
|
||||
|
||||
|
||||
|
||||
### Công cụ Diff trực quan
|
||||
|
||||
@ -45,29 +45,29 @@ Nếu sau đó chúng ta chạy lệnh `git diff`, chúng ta sẽ so sánh và c
|
||||
|
||||
Chúng ta sẽ chạy phần trên và sẽ đặt một số tham số khi khởi chạy VScode.
|
||||
|
||||
|
||||
|
||||
|
||||
Chúng ta cũng có thể kiểm tra cấu hình của mình với `git config --global -e`
|
||||
|
||||
|
||||
|
||||
|
||||
Sau đó, chúng ta có thể sử dụng `git difftool` để mở công cụ trực quan.
|
||||
|
||||
|
||||
|
||||
|
||||
Sau đó, mở trang diff trên VSCode và so sánh 2 trang, chúng ta chỉ sửa đổi một tệp từ không có gì thành thêm một dòng mã như ở màn hình bên phải.
|
||||
|
||||
|
||||
|
||||
|
||||
Tôi thấy phương pháp này dễ dàng hơn nhiều để theo dõi các thay đổi và đây là phương pháp tương tự như những gì chúng ta sẽ thấy khi sử dụng các dịch vụ dựa trên git như GitHub.
|
||||
|
||||
Chúng ta cũng có thể sử dụng `git difftool --staged` để so sánh stage với các tệp đã được commit.
|
||||
|
||||
|
||||
|
||||
|
||||
Sau đó, chúng ta có thể duyệt qua các tệp đã thay đổi của mình trước khi commit.
|
||||
|
||||
|
||||
|
||||
|
||||
Tôi đang sử dụng VSCode làm IDE của mình và giống như hầu hết các IDE khác, chúng có chức năng này được tích hợp sẵn, rất hiếm khi bạn cần chạy các lệnh này từ terminal, mặc dù nó rất hữu ích nếu bạn không có sẵn IDE bởi một lý do nào đó.
|
||||
|
||||
@ -75,17 +75,17 @@ Tôi đang sử dụng VSCode làm IDE của mình và giống như hầu hết
|
||||
|
||||
Trước đây chúng ta đã đề cập đến `git log` sẽ cung cấp một cái nhìn toàn diện về tất cả các commit mà chúng ta đã thực hiện trong kho lưu trữ của mình.
|
||||
|
||||
|
||||
|
||||
|
||||
Mỗi commit có chuỗi thập lục phân, duy nhất cho kho lưu trữ. Tại đây, bạn có thể xem chúng ta đang làm việc trên nhánh nào và sau đó là tác giả, ngày tháng và nội dung commit.
|
||||
|
||||
Chúng ta cũng có `git log --oneline` và điều này mang lại một phiên bản ngắn gọn hơn nhiều của chuỗi thập lục phân mà chúng ta có thể sử dụng trong các lệnh `diff`. Chúng ta cũng chỉ có một dòng mô tả cho các commit.
|
||||
|
||||
|
||||
|
||||
|
||||
Chúng ta có thể đảo ngược điều này và bắt đầu với commit hận đầu tiên bằng cách chạy `git log --oneline --reverse`, chúng ta thấy commit đầu tiên của mình ở đầu trang.
|
||||
|
||||
|
||||
|
||||
|
||||
### Xem một commit
|
||||
|
||||
@ -93,35 +93,35 @@ Việc có thể xem nội dung commit là một điều tuyệt vời nếu b
|
||||
|
||||
Chúng ta có thể sử dụng `git log --oneline --reverse` để lấy danh sách các commit của mình rồi lấy chúng và chạy `git show <commit ID>`
|
||||
|
||||
|
||||
|
||||
|
||||
Đầu ra của lệnh đó sẽ giống như bên dưới với chi tiết về commit, tác giả và những gì đã thay đổi.
|
||||
|
||||
|
||||
|
||||
|
||||
Chúng ta cũng có thể sử dụng `git show HEAD~1` trong đó 1 là số bước quay lại từ phiên bản hiện tại.
|
||||
|
||||
Điều này rất hữu ích nếu bạn muốn biết một số chi tiết về tệp của mình, nhưng nếu chúng ta muốn liệt kê tất cả các tệp trong một cây cho toàn bộ snapshot của thư mục. Chúng ta có thể sử dụng lệnh `git ls-tree HEAD~1`, một lần nữa quay lại một snapshot từ commit cuối cùng. Chúng ta có thể thấy có hai blobs, những blobs này biểu thị các tệp trong khi cây biểu thị một thư mục. Bạn cũng có thể thấy các commit và tags.
|
||||
|
||||
|
||||
|
||||
|
||||
Sau đó, chúng ta có thể sử dụng phần trên để đi sâu vào và xem nội dung của tệp (blobs) bằng cách sử dụng lệnh `git show`.
|
||||
|
||||
|
||||
|
||||
|
||||
Sau đó, nội dung của phiên bản cụ thể của tệp sẽ được hiển thị.
|
||||
|
||||
|
||||
|
||||
|
||||
### Unstage tệp
|
||||
|
||||
Sẽ có lúc bạn có thể đã sử dụng `git add .` nhưng có những tệp bạn chưa muốn commit với snapshot đó. Trong ví dụ dưới đây, tôi đã thêm newfile.txt vào khu vực staging của mình nhưng tôi chưa sẵn sàng commit tệp này nên tôi sẽ sử dụng `git restore --staged newfile.txt` để hoàn tác bước `git add`.
|
||||
|
||||
|
||||
|
||||
|
||||
Chúng ta cũng có thể thực hiện tương tự với các tệp đã sửa đổi, chẳng hạn như main.js và hủy thực hiện commit, như ở trên chúng tôi có chữ M màu xanh lá cây để sửa đổi và sau đó bên dưới chúng ta sẽ hủy thực hiện những thay đổi đó.
|
||||
|
||||
|
||||
|
||||
|
||||
Tôi nhận thấy lệnh này khá hữu ích với 90DaysOfDevOps vì đôi khi tôi chuẩn bị cho nhiều ngày trước và cảm thấy muốn ghi chú lại nhưng tôi không muốn commit và đẩy lên kho lưu trữ GitHub công khai.
|
||||
|
||||
@ -129,15 +129,15 @@ Tôi nhận thấy lệnh này khá hữu ích với 90DaysOfDevOps vì đôi kh
|
||||
|
||||
Đôi khi chúng ta có thể thực hiện các thay đổi nhưng chúng ta không hài lòng với những thay đổi đó và muốn loại bỏ chúng. Chúng ta sẽ sử dụng lại lệnh `git restore` và chúng ta sẽ có thể khôi phục các tệp từ snapshot hoặc các phiên bản trước đó. Chúng ta có thể chạy `git restore .` đối với thư mục của mình và nó sẽ khôi phục mọi thứ từ snapshot của mình, lưu ý rằng tệp chưa được theo dõi của chúng ta vẫn còn. Không có tệp có tên là newfile.txt được theo dõi trước đó.
|
||||
|
||||
|
||||
|
||||
|
||||
Bây giờ để xóa newfile.txt hoặc bất kỳ tệp nào chưa được theo dõi. Chúng ta có thể sử dụng `git clean`.
|
||||
|
||||
|
||||
|
||||
|
||||
Hoặc nếu chugns ta biết hậu quả, có thể muốn chạy `git clean -fd` để buộc và xóa tất cả các thư mục.
|
||||
|
||||
|
||||
|
||||
|
||||
### Khôi phục tệp về một phiên bản cũ
|
||||
|
||||
@ -145,17 +145,17 @@ Như chúng ta đã đề cập trong suốt phần lớn những gì Git có th
|
||||
|
||||
Ví dụ: hãy xóa tệp quan trọng nhất trong thư mục của chúng ta, lưu ý rằng chúng ta đang sử dụng các lệnh dựa trên Unix để xóa tệp này khỏi thư mục, không phải lệnh git.
|
||||
|
||||
|
||||
|
||||
|
||||
Bây giờ, không còn readme.md trong thư mục làm việc của chúng tôi. Chúng ta có thể đã sử dụng `git rm readme.md` và nó sẽ được phản ánh trong cơ sở dữ liệu git. Chúng ta cũng hãy xóa nó khỏi đây để mô phỏng việc nó bị xóa hoàn toàn.
|
||||
|
||||
|
||||
|
||||
|
||||
Let's now commit this with a message and prove that we no longer have anything in our working directory or staging area.
|
||||
|
||||
Bây giờ chúng ta hãy commit điều này và chứng minh rằng chúng ta không còn bất kỳ thứ gì trong thư mục làm việc hoặc khu vực tổ chức của mình.
|
||||
|
||||
|
||||
|
||||
|
||||
Chúng ta đã sai lầm và giờ cần tệp đó trở lại!
|
||||
|
||||
@ -163,7 +163,7 @@ Chúng ta có thể sử dụng lệnh `git undo` để hoàn tác commit cuối
|
||||
|
||||
Bạn có thể thấy bằng cách sử dụng quy trình này, giờ đây chúng ta có tệp trở lại trong thư mục làm việc.
|
||||
|
||||
|
||||
|
||||
|
||||
We now have a new untracked file and we can use our commands previously mentioned to track, stage and commit our files and changes.
|
||||
Bây giờ chúng ta có một tệp chưa được theo dõi mới và có thể sử dụng các lệnh đã đề cập trước đó để theo dõi, stage và commit các tệp và thay đổi của chúng ta.
|
||||
@ -176,11 +176,11 @@ Bây giờ chúng ta có một tệp chưa được theo dõi mới và có th
|
||||
|
||||
Hãy bắt đầu với một tính năng mới trong một nhánh mới. Nhánh chính tiếp tục với các commit mới.
|
||||
|
||||
|
||||
|
||||
|
||||
Lựa chọn dễ dàng ở đây là sử dụng `git merge feature main` sẽ hợp nhất nhánh main vào nhánh feature.
|
||||
|
||||
|
||||
|
||||
|
||||
Merge rất dễ dàng vì nó không có tính phá hủy. Các nhánh hiện tại không bị thay đổi theo bất kỳ cách nào. Tuy nhiên, điều này cũng có nghĩa là nhánh tính năng sẽ có một merge commit không liên quan mỗi khi bạn cần kết hợp các thay đổi với upstream. Nếu main được commit liên tục và nhiều, điều này sẽ hoặc có thể làm bẩn lịch sử commit của nhánh feature.
|
||||
|
||||
@ -192,7 +192,7 @@ git rebase main
|
||||
|
||||
Điều này chuyển nhánh feature (toàn bộ nhánh feature) kết hợp hiện quả với tất cả các commit mới trong nhánh main. Tuy nhiên, thay vì sử dụng một merge commit, việc rebase sẽ viết lại lịch sử commit bằng cách tạo các commit hoàn toàn mới cho mỗi commit trong nhánh ban đầu.
|
||||
|
||||
|
||||
|
||||
|
||||
Lợi ích lớn nhất của việc rebase là lịch sử dự án rõ ràng hơn nhiều. Nó cũng loại bỏ các merge commit không cần thiết. Và khi bạn so sánh hai hình ảnh cuối cùng, bạn có thể theo dõi lịch sử dự án tuyến tính rõ ràng hơn nhiều.
|
||||
|
||||
|
||||
215
2022/vi/Days/day40.md
Normal file
215
2022/vi/Days/day40.md
Normal file
@ -0,0 +1,215 @@
|
||||
---
|
||||
title: '#90DaysOfDevOps - Mạng xã hội dành cho code - Ngày 40'
|
||||
published: false
|
||||
description: 90DaysOfDevOps - Mạng xã hội dành cho code
|
||||
tags: 'devops, 90daysofdevops, learning'
|
||||
cover_image: null
|
||||
canonical_url: null
|
||||
id: 1049044
|
||||
---
|
||||
|
||||
## Mạng xã hội dành cho code
|
||||
|
||||
Khám phá GitHub | GitLab | BitBucket
|
||||
|
||||
Hôm nay tôi muốn đề cập đến một số dịch vụ dựa trên git mà có lẽ tất cả chúng ta đều đã nghe nói đến và mong rằng chúng ta cũng sử dụng hàng ngày.
|
||||
|
||||
Sau đó, chúng ta sẽ sử dụng một số kiến thức trong buổi trước của mình để di chuyển các bản sao dữ liệu của chúng ta sang từng dịch vụ chính.
|
||||
|
||||
Tôi gọi phần này là "Mạng xã hội cho mã" hãy để tôi giải thích tại sao?
|
||||
|
||||
### GitHub
|
||||
|
||||
Phổ biến nhất ít nhất đối với tôi là GitHub, GitHub là dịch vụ lưu trữ dựa trên web dành cho git. Nó được các nhà phát triển phần mềm sử dụng nhiều nhất để lưu trữ mã của họ. Quản lý mã nguồn với các tính năng quản lý phiên bản git và rất nhiều tính năng bổ sung. Nó cho phép các nhóm hoặc cộng tác viên dễ dàng giao tiếp và xã hội hoá việc viết mã. (do đó có tiêu đề là mạng xã hội) Kể từ năm 2018, GitHub là một phần của Microsoft.
|
||||
|
||||
GitHub đã xuất hiện khá lâu và được thành lập vào năm 2007/2008. Với hơn 40 triệu người dùng trên nền tảng ngày nay.
|
||||
|
||||
Các tính năng chính của GitHub
|
||||
|
||||
- Code Repository
|
||||
- Pull Requests
|
||||
- Công cụ quản lý dự án - Issues
|
||||
- CI / CD Pipeline - GitHub Actions
|
||||
|
||||
Về giá cả, GitHub có các mức giá khác nhau cho người dùng. Bạn có thể tìm thêm thông tin về [Pricing](https://github.com/pricing)
|
||||
|
||||
Lần này, chúng ta sẽ tìm hiểu với cấp miễn phí.
|
||||
|
||||
Tôi sẽ sử dụng tài khoản GitHub đã tạo của mình trong hướng dẫn này, nếu bạn chưa có tài khoản thì trên trang GitHub mở sẽ có tùy chọn đăng ký và các bước dễ dàng để cấu hình.
|
||||
|
||||
### Trang đầu tiên của Github
|
||||
|
||||
Khi bạn đăng nhập lần đầu vào tài khoản GitHub của mình, bạn sẽ nhận được một trang chứa rất nhiều tiện ích cung cấp cho bạn các tùy chọn về địa điểm và nội dung bạn muốn xem hoặc làm. Đầu tiên, chúng ta có mục "All Activity", điều này sẽ cung cấp cho bạn cái nhìn về những gì đang xảy ra với kho lưu trữ hoặc hoạt động được liên kết với tổ chức hoặc tài khoản của bạn.
|
||||
|
||||
|
||||
|
||||
Tiếp theo, chúng ta có Kho lưu trữ mã, kho lưu trữ của riêng chúng ta hoặc kho lưu trữ mà chúng ta đã tương tác gần đây. Chúng ta cũng có thể nhanh chóng tạo các kho mới hoặc tìm kiếm các kho mã.
|
||||
|
||||
|
||||
|
||||
Sau đó, chúng ta có hoạt động gần đây của chúng ta, những điều này đối với tôi là issues và pull requests mà tôi đã tạo hoặc đóng góp gần đây.
|
||||
|
||||
|
||||
|
||||
Ở phía bên phải của trang, chúng ta có một số giới thiệu về các kho mã mà chúng ta có thể quan tâm, rất có thể dựa trên hoạt động gần đây của bạn hoặc các dự án của riêng bạn.
|
||||
|
||||
|
||||
|
||||
Thành thật mà nói, tôi rất hiếm khi vào trang chủ của mình, mặc dù bây giờ tôi thấy rằng việc xem qua nó có thể thực sự hữu ích để giúp tương tác với cộng đồng tốt hơn một chút trong một số dự án nhất định.
|
||||
|
||||
Tiếp theo, nếu chúng ta muốn truy cập Hồ sơ GitHub của mình, chúng ta có thể điều hướng đến góc trên cùng bên phải và trên hình ảnh của bạn, có một drop-down cho phép bạn qua tài khoản của mình. Từ đây để truy cập Hồ sơ của bạn, chọn "Your Profile"
|
||||
|
||||
|
||||
|
||||
Tiếp theo, trang hồ sơ của bạn sẽ xuất hiện theo mặc định, trừ khi bạn thay đổi cấu hình của mình, bạn sẽ không thấy những gì tôi có, tôi đã thêm một số chức năng hiển thị các bài đăng blog gần đây của tôi trên [vZilla](https://vzilla.co.uk) và sau đó là các video mới nhất của tôi trên Kênh [YouTube](https://m.youtube.com/c/MichaelCade1) của mình.
|
||||
|
||||
Bạn sẽ không mất nhiều thời gian để xem hồ sơ của mình, nhưng đây là một nơi rất tốt để chia sẻ với mạng lưới của bạn để họ có thể thấy các dự án thú vị mà bạn đang thực hiện.
|
||||
|
||||
|
||||
|
||||
Sau đó, chúng ta có thể đi sâu vào khối xây dựng của GitHub, các kho lưu trữ. Ở đây bạn sẽ thấy các kho lưu trữ của mình và nếu bạn có các kho lưu trữ private thì chúng cũng sẽ được hiển thị trong danh sách dài này.
|
||||
|
||||
|
||||
|
||||
Vì kho lưu trữ rất quan trọng đối với GitHub, hãy để tôi chọn một kho lưu trữ khá hot trong thời gian gần đây và thực hiện một số chức năng chính có thể sử dụng ở đây khi tôi chỉnh sửa "mã" của chúng ta bằng git trên thống cục bộ của tôi.
|
||||
|
||||
Trước hết, từ cửa sổ trước, tôi đã chọn kho lưu trữ 90DaysOfDevOps và chúng ta có thể thấy mành hình này. Bạn có thể thấy từ đây, chúng ta có rất nhiều thông tin, có cấu trúc mã chính ở giữa hiển thị các tệp và thư mục được lưu trữ trong kho lưu trữ, có readme.md hiển thị ở dưới cùng. Ở bên phải của trang, chúng ta có phần giới thiệu, có mô tả và mục đích của kho lưu trữ. Sau đó, chúng ta có rất nhiều thông tin bên dưới điều này cho thấy có bao nhiêu người đã thả sao cho dự án, số lần được fork và số người theo dõi.
|
||||
|
||||
|
||||
|
||||
Nếu cuộn xuống thêm một chút, bạn cũng sẽ thấy rằng chúng ta có Released, đó là từ phần golang trong thử thách này. Chúng ta không có bất kỳ gói nào trong dự án của mình, và có người đóng góp được liệt kê ở đây. (Cảm ơn cộng đồng đã hỗ trợ tôi kiểm tra chính tả và tính xác thực của thông tin). Sau đó, chúng ta có các ngôn ngữ, đây là những ngôn ngữ được sử dụng trong thử thách.
|
||||
|
||||
|
||||
|
||||
Ở đầu trang, bạn sẽ thấy một danh sách các tab. Chúng có thể khác nhau và chúng có thể được tuỳ biến để chỉ hiển thị những thứ bạn yêu cầu. Bạn sẽ thấy ở đây tôi không sử dụng tất cả những thứ này và nên loại bỏ chúng để đảm bảo toàn bộ kho lưu trữ gọn gàng.
|
||||
|
||||
Đầu tiên, chúng ta có tab code mà chúng ta vừa thảo luận nhưng các tab này sẽ giúp điều hướng qua trong kho lưu trữ, điều này cực kỳ hữu ích để chúng ta có thể chuyển đổi giữa các phần một cách nhanh chóng và dễ dàng. Tiếp theo, chúng tôi có tab Issues.
|
||||
|
||||
Issues cho phép bạn theo dõi công việc của mình trên GitHub, nơi quá trình phát triển diễn ra. Trong kho lưu trữ cụ thể này, bạn có thể thấy tôi có một số issue tập trung vào việc thêm sơ đồ hoặc lỗi chính tả nhưng chúng ta cũng có yêu cầu có phiên bản tiếng Trung cho kho lưu trữ.
|
||||
|
||||
Nếu đây là một kho lưu trữ mã thì đây là nơi tuyệt vời để nêu lên các vấn đề với những người bảo trì, nhưng hãy nhớ chú ý và cụ thể về những gì bạn đang báo cáo và cung cấp càng nhiều thông tin càng tốt.
|
||||
|
||||
|
||||
|
||||
Tab tiếp theo là Pull Requests, Pull Requests cho phép bạn thông báo cho người khác về những thay đổi mà bạn đã đẩy tới một nhánh trong kho lưu trữ. Đây là nơi ai đó có thể đã phân nhánh kho lưu trữ của bạn, thực hiện các thay đổi như sửa lỗi hoặc cải tiến tính năng hoặc chỉ lỗi đánh máy.
|
||||
|
||||
Chúng tôi sẽ đề cập đến fork sau.
|
||||
|
||||
|
||||
|
||||
Tôi tin rằng tab tiếp theo khá mới? Tab Discussion (Thảo luận). Nhưng tôi nghĩ đối với một dự án như #90DaysOfDevOps, điều này có thể giúp hướng dẫn cho các nội dung mới nhưng cũng giúp ích cho cộng đồng và qua hành trình học tập của mình. Tôi đã tạo một số nhóm thảo luận cho từng phần của thử thách để mọi người có thể tham gia và bình luận.
|
||||
|
||||
|
||||
|
||||
Tab Actions sẽ cho phép bạn build, kiểm thử và triển khai mã,... với GitHub. GitHub Actions sẽ là nội dung chúng ta đề cập trong phần CI/CD của thử thách, đây là nơi chúng ta có thể đặt một số cấu hình để tự động hóa các bước.
|
||||
|
||||
Trên Hồ sơ GitHub chính của mình, tôi đang sử dụng GitHub Actions để tìm các bài đăng trên blog và video YouTube mới nhất để cập nhật màn hình chính đó.
|
||||
|
||||
|
||||
|
||||
Tôi đã đề cập ở trên về cách GitHub không chỉ là kho lưu trữ mã nguồn mà còn là một công cụ quản lý dự án, tab Project cho phép chúng ta xây dựng các bảng kanban cho dự án để chúng ta có thể liên kết các Issues và PR nhằm cộng tác tốt hơn và có thểm theo dõi tiến độ của các tasks.
|
||||
|
||||
|
||||
|
||||
Tôi biết rằng issues có vẻ là một nơi tốt để ghi lại các yêu cầu tính năng và chúng đúng là để làm như vậy nhưng trang wiki cho phép phác thảo một lộ trình toàn diện cho dự án với trạng thái hiện tại và giúp các tài liệu hoàn thiện hơn cho dự án của bạn, ví dụ như hướng dẫn khắc phục sự cố các nội dụng dạng how-to.
|
||||
|
||||
|
||||
|
||||
Không có trong dự án này nhưng có tab Security để đảm bảo rằng những contributors biết cách xử lý một số tác vụ nhất định, chúng tôi có thể xác định một policy tại đây cũng như các tiện ích quét mã để đảm bảo mã của bạn không chứa các biến môi trường bí mật.
|
||||
|
||||
|
||||
|
||||
Đối với tôi, tab insights rất tuyệt, nó cung cấp rất nhiều thông tin về kho lưu trữ, từ bao nhiêu hoạt động đang diễn ra cho đến các commits và issues, nhưng nó cũng báo cáo về lượng truy cập vào kho lưu trữ. Bạn có thể thấy một danh sách ở phía bên trái cho phép bạn xem chi tiết về các số liệu trên kho lưu trữ.
|
||||
|
||||
|
||||
|
||||
Cuối cùng, chúng tôi có tab Settings, đây là nơi chúng tôi có thể xem chi tiết cách chúng tôi chạy kho lưu trữ của mình, tôi hiện là người bảo trì duy nhất của kho lưu trữ nhưng chúng tôi có thể chia sẻ trách nhiệm này tại đây. Chúng ta có thể định nghĩa tích hợp và các tác vụ khác tương tự như vậy tại đây.
|
||||
|
||||
|
||||
|
||||
This was a super quick overview of GitHub, I think there are some other areas that I might have mentioned that need explaining in a little more detail. As mentioned GitHub houses millions of repositories mostly these are holding source code and these can be public or privately accessible.
|
||||
|
||||
Đây là tổng quan siêu nhanh về GitHub, tôi nghĩ rằng có một số lĩnh vực khác mà tôi có thể đã đề cập cần được giải thích chi tiết hơn một chút. Như đã đề cập, GitHub chứa hàng triệu kho lưu trữ, hầu hết những kho lưu trữ này đang chứa mã nguồn và chúng có thể được truy cập công khai hoặc riêng tư.
|
||||
|
||||
### Forking
|
||||
|
||||
Ta sẽ tìm hiểu thêm về Nguồn mở trong buổi ngày mai nhưng một phần quan trọng của bất kỳ kho lưu trữ mã nào là khả năng cộng tác với cộng đồng. Hãy nghĩ về kịch bản sau: tôi muốn có một bản sao của kho lưu trữ vì tôi muốn thực hiện một số thay đổi, có thể tôi muốn sửa lỗi hoặc có thể tôi muốn thay đổi thứ gì đó để sử dụng nó cho trường hợp sử dụng mà tôi có thể không trường hợp sử dụng dự định cho người bảo trì ban đầu của mã. Đây là những gì chúng tôi gọi là forking một kho lưu trữ. Một ngã ba là một bản sao của một kho lưu trữ. Forking một kho lưu trữ cho phép bạn tự do thử nghiệm các thay đổi mà không ảnh hưởng đến dự án ban đầu.
|
||||
|
||||
Hãy để tôi quay lại trang mở đầu sau khi đăng nhập và xem một trong những kho lưu trữ được đề xuất đó.
|
||||
|
||||
I am going to get more into Open-Source in the session tomorrow but a big part of any code repository is the ability to collaborate with the community. Let's think of the scenario I want a copy of a repository because I want to make some changes to it, maybe I want to fix a bug or maybe I want to change something to use it for a use case that I have that was maybe not the intended use case for the original maintainer of the code. This is what we would call forking a repository. A fork is a copy of a repository. Forking a repository allows you to freely experiment with changes without affecting the original project.
|
||||
|
||||
|
||||
|
||||
Nếu chúng ta nhấp vào kho lưu trữ đó, chúng ta sẽ có giao diện giống như kho lưu trữ 90DaysOfDevOps.
|
||||
|
||||
|
||||
|
||||
|
||||
If we notice below we have 3 options, we have watch, fork and star.
|
||||
|
||||
- Watch - Updates when things happen to the repository.
|
||||
- Fork - a copy of a repository.
|
||||
- Star - "I think your project is cool"
|
||||
|
||||
|
||||
|
||||
Given our scenario of wanting a copy of this repository to work on we are going to hit the fork option. If you are a member of multiple organisations then you will have to choose where the fork will take place, I am going to choose my profile.
|
||||
|
||||
|
||||
|
||||
Now we have our copy of the repository that we can freely work on and change as we see fit. This would be the start of the pull request process that we mentioned briefly before but we will cover it in more detail tomorrow.
|
||||
|
||||
|
||||
|
||||
Ok, I hear you say, but how do I make changes to this repository and code if it's on a website, well you can go through and edit on the website but it's not going to be the same as using your favourite IDE on your local system with your favourite colour theme. For us to get a copy of this repository on our local machine we will perform a clone of the repository. This will allow us to work on things locally and then push our changes back into our forked copy of the repository.
|
||||
|
||||
We have several options when it comes to getting a copy of this code as you can see below.
|
||||
|
||||
There is a local version available of GitHub Desktop which gives you a visual desktop application to track changes and push and pull changes between local and GitHub.
|
||||
|
||||
For this little demo, I am going to use the HTTPS URL we see on there.
|
||||
|
||||
|
||||
|
||||
Now on our local machine, I am going to navigate to a directory I am happy to download this repository to and then run `git clone url`
|
||||
|
||||
|
||||
|
||||
Now we could take it to VScode to make some changes to this.
|
||||
|
||||
|
||||
|
||||
Let's now make some changes, I want to make a change to all those links and replace that with something else.
|
||||
|
||||
|
||||
|
||||
Now if we check back on GitHub and we find our readme.mdin that repository, you should be able to see a few changes that I made to the file.
|
||||
|
||||
|
||||
|
||||
At this stage, this might be complete and we might be happy with our change as we are the only people going to use our new change but maybe it was a bug change and if that is the case then we will want to contribute via a Pull Request to notify the original repository maintainers of our change and see if they accept our changes.
|
||||
|
||||
We can do this by using the contribute button highlighted below. I will cover more on this tomorrow when we look into Open-Source workflows.
|
||||
|
||||
|
||||
|
||||
I have spent a long time looking through GitHub and I hear some of you cry but what about other options!
|
||||
|
||||
Well, there are and I am going to find some resources that cover the basics for some of those as well. You are going to come across GitLab and BitBucket amongst others in your travels and whilst they are git-based services they have their differences.
|
||||
|
||||
You will also come across hosted options. Most commonly here I have seen GitLab as a hosted version vs GitHub Enterprise (Don't believe there is a free hosted GitHub?)
|
||||
|
||||
## Tài liệu tham khảo
|
||||
|
||||
- [Learn GitLab in 3 Hours | GitLab Complete Tutorial For Beginners](https://www.youtube.com/watch?v=8aV5AxJrHDg)
|
||||
- [BitBucket Tutorials Playlist](https://www.youtube.com/watch?v=OMLh-5O6Ub8&list=PLaD4FvsFdarSyyGl3ooAm-ZyAllgw_AM5)
|
||||
- [What is Version Control?](https://www.youtube.com/watch?v=Yc8sCSeMhi4)
|
||||
- [Types of Version Control System](https://www.youtube.com/watch?v=kr62e_n6QuQ)
|
||||
- [Git Tutorial for Beginners](https://www.youtube.com/watch?v=8JJ101D3knE&t=52s)
|
||||
- [Git for Professionals Tutorial](https://www.youtube.com/watch?v=Uszj_k0DGsg)
|
||||
- [Git and GitHub for Beginners - Crash Course](https://www.youtube.com/watch?v=RGOj5yH7evk&t=8s)
|
||||
- [Complete Git and GitHub Tutorial](https://www.youtube.com/watch?v=apGV9Kg7ics)
|
||||
- [Git cheatsheet](https://www.atlassian.com/git/tutorials/atlassian-git-cheatsheet)
|
||||
|
||||
Hẹn gặp lại vào [ngày 41](day41.md)
|
||||
129
2022/vi/Days/day41.md
Normal file
129
2022/vi/Days/day41.md
Normal file
@ -0,0 +1,129 @@
|
||||
---
|
||||
title: '#90DaysOfDevOps - Quy trình làm việc với mã nguồn mở - Ngày 41'
|
||||
published: false
|
||||
description: 90DaysOfDevOps -Quy trình làm việc với mã nguồn mở
|
||||
tags: 'DevOps, 90daysofdevops, learning'
|
||||
cover_image: null
|
||||
canonical_url: null
|
||||
id: 1048806
|
||||
---
|
||||
|
||||
## Quy trình làm việc với mã nguồn mở
|
||||
|
||||
Hi vọng rằng qua 7 bài viết vừa rồi với Git, chúng ta đã hiểu rõ hơn về git là gì và sau đó là cách một dịch vụ sử dụng git như Github tích hợp với git để cung cấp kho lưu trữ mã nguồn và cũng là cách cộng đồng có thể cộng tác trên mã và các dự án khác nhau.
|
||||
|
||||
Khi chúng ta xem xét các kiến thức cơ bản về GitHub, chúng ta đã trải qua quá trình fork một dự án bất kỳ và thực hiện thay đổi đó với kho lưu trữ cục bộ của chúng ta. Bây giờ, chúng ta sẽ tiến thêm một bước và thực hiện đóng góp cho một dự án mã nguồn mở. Hãy nhớ rằng việc đóng góp không nhất thiết phải là các bản sửa lỗi hoặc các tính năng cần viết mã, nó cũng có thể là tài liệu, sửa lỗi chính tả. Tất cả thứ dù là nhỏ nhất đều hữu ích và nó cũng cho phép bạn thực hành với một số chức năng git mà chúng ta đã đề cập trong những ngày qua.
|
||||
|
||||
## Fork một project
|
||||
|
||||
Điều đầu tiên chúng ta phải làm là tìm một dự án mà chúng ta có thể đóng góp. Gần đây, tôi đã thuyết trình về dự án [Kanister Project](https://github.com/kanisterio/kanister) và tôi muốn chia sẻ các bài thuyết trình của mình đã được đăng tải trên Youtube tới tệp Readme.md trong project đó.
|
||||
|
||||
Trước hết, chúng ta cần fork project đó. Hãy cùng thử quy trình đó. Tôi sẽ tới liên kết đã ở trên và fork kho lưu trữ của project.
|
||||
|
||||
|
||||
|
||||
Bây giờ, chúng ta đã có bản sao của toàn bộ kho lưu trữ.
|
||||
|
||||
|
||||
|
||||
Để tham khảo trên tệp Readme.md, các bài trình bài ban đầu được liệt kê chỉ gồm 2 bài này, vì vậy chúng ta sẽ sửa với quy trình của chúng ta.
|
||||
|
||||
|
||||
|
||||
## Clone vào máy cục bộ
|
||||
|
||||
Sau khi có bản fork của kho lưu trữ, chúng ta có thể mang nó xuống máy cục bộ của mình và bắt đầu thực hiện chỉnh sửa của mình đối với các tệp. Sử dụng nút `code` trong repo của chúng ta để có thể lấy URL của kho lưu trữ rồi sử dụng lệnh `git clone <url>` trong thư mục mà chúng ta muốn đặt kho lưu trữ.
|
||||
|
||||
|
||||
|
||||
## Thực hiện các thay đổi
|
||||
|
||||
Sau khi có project ở máy của mình, chúng ta có thể mở VSCode hoặc IDE, text editor tuỳ chọn của mình để thực hiện thay đổi của mình.
|
||||
|
||||
|
||||
|
||||
Tệp Readme.md được viết dưới cú pháp markdown và vì chúng ta đang chỉnh sửa một project của người khác nên sẽ thêm nội dung của mình với format của dự án hiện tại.
|
||||
|
||||
|
||||
|
||||
## Kiểm tra thay đổi của bạn
|
||||
|
||||
|
||||
Chúng ta phải kiểm tra các thay đổi của mình theo cách tốt nhất, điều này rất hợp lý nếu đây là thay đổi mã nguồn đối với một ứng dụng mà bạn muốn đảm bảo rằng ứng dụng vẫn hoạt động sau khi thay đổi được thêm vào, chúng ta cũng phải đảm bảo rằng tài liệu được định dạnh và trông một cách chuẩn xác.
|
||||
|
||||
Với VSCode, chúng ta có thể thêm nhiều plugin, một trong số đá là khả năng xem trước các trang markdown.
|
||||
|
||||
|
||||
|
||||
## Push các thay đổi trở lại kho lưu trữ của chúng ta
|
||||
|
||||
Chúng ta không có quyền để đẩy trực tiếp các thay đổi trở lại kho lưu trữ của Kanister, vì vậy chúng ta phải đi theo con đường này. Bây giờ sau khi chúng ta hài lòng với những thay đổi cùa mình, chúng ta có thể chạy quả một số lệnh phổ biến của git.
|
||||
|
||||
|
||||
|
||||
Bây giờ, chúng ta quay trở lại Github để kiểm tra các thay đổi một lần nữa và sau đó đóng góp cho dự án chính.
|
||||
|
||||
Trong có vẻ ổn.
|
||||
|
||||
|
||||
|
||||
Bây giờ chúng ta có thể quay trở lại kho lưu trữ được forked của Kanistẻ và thấy rằng mình đang ở trước một commit so với nhánh kanisterio:master.
|
||||
|
||||
|
||||
|
||||
Tiếp theo, chúng ta nhấn nút `contribute` được đánh dấu ở trên. Chúng ta thấy có lựa chọn "Open Pull Request".
|
||||
|
||||
|
||||
|
||||
## Mở một pull request
|
||||
|
||||
Có khá nhiều thứ trong hình ảnh sau đây, trên cùng bên trái, bạn có thấy chúng ta đang ở kho lưu trữ gốc hoặc kho lưu trữ chính. Một nút tạo Pull request mà chúng ta sẽ nhắc tới sau đây. Chúng ta có một commit duy nhất nhưng nếu chúng ta sửa nhiều hơn thì có thể thấy được nhiều commits hơn ở đây. Sau đó là thay đổi trong tệp Readme.md của mà chúng ta đã thêm vào.
|
||||
|
||||
|
||||
|
||||
|
||||
Sau khi xem xét các thay đổi ở trên và sẵn sàng tạo pull request, chúng ta có thể click nút màu xanh lá cây.
|
||||
|
||||
Sau đó, tuỳ thuộc vào cách người bảo trì dự án thiết lập chứng năng Pull Request trong kho lưu trữ của họ, bạn có thể cần hoặc không cung cấp những thông tin về Pull request theo một template mà người bảo trì đã chuẩn bị.
|
||||
|
||||
Đây là nơi bạn muốn mô tả về những gì bạn đã làm, rõ ràng và ngắn gọn nhưng đầy đủ chi tiết. Bạn có thể thấy tôi đã thực hiện một tổng quan về thay đổi đơn giản và tôi đã đánh dấu vào các đầu mục.
|
||||
|
||||
|
||||
|
||||
## Tạo một pull request
|
||||
|
||||
Bây giờ chúng ta đã sẵn sàng tạo một pull request. Sau khi nhấn "Create Pull Request" ở đầu trang, bạn sẽ nhận được bản tóm tắt về pull request của mình.
|
||||
|
||||
|
||||
|
||||
Kéo xuống dưới, bạn có thể thấy một số quá trình tự động hoá đang diễn ra, trong trường hợp này, chúng ta yêu cầu một review cho pull request của mình. Chúng ta có thể thấy Travis CI đang được tiên shanfh và quá trình build đã được bắt đầu và nó sẽ kiểm tra bản cập nhật của chúng ta, đảm bảo bổ sung mới không phá vỡ bất cứ điều gì.
|
||||
|
||||
|
||||
|
||||
Một điều khác cần lưu ý ở đây là màu đỏ trong ảnh chụp màn hình ở trên, có thể trông hơi khó chịu và có vẻ như bạn đã mặc một lỗi gì đó. Đừng lo lắng, bạn không làm hỏng bất cứ thứ gì, quy trình này là để giúp bạn và người bảo trì của dự án. Theo kinh nghiệm của tôi, nếu bạn mặc mỗi lỗi, người bảo trì sẽ liên hệ và tư vấn về những việc cần làm tiếp theo.
|
||||
|
||||
Pull request này hiện đã được công khai cho mọi người xem [added Kanister presentation/resource #1237](https://github.com/kanisterio/kanister/pull/1237)
|
||||
|
||||
Tôi sẽ publish tất cả những điều này trước khi pull request của tôi được chấp nhận, có lẽ sẽ có một phần thưởng cho ai thêm một hình ảnh của một PR thành công?
|
||||
|
||||
1. Fork kho lưu trữ này về GitHub account của bạn
|
||||
2. Thêm hình ảnh và có thể là một chút văn bản
|
||||
3. Đẩy các thay đổi vào kho lưu trữ đã được forked của bạn
|
||||
4. Tạo PR để tôi xem xét và duyệt
|
||||
5. Tôi sẽ nghĩ một số giải thưởng
|
||||
|
||||
Phần này kết thúc quá trình tìm hiểu về Git và GitHub của chúng ta, tiếp theo, chúng ta sẽ đi sâu vào containers, bắt đầu bằng một bức tranh toàn cảnh, xem xét cách thức và lý do tại sao các chúng ta sử dụng containers cũng như tìm hiểu thêm về ảo hoá.
|
||||
|
||||
## Tài liệu tham khảo
|
||||
|
||||
- [Learn GitLab in 3 Hours | GitLab Complete Tutorial For Beginners](https://www.youtube.com/watch?v=8aV5AxJrHDg)
|
||||
- [BitBucket Tutorials Playlist](https://www.youtube.com/watch?v=OMLh-5O6Ub8&list=PLaD4FvsFdarSyyGl3ooAm-ZyAllgw_AM5)
|
||||
- [What is Version Control?](https://www.youtube.com/watch?v=Yc8sCSeMhi4)
|
||||
- [Types of Version Control System](https://www.youtube.com/watch?v=kr62e_n6QuQ)
|
||||
- [Git Tutorial for Beginners](https://www.youtube.com/watch?v=8JJ101D3knE&t=52s)
|
||||
- [Git for Professionals Tutorial](https://www.youtube.com/watch?v=Uszj_k0DGsg)
|
||||
- [Git and GitHub for Beginners - Crash Course](https://www.youtube.com/watch?v=RGOj5yH7evk&t=8s)
|
||||
- [Complete Git and GitHub Tutorial](https://www.youtube.com/watch?v=apGV9Kg7ics)
|
||||
- [Git cheatsheet](https://www.atlassian.com/git/tutorials/atlassian-git-cheatsheet)
|
||||
|
||||
Hẹn gặp lại vào [ngày 42](day42.md)
|
||||
135
2022/vi/Days/day42.md
Normal file
135
2022/vi/Days/day42.md
Normal file
@ -0,0 +1,135 @@
|
||||
---
|
||||
title: '#90DaysOfDevOps - Bức tranh toàn cảnh: Containers - Day 42'
|
||||
published: false
|
||||
description: 90DaysOfDevOps - Bức tranh toàn cảnh Containers
|
||||
tags: 'devops, 90daysofdevops, learning'
|
||||
cover_image: null
|
||||
canonical_url: null
|
||||
id: 1048826
|
||||
---
|
||||
|
||||
## Bức tranh toàn cảnh: Containers
|
||||
|
||||
Bây giờ, chúng ta bắt đầu với phần tiếp theo và phần này sẽ tập trung vào các containers, cụ thể là chúng ta sẽ nói tới Docker, một vài phần chính để hiểu thêm về các containers.
|
||||
|
||||
Tôi cũng sẽ cố gắng thực hành nhiều trong phần này để tại một số container sử dụng trong phần này và các phần sau của thử thách.
|
||||
|
||||
Như mọi khi, bài đăng đầu tiên này sẽ tập trung vào bức tranh toàn cảnh cách chúng ta đi được tới đây và ý nghĩa của những điều đó.
|
||||
|
||||
- Lịch sử của các phát triển platforms và các ứng dụng
|
||||
- Chúng ta cũng sẽ nói về ảo hoá và container hoá
|
||||
|
||||
### Tại sao chạy ứng dụng bằng một cách khác?
|
||||
|
||||
Điều đầu tiên chúng ta phải xem xét là tại sao chúng ta cần một cách khác để chạy phần mềm hoặc ứng dụng của mình? Chà, lựa chọn đó thật tuyệt, chúng ta có thể chạy các ứng dụng của mình ở nhiều dạng khác nhau, chúng ta có thể thấy các ứng dụng được triển khai trên phần cứng vật lý có hệ điều hành và một ứng dụng duy nhất được triển khai tại đó. Cũng có thể thấy máy ảo hoặc các phiên bản IaaS sử dụng điện toán đám mây chạy ứng dụng của chúng ta, sau đó tích hợp lại vào cơ sở dữ liệu trong máy ảo hoặc dưới dạng cung cấp PaaS trong đám mây công cộng. Hoặc cũng có thể thấy ứng dụng chạy trong các containers.
|
||||
|
||||
Không có lựa chọn nào ở trên là đúng hay sai, nhưng chúng đều có lý do để tồn tại và tôi cũng tin tưởng rằng không có lựa chọn nào trong số này sẽ biến mất trong tương lai gần. Tôi đã thấy rất nhiều nội dung liên quan đến việc so sánh container và VMs và thực sự điều đó không nên được tranh luận, nó giống như tranh luận táo với lê quả nào ngon hơn dù cả hai đều là trái cây (=cách chạy ứng dụng của chúng ta) và chúng không giống nhau.
|
||||
|
||||
Tôi cũng muốn nói rằng nếu bạn mới bắt đầu và đang phát triển một ứng dụng, bạn nên hướng tới các container đơn gỉan khi xét về tính hiệu quả, tốc độ và kích thước. Nhưng điều đó cũng đi kèm với một cái giá, nếu bạn không biết gì về container thì đó sẽ là một quá trình học tập để buộc bản thân bạn phải hiểu lý do tại sao chúng ta sử dụng và xây dựng một mindset mới. Nếu bạn đã phát triển các ứng dụng của mình theo một cách cụ thể hoặc chưa từng sử dụng containers thì bạn có thể có nhiều vấn đề khó giải quyết hơn trước cả khi xem xét đến việc sử dụng chúng.
|
||||
|
||||
Chúng tôi có nhiều sự lựa chọn khác nhau khi tải xuống một phần mềm nhất định, có rất nhiều hệ điều hành khác nhau mà chúng ta có thể đang sử dụng và hướng dẫn cụ thể về những gì chúng ta cần làm để cài đặt ứng dụng của mình.
|
||||
|
||||
|
||||
|
||||
Gần đây, tôi nhận thấy rằng các ứng dụng mà chúng tôi có thể đã từng cần một hệ điều hành máy chủ đầy đủ, một máy ảo, một instance vật lý hoặc điện toán đám mây hiện đang phát hành các phiên bản phần mềm trên container của chúng. Tôi thấy điều này khá thú vị vì nó đứa thế giới của container và sau đó là Kubernetes tới mọi người chứ không chỉ tập trung vào các nhà phát triển ứng dụng.
|
||||
|
||||
|
||||
|
||||
Như bạn có thể thấy như tôi đã nói trước đây, tôi sẽ không cố thuyết phục rằng câu trả lời cho việc chạy các ứng dụng là việc sử dụng các containers! Tôi nói răng đây là một tùy chọn khác mà chúng ta cần lưu ý khi triển khai các ứng dụng của mình.
|
||||
|
||||
|
||||
|
||||
Chúng ta đã có công nghệ container trong một thời gian dài, vậy tại sao trong 10 năm qua, điều này đã trở nên phổ biến, tôi có thể nói rằng thậm chí nó còn phổ biến hơn trong 5 năm qua. Chúng ta đã có container trong nhiều thập kỷ. Nó liên quan đến các thách thức của containers hay thậm chí các images, về cách chúng ta phân phối phần mềm của mình, bởi vì nếu chúng ta chỉ có công nghệ container, thì chúng ta vẫn sẽ gặp các vấn đề giống như chúng ta đã gặp phải với quản lý phần mềm.
|
||||
|
||||
Nếu chúng ta coi Docker như một công cụ, thì lý do khiến nó thành công là do hệ sinh thái images dễ tìm kiếm và sử dụng. Việc tích hợp vào hệ thống của bạn và thiết lập và chạy trở nên rất đơn giản. Một phần quan trọng của điều này là tính nhất quán, một trong những thách thức mà chúng ta phải đối mặt với việc triển phai, phát triển phần mềm. Không quan trọng đó là MongoDB hay nodeJS, quá trình thiết lập và chạy hai phần mềm này sẽ giống nhau. Việc tắt các ứng dụng trên cũng giống nhau. Tất cả những vấn đề vẫn sẽ tồn tại, nhưng điều tuyệt vời là khi chúng tôi kết hợp công nghệ images và containers với nhau, giờ đây chúng tôi có một bộ công cụ duy nhất giúp chúng tôi giải quyết tất cả các vấn đề được liệt kê dưới đây:
|
||||
|
||||
- Đầu tiên chúng ta phải tìm phần mềm trên internet.
|
||||
- Sau đó chúng ta phải tải phần mềm này về.
|
||||
- Chúng ta có tin nguồn mà chúng ta tải về không?
|
||||
- Vậy chúng ta có cần giấy phép không? License nào là phù hợp?
|
||||
- Có tương thích với các nền tảng khác nhau không?
|
||||
- Package đó là gì? mã nhị phân? tệp thực thi? Trình quản lý gói?
|
||||
- Làm thế nào để chúng ta cấu hình phần mềm?
|
||||
- Các dependencies? Toàn bộ quá trình tải xuống bao gồm chúng hay chúng ta cũng cần cài đặt, cấu hình chúng?
|
||||
- Dependencies của dependencies?
|
||||
- Làm thế nào để bắt đầu ứng dụng?
|
||||
- Làm thế nào để dừng ứng dụng?
|
||||
- Nó có tự động khởi động lại không?
|
||||
- Khởi động khi boot?
|
||||
- Xung đột tài nguyên?
|
||||
- Xung đột thư viện?
|
||||
- Xung đột cổng
|
||||
- Bảo mật cho phần mềm?
|
||||
- Nâng cấp phần mềm?
|
||||
- Làm cách nào để gỡ bỏ phần mềm?
|
||||
|
||||
Chúng ta có thể chia những điều trên thành 3 lĩnh vực rất phức tạp của phần mềm mà các containers và images giúp chúng ta giải quyết.
|
||||
|
||||
| Phân phối | Cài đặt | Vận hành |
|
||||
| ------------ | ------------- | ------------------ |
|
||||
| Find | Install | Start |
|
||||
| Download | Configuration | Security |
|
||||
| License | Uninstall | Ports |
|
||||
| Package | Dependencies | Resource Conflicts |
|
||||
| Trust | Platform | Auto-Restart |
|
||||
| Find | Libraries | Updates |
|
||||
|
||||
|
||||
Containers và images sẽ giúp chúng ta loại bỏ một số thách thức mà chúng ta gặp phải với các phần mềm và ứng dụng khác.
|
||||
|
||||
Ở high-level, chúng ta có thể gộp cài đặt và vận hành vào cùng một danh sách, images sẽ giúp chúng ta từ quan điểm phân phối và containers giúp cài đặt và vận hành.
|
||||
|
||||
Ok, nghe có vẻ hay và thú vị nhưng chúng ta vẫn cần hiểu containers là gì và như tôi đã đề cập đến images nên tiếp theo chúng ta hãy đề cập đến phần đó.
|
||||
|
||||
Một điều khác mà bạn có thể đã thấy rất nhiều khi chúng ta nói về Container để phát triển phần mềm là sự giống nhau của chúng với các công-te-nơ (container) vận chuyển, container vận chuyển được sử dụng để vận chuyển nhiều loại hàng hóa trên biển bằng tàu lớn.
|
||||
|
||||
|
||||
|
||||
Vậy thì những điều này có liên quan gì tới chủ đề container của chúng ta? Hãy nghĩ về mã nguồn mà các nhà phát triển phần mềm đã viết, làm thế nào chúng ta có thể triển kahi mã đó từ máy này sang một máy khác?
|
||||
|
||||
Nếu chúng ta nghĩ về những gì đã được biết tới phân phối phần mềm, cài đặt và vận hành nhưng bây giờ chúng ta sẽ xây dựng chúng tành một hình ảnh môi trường. Chúng ta có phần cứng và hệ điều hành nơi bạn sẽ chạy nhiều ứng dụng. Ví dụ: NodeJS có một số dependencies nhất định và cần một số thư viện nhất định. Nếu sau đó bạn muốn cài đặt MySQL thì nó cần các thư viện và dependencies cần thiết. Mỗi ứng dụng phần mềm sẽ có thư viện và dependencies của nó. Chúng ta có thể rất may mắn và không có bất kỳ xung đột nào giữa bất kỳ các ứng dụng nào của chúng ta bởi sự xung đột giữa các thư viện và dependencies. Tuy nhiên, càng nhiều ứng dụng thì sẽ có càng nhiều cơ hội hoặc rủi ro xảy ra do các xung đột đó. Các ứng dụng sẽ được cập nhật và những xung đột này. Rất có thể với một lần triển khai sửa chữa các phần mềm của bản bằng việc update chúng sẽ tạo ra các xung đột khác.
|
||||
|
||||
|
||||
|
||||
Containers có thể giúp giải quyết vấn đề này. Containers giúp **xây dựng** ứng dụng của bạn, **vận chuyển** ứng dụng đó, **triển khai** và **mở rộng quy mô các ứng dụng này một cách dễ dàng và độc lập với nhau. Hãy nhìn vào kiến trúc, bạn sẽ có phần cứng và hệ điều hành, sau đó, bạn sẽ có một container engine như docker (chúng ta sẽ nhắc tới sau). Phần mềm container engine sẽ giúp tạo các container đóng gói các thư viện và các dependencies cùng với nó để bạn có thể di chuyển container này từ máy này sang máy khác mà không phải lo lắng về các thư viện và dependencies vì chúng là một phần của container. Container này có thể được di chuyển qua các hệ thống mà không phải lo lắng về các dependencies mà ứng dụng cần để chạy vì mọi thứ mà ứng dụng cần đều được đóng gói thành một container.
|
||||
|
||||
|
||||
|
||||
### Ưu điểm của containers
|
||||
|
||||
- Container giúp đóng gói tất cả các dependencies bên trong và cô lập nó.
|
||||
|
||||
- Dễ dàng quản lý các containers
|
||||
|
||||
- Khả năng di chuyển từ hệ thống này qua hệ thống khác
|
||||
|
||||
- Container giúp đóng gói phần mềm và bạn có thể dễ dàng vận chuyển nó mà không cần nhiều nỗ lực
|
||||
|
||||
- Container có khả năng mở rộng dễ dàng
|
||||
|
||||
Sử dụng các container, bạn có thể mở rộng các container và sử dụng bộ cân bằng tải hoặc một service để phân chia lưu lượng và có thể mở rộng ứng dụng theo chiều ngang. Container cung cấp tính linh hoạt và dễ dàng trong việc quản lý các ứng dụng của mình.
|
||||
|
||||
### Container là gì?
|
||||
|
||||
Khi chúng ta chạy các ứng dụng trên máy tính, đây có thể là VSCode hoặc trình duyệt web mà bạn đang sử dụng để đọc bài viết này. Ứng dụng đó đang chạy dưới dạng một process hoặc một thứ gì đó coi là một process. Trên máy tính xách tay hoặc hệ thống của chúng ta, chúng ta có xu hướng chạy nhiều ứng dụng hoặc như chúng tôi đã nói là các process. Khi chúng ta mở một ứng dụng mới hoặc click vào biểu tượng ứng dụng, đây là ứng dụng chúng ta muốn chạy, đôi khi ứng dụng này có thể là một dịch vụ mà chúng tôi chỉ muốn chạy nền, hệ điều hành của chúng ta có rất nhiều các dịch vụ chạy nền cung cấp cho bạn trải nghiệm người dùng mà bạn có đang có với hệ thống.
|
||||
|
||||
Biểu tượng ứng dụng đó đại diện cho một liên kết đến một tệp thực thi ở đâu đó trên hệ thống tệp của bạn, sau đó hệ điều hành sẽ tải tệp thực thi đó vào bộ nhớ. Thật thú vị, tệp thực thi đó đôi khi được nhắc tới như là một hình ảnh khi chúng ta đang nói về một process.
|
||||
|
||||
Containers là các processes, một container là một đơn vị phần mềm tiêu chuẩn đóng gói mã và tất cả các dependencies của nó để ứng dụng chạy nhanh và đáng tin cậy từ môi trường điện toán này sang môi trường điện toán khác.
|
||||
|
||||
Phần mềm được đóng gói trong container sẽ luôn chạy giống nhau, bất kể trên cơ sở hạ tầng nào. Các container cách ly phần mềm khỏi môi trường của nó và đảm bảo rằng nó hoạt động đồng nhất bất chấp sự khác biệt chẳng hạn giữa môi trường phát triển và staging.
|
||||
|
||||
Tôi đã đề cập đến image trong phần trước khi đề cập đến cách thức và lý do tại sao các container và image được kết hợp với nhau khiến các container trở nên phổ biến trong hệ sinh thái của chúng ta.
|
||||
|
||||
### Image là gì?
|
||||
|
||||
Container image là một gói phần mềm nhẹ, độc lập, có thể thực thi, bao gồm mọi thứ cần thiết để chạy một ứng dụng: mã, runtime, công cụ hệ thống, thư viện hệ thống và cài đặt. Container image trở thành container khi chạy.
|
||||
|
||||
## Tài liệu tham khảo
|
||||
|
||||
- [TechWorld with Nana - Docker Tutorial for Beginners](https://www.youtube.com/watch?v=3c-iBn73dDE)
|
||||
- [Programming with Mosh - Docker Tutorial for Beginners](https://www.youtube.com/watch?v=pTFZFxd4hOI)
|
||||
- [Docker Tutorial for Beginners - What is Docker? Introduction to Containers](https://www.youtube.com/watch?v=17Bl31rlnRM&list=WL&index=128&t=61s)
|
||||
- [Introduction to Container By Red Hat](https://www.redhat.com/en/topics/containers)
|
||||
|
||||
Hẹn gặp lại vào [ngày 43](day43.md)
|
||||
94
2022/vi/Days/day43.md
Normal file
94
2022/vi/Days/day43.md
Normal file
@ -0,0 +1,94 @@
|
||||
---
|
||||
title: '#90DaysOfDevOps - Docker là gì & Cài đặt - Ngày 43'
|
||||
published: false
|
||||
description: 90DaysOfDevOps - Docker là gì & Cài đặt
|
||||
tags: 'devops, 90daysofdevops, learning'
|
||||
cover_image: null
|
||||
canonical_url: null
|
||||
id: 1048739
|
||||
---
|
||||
|
||||
## Docker là gì & Cài đặt
|
||||
|
||||
Trong bài viết trước, tôi đã đề cập đến Docker ít nhất một lần và lý do là Docker đá đóng góp công lớn trong việc làm cho container trở nên phổ biến mặc dù chúng đã xuất hiện từ lâu.
|
||||
|
||||
Chúng ta sẽ sử dụng và giải thích về docker nhưng cũng sẽ đề cập tới [Open Container Initiative (OCI)](https://www.opencontainers.org/) là một tổ chức tiêu chuẩn công nghiệp khuyến khích đổi mới đồng thời giảm thiểu nguy cơ các dịch vụ bị khoá với các nhà cung cấp. Nhờ có OCI, khi chúng ta chọn chuỗi các công cụ container, chúng ta có thể chọn Docker, [CRI-O](https://cri-o.io/), [Podman](http://podman.io/), [LXC](https://linuxcontainers.org/), và các công cụ khác.
|
||||
|
||||
Docker là một khung phần mềm để xây dựng, chạy, quản lý các vùng chứa. Thuật ngữ "docker" có thể đề cập đến các công cụ (các lệnh và deamon)
|
||||
hoặc định dạng tệp Dockerfile.
|
||||
|
||||
Chúng ta sẽ sử dọng Docker Personal trong tuần này, nó sẽ được miễn phí cho mục đích học tập. Tất cả những chức năng cần thiết mà chúng ta cần trang bị để có kiến thức nền tảng tốt về container và công cụ xung quanh đều có trong Docker Personal.
|
||||
|
||||
Có lẽ đáng để chia nhỏ một số công cụ "docker" mà chúng ta sẽ sử dụng và cách chúng được sử dụng. Thuật ngữ docker có thể đề cập đến dự án docker nói chung, đây là một nền tảng dành cho các nhà phát triển và quản trị viên để phát triển, vận chuyển và chạy các ứng dụng. Nó cũng có thể nhắn tới process docker daemon chạy trên máy chủ quản lý image và container, hay còn được gọi là Docker Engine.
|
||||
|
||||
### Docker Engine
|
||||
|
||||
Docker Engine là một công nghệ container mã nguồn mở để xây dựng và đóng gói các ứng dụng của bạn. Docker Engine hoạt động như một ứng dụng client-server với:
|
||||
|
||||
- Một máy chủ có tiến trình daemon dockerd.
|
||||
- API với các giao diện mà các chương trình có thể sử dụng để giao tiếp và đưa ra chỉ thị với daemon Docker.
|
||||
- Giao diện dòng lệnh (CLI) của docker.
|
||||
|
||||
Phần trên được lấy từ tài liệu chính thức của Docker và [Tổng quan về Docker Engine cụ thể](https://docs.docker.com/engine/)
|
||||
|
||||
### Docker Desktop
|
||||
|
||||
Chúng ta có docker desktop cho cả Windows và macOS. Nó là một môi trường phát triển docker nhẹ, dễ cài đặt. Một ứng dụng native với khả năng tận dụng khả năng ảo hóa trên hệ điều hành máy chủ.
|
||||
|
||||
Đây là giải pháp tốt nhất nếu bạn muốn xây dựng, gỡ lỗi, thử nghiệm, đóng gói và vận chuyển các ứng dụng Dockerized trên Windows hoặc macOS.
|
||||
|
||||
Trên Windows, chúng ta cũng có thể tận dụng WSL2 và Microsoft Hyper-V. Chúng ta sẽ đề cập đến một số lợi ích của WSL2 trong các phần tiếp theo.
|
||||
|
||||
Do tích hợp với các khả năng của trình ảo hóa trên hệ điều hành máy chủ, docker cung cấp khả năng chạy các vùng chứa của bạn với Hệ điều hành Linux.
|
||||
|
||||
### Docker Compose
|
||||
|
||||
Docker compose là một công cụ cho phép bạn chạy các ứng dụng phức tạp hơn trên nhiều containers. Với lợi ích là có thể sử dụng một tệp và lệnh duy nhất để khởi động ứng dụng của bạn.
|
||||
|
||||
### Docker Hub
|
||||
|
||||
Một tài nguyên tập trung để làm việc với Docker và các thành phần của nó. Thường được gọi là một registry để lưu trữ các docker images. Nhưng có rất nhiều dịch vụ bổ sung ở đây có thể được sử dụng để tự động hóa, tích hợp vào GitHub hoặc quét bảo mật.
|
||||
|
||||
### Dockerfile
|
||||
|
||||
Dockerfile là một tệp văn bản chứa các lệnh mà bạn thường thực hiện thủ công để tạo docker image. Docker có thể tự động tạo image bằng cách đọc các chỉ dẫn chúng ta có trong dockerfile của mình.
|
||||
|
||||
## Cài đặt Docker Desktop
|
||||
|
||||
[Tài liệu của Docker](https://docs.docker.com/engine/install/) rất tốt cho các bạn mới tìm hiểu về docker. Chúng ta sẽ sử dụng Docker Desktop trên Windows với WSL2. Tôi đã cài đặt cho máy tính mà chúng ta sẽ sử dụng ở trong phần này.
|
||||
|
||||
|
||||
|
||||
Lưu ý trước khi bạn tiếp tục và
|
||||
|
||||
Take note before you go ahead and install at the system requirements, [Install Docker Desktop on Windows](https://docs.docker.com/desktop/windows/install/) if you are using macOS including the M1-based CPU architecture you can also take a look at [Install Docker Desktop on macOS](https://docs.docker.com/desktop/mac/install/)
|
||||
|
||||
Tôi sẽ cặt đặt Docker Desktop cho Windows trên một máy Windows khác và ghi lại quá trình bên dưới.
|
||||
|
||||
### Windows
|
||||
|
||||
- Chọn windows làm hệ điều hành cho thiết bị của bạn.
|
||||
|
||||
|
||||
|
||||
- Điều hướng đến thư mục mà bạn muốn lưu bộ cài đặt và lưu lại.
|
||||
|
||||
- Chạy bộ cài và đợi vài giây rồi cấp quyền truy cập cho WSL.
|
||||
|
||||
|
||||
|
||||
- Nhấn ok và quá trình cài đặt sẽ bắt đầu.
|
||||
|
||||
|
||||
- Docker Desktop đã được cài đặt thành công trên thiết bị của bạn. Bây giờ bạn có thể chạy lệnh "docker" trên terminal để kiểm tra xem cài đặt có thành công hay không.
|
||||
|
||||
|
||||
|
||||
## Tài liệu tham khảo
|
||||
|
||||
- [TechWorld with Nana - Docker Tutorial for Beginners](https://www.youtube.com/watch?v=3c-iBn73dDE)
|
||||
- [Programming with Mosh - Docker Tutorial for Beginners](https://www.youtube.com/watch?v=pTFZFxd4hOI)
|
||||
- [Docker Tutorial for Beginners - What is Docker? Introduction to Containers](https://www.youtube.com/watch?v=17Bl31rlnRM&list=WL&index=128&t=61s)
|
||||
- [WSL 2 with Docker getting started](https://www.youtube.com/watch?v=5RQbdMn04Oc)
|
||||
|
||||
Hẹn gặp lại vào [ngày 44](day44.md)
|
||||
142
2022/vi/Days/day44.md
Normal file
142
2022/vi/Days/day44.md
Normal file
@ -0,0 +1,142 @@
|
||||
---
|
||||
title: '#90DaysOfDevOps - Docker Images & Thực hành với Docker Desktop - Ngày 44'
|
||||
published: false
|
||||
description: 90DaysOfDevOps - Docker Images & Thực hành với Docker Desktop
|
||||
tags: 'devops, 90daysofdevops, learning'
|
||||
cover_image: null
|
||||
canonical_url: null
|
||||
id: 1048708
|
||||
---
|
||||
|
||||
## Docker Images & Thực hành với Docker Desktop
|
||||
|
||||
Bây giờ chúng ta đã cài đặt Docker Desktop trên hệ thống của mình. (Nếu bạn đang chạy Linux thì bạn vẫn còn có các tuỳ chọn nhưng không có GUI, dù sao thì docker có hoạt động trên Linux.) [Cài đặt Docker Engine trên Ubuntu](https://docs.docker.com/engine/install/ubuntu/) (Các bản phân phối khác cũng có sẵn.)
|
||||
|
||||
Trong bài đăng này, chúng ta sẽ bắt đầu triển khai một số images và môi trường của chúng ta. Nhắc lại về Docker image - Docker image là một tệp được sử dụng để thực thi mã trong Docker container. Docker image hoạt động như một bộ chỉ dẫn để xây dựng Docker container, giống như một template. Docker images cũng đóng vai trò là điểm bắt đầu khi sử dụng Docker.
|
||||
|
||||
Bây giờ là thời điểm tốt để tạo tài khoản cảu bạn trên [DockerHub](https://hub.docker.com/)
|
||||
|
||||
|
||||
|
||||
DockerHub là một tài nguyên tập trung để làm việc với Docker và các thành phần khác của nó. Thường được gọi là một registry để lưu trữ các docker images. Nhưng có rất nhiều dịch vụ bổ sung ở đây có thể được sử dụng để tự động hóa, tích hợp vào GitHub hoặc quét bảo mật.
|
||||
|
||||
Nếu bạn kéo xuống sau khi đăng nhập, bạn sẽ thấy danh sách các container image. Bạn có thể thấy các image cho cơ sở dữ liệu sử dụng MySQL, hello-world, v.v. Hãy coi đây là những image cơ sở tốt, bạn có thể chỉ cần một image cho cơ sở dữ liệu ở đây và trong phần lớn trường hợp, tốt nhất là bạn nên sử dụng image chính thức (với dấu tích xanh) thay vì việc tạo riêng image của mình.
|
||||
|
||||
|
||||
|
||||
Chúng ta có thể đi sâu hơn vào chế độ xem các image có sẵn và tìm kiếm trên các danh mục, hệ điều hành và kiến trúc. Một điều tôi nhấn mạnh bên dưới là image chính thức, điều này sẽ giúp bạn yên tâm hơn về nguồn gốc của nó.
|
||||
|
||||
|
||||
|
||||
Chúng ta cũng có thể tìm kiếm một image cụ thể, ví dụ: WordPress có thể là một image cơ sở tốt mà chúng ta muốn, chúng ta có thể làm điều đó ở trên cùng và tìm tất cả các container image liên quan đến WordPress. Dưới đây là chú ý cho việc chúng ta cũng có Verified Publisher.
|
||||
|
||||
- Image chính thức (Official Image) - Docker Official images là một tập hợp các kho lưu trữ giải pháp mã nguồn mở Docker được tuyển chọn.
|
||||
|
||||
- Verified Publisher - Nội dung Docker chất lượng cao từ các tổ chức đã được xác minh. Các sản phẩm này được công khai và duy trì bởi một công ty/tổ chức thương mại.
|
||||
|
||||
|
||||
|
||||
### Khám phá Docker Desktop
|
||||
|
||||
Chúng ta đã cài đặt Docker Desktop trên hệ thống của mình và nnếu bạn mở ứng dụng này, bạn sẽ thấy một cái gì đó tương tự như hình bên dưới. Như bạn có thể thấy, chúng ta không có container nào đang chạy và docker engine của chúng ta đang chạy.
|
||||
|
||||
|
||||
|
||||
Vì đây không phải là bản cài đặt mới đối với tôi nên tôi có một số image đã được tải xuống và có sẵn trên hệ thống của mình. Bạn có thể sẽ không thấy gì ở đây.
|
||||
|
||||
|
||||
|
||||
Bạn sẽ thấy các container images mà bạn đã lưu trữ trong docker hub của mình trong mục remote repositories. Bạn có thể thấy như bên dưới, tôi không có bất kỳ image nào.
|
||||
|
||||
|
||||
|
||||
Chúng ta cũng có thể xác nhận này trên trang dockerhub của mình và xác nhận rằng chúng ta không có gì ở đó.
|
||||
|
||||
|
||||
|
||||
Tiếp theo, chúng ta có tab Volumes, nếu bạn có các containers yêu cầu tính bền vững thì đây là nơi chúng ta có thể thêm các volumes vào hệ thống tệp trên máy của bạn hoặc hệ thống tệp được chia sẻ.
|
||||
|
||||
|
||||
|
||||
Tại thời điểm viết bài, cũng có một tab "Dev Environments", đây là nơi giúp bạn cộng tác với nhóm của mình thay vì sử dụng các nhánh của khác nhau trên git. Tuy nhiên, chúng ta sẽ không nói về phần này.
|
||||
|
||||
|
||||
|
||||
Quay trở lại tab đầu tiên, bạn có thể thấy rằng có một lệnh mà chúng ta có thể chạy, đó là container getting-started. Hãy chạy `docker run -d -p 80:80 docker/getting-started` trong terminal của chúng ta.
|
||||
|
||||
|
||||
|
||||
Nếu chúng ta kiểm tra lại cửa sổ docker desktop, chúng ta sẽ thấy rằng chúng ta có một container đang chạy.
|
||||
|
||||
|
||||
|
||||
Bạn có thể nhận thấy rằng tôi đang sử dụng WSL2 và để có thể sử dụng, bạn cần đảm bảo rằng tính năng này được bật trong cài đặt.
|
||||
|
||||
|
||||
|
||||
Nếu bây giờ chúng ta kiểm tra lại tab Images của mình, bạn sẽ thấy một image đang được sử dụng có tên là `docker/getting-started`.
|
||||
|
||||
|
||||
|
||||
Quay lại tab Containers/Apps, nhấp vào container đang chạy của bạn. Bạn sẽ mặc định thấy được logs và trên thanh ở phía trên, bạn có một số tùy chọn để chọn, trong trường hợp của chúng ta, tôi khá tự tin rằng một trang web chạy trong container này, vì vậy chúng ta sẽ chọn mở trong trình duyệt.
|
||||
|
||||
|
||||
|
||||
Khi chúng tôi nhấn vào nút đó ở trên, chắc chắn rằng một trang web sẽ được mở ra và hiển thị nội dung tương tự như bên dưới.
|
||||
|
||||
Container này cũng có thêm một số chi tiết về container và image của chúng ta.
|
||||
|
||||
|
||||
|
||||
Bây giờ chúng ta đã có container đầu tiên. Chưa có gì quá đáng sợ. Còn nếu chúng ta muốn pull một container image từ DockerHub thì sao? Có thể sẽ có một `hello world` container chúng ta có thể sử dụng.
|
||||
|
||||
Tôi dừng container `getting started` không phải để tiết kiệm tài nguyên mà để những bước sau được nhìn rõ hơn.
|
||||
|
||||
Quay trở lại terminal, chạy `docker run hello-world` và xem điều gì xảy ra.
|
||||
|
||||
Bạn có thể thấy rằng chúng ta không có image ở local, vì vậy chúng ta đã kéo nó xuống từ dockerhub. Sau đó chúng ta nhận được một thông báo trong container image với một số thông tin về những gì nó đã làm để thiết lập và chạy cũng như một số liên kết đến các tài liệu tham khảo.
|
||||
|
||||
|
||||
|
||||
Nếu bây giờ chúng ta vào Docker Desktop, chúng ta không thấy có container đang chạy nhưng có một container đã exited gửi thông báo hello-world message, nghĩa là nó xuất hiện, gửi thông báo và sau đó bị chấm dứt.
|
||||
|
||||
|
||||
|
||||
Và cuối cùng, chúng ta hãy kiểm tra tab Images và thấy rằng chúng ta có một image hello-world mới trên hệ thống của mình, nghĩa là nếu chúng ta chạy lại lệnh `docker run hello-world` trong terminal, chúng ta sẽ không phải kéo bất cứ thứ gì trừ khi phiên bản thay đổi.
|
||||
|
||||
|
||||
|
||||
Thông điệp từ container hello-world đặt ra một thử thách làm một điều gì đó khó hơn một chút.
|
||||
|
||||
Thử thách được chấp nhận!
|
||||
|
||||
|
||||
|
||||
Khi chạy `docker run -it ubuntu bash` trong thiết bị đầu cuối của chúng ta, chúng ta sẽ chạy phiên bản Ubuntu được đóng gói chứ không phải bản sao đầy đủ của Hệ điều hành. Bạn có thể tìm hiểu thêm về image cụ thể này trên [DockerHub](https://hub.docker.com/_/ubuntu)
|
||||
|
||||
Bạn có thể thấy bên dưới khi chúng ta chạy lệnh, giờ đây chúng ta có một dấu nhắc tương tác (`-it`) và chúng ta có một trình shell bằng bash trong container của mình.
|
||||
|
||||
|
||||
|
||||
Chúng tôi có bash shell nhưng chúng ta không có gì khác, đó là lý do tại sao container image này nhỏ hơn 30 MB.
|
||||
|
||||
|
||||
|
||||
Nhưng chúng ta vẫn có thể sử dụng image này và có thể cài đặt phần mềm bằng trình quản lý gói apt của mình, chúng ta cũng có thể cập nhật container image và nâng cấp.
|
||||
|
||||
|
||||
|
||||
Hoặc có thể chúng ta muốn cài đặt một số phần mềm vào container của mình, tôi đã chọn một ví dụ thực sự tệ ở đây vì pinta là một trình chỉnh sửa image và nó có dung lượng hơn 200 MB nhưng hy vọng bạn sẽ hiểu được những gì tôi đang làm ở đây. Điều này sẽ làm tăng đáng kể kích thước container của chúng ta nhưng dù sao thì chúng ta vẫn đang ở MB chứ không phải GB.
|
||||
|
||||
|
||||
|
||||
Tôi hy vọng đã cung cấp cho bạn cái nhìn tổng quan về Docker Desktop và thế giới container không quá đáng sợ khi bạn chia nhỏ nó với các trường hợp sử dụng đơn giản. Chúng ta cần đề cập đến kết nối mạng, bảo mật và các tùy chọn khác mà chúng ta có so với việc chỉ tải xuống container image và sử dụng chúng như thế này. Đến cuối phần này, chúng ta sẽ tạo một cái gì đó, tải nó lên kho lưu trữ DockerHub và có thể triển khai nó.
|
||||
|
||||
## Tài liệu tham khảo
|
||||
|
||||
- [TechWorld with Nana - Docker Tutorial for Beginners](https://www.youtube.com/watch?v=3c-iBn73dDE)
|
||||
- [Programming with Mosh - Docker Tutorial for Beginners](https://www.youtube.com/watch?v=pTFZFxd4hOI)
|
||||
- [Docker Tutorial for Beginners - What is Docker? Introduction to Containers](https://www.youtube.com/watch?v=17Bl31rlnRM&list=WL&index=128&t=61s)
|
||||
- [WSL 2 with Docker getting started](https://www.youtube.com/watch?v=5RQbdMn04Oc)
|
||||
|
||||
Hẹn gặp lại vào [ngày 45](day45.md)
|
||||
@ -81,13 +81,13 @@ Cách nhanh nhất để liên lạc với tôi là thông qua Twitter tại [@M
|
||||
- [✔️] 📚 41 > [Quy trình làm việc với mã nguồn mở](Days/day41.md)
|
||||
### Containers
|
||||
|
||||
- [✔️] 🏗️ 42 > [The Big Picture: Containers](Days/day42.md)
|
||||
- [✔️] 🏗️ 43 > [What is Docker & Getting installed](Days/day43.md)
|
||||
- [✔️] 🏗️ 44 > [Docker Images & Hands-On with Docker Desktop](Days/day44.md)
|
||||
- [✔️] 🏗️ 45 > [The anatomy of a Docker Image](Days/day45.md)
|
||||
- [✔️] 🏗️ 42 > [Bức tranh toàn cảnh: Containers](Days/day42.md)
|
||||
- [✔️] 🏗️ 43 > [Docker là gì & Cài đặt](Days/day43.md)
|
||||
- [✔️] 🏗️ 44 > [Docker Images & Thực hành với Docker Desktop](Days/day44.md)
|
||||
- [✔️] 🏗️ 45 > [Phân tích một Docker Image](Days/day45.md)
|
||||
- [✔️] 🏗️ 46 > [Docker Compose](Days/day46.md)
|
||||
- [✔️] 🏗️ 47 > [Docker Networking & Security](Days/day47.md)
|
||||
- [✔️] 🏗️ 48 > [Alternatives to Docker](Days/day48.md)
|
||||
- [✔️] 🏗️ 48 > [Các lựa chọn thay thế cho Docker](Days/day48.md)
|
||||
|
||||
### Kubernetes
|
||||
|
||||
|
||||
Loading…
Reference in New Issue
Block a user