rsync-with-sparse-file

tags: #rsync #devops #linux #migration

Có thể dùng rsync để chuyển bộ cài đặt Linux qua một đĩa cứng mới (cùng máy) hoặc qua một máy hoàn toàn khác. Tóm tắt bước cơ bản

1. (tùy chọn) tắt hết các dịch vụ đang ghi vào ổ cứng nguồn (A) 1. Chạy rsync với (option) phù hợp để chép qua đĩa đích (B) 1. Fix /etc/fstab và bootloader

Bước cuối cùng thì dễ, giống như khi bạn cài máy mới. Lưu ý là phải đảm bảo /etc/mtab là một symlink

$ ls -ld /etc/mtab
... /etc/mtab -> ../proc/self/mounts

Chạy rsync trong phần lớn trường hợp có thể dùng như sau, với quyền root:

# mount /dev/new_device /mnt/new_disk_B/

# rsync -avx                \
  --progress                \
  /                         \
  /mnt/new_disk_B/          \
  --exclude="/dev/*"        \
  --exclude="/proc/*"       \
  --exclude="/sys/*"

Ý nghĩa vài tham số quan trọng: -a để chép ở chế độ archive, tham số này là viết tắt cho tổ hợp -rlptgoD, trong đó

1. -r: chép mọi thư mục, thư mục con và tập tin của chúng

2. -l: chép các symlink

3. -p, -o, -g, -t: bảo toàn các quyền cơ bản (cấp bởi chmod, chown), các mốc thời gian liên quan đến tập tin hay thư mục, không bao gồm các quyền mở rộng (extended attributes (-X) hay thông tin phân quyền ACL (-A), cũng không bảo toàn các hardlink (-H)),

4. -x: chỉ chép các nội dung được kết nối (mount) vào các thư mục con của thư mục /.

5. Các tham số --exclude để bỏ qua mấy thứ không cần thiết (thực ra thì nếu không có chúng bạn sẽ phải chờ rụng râu.)

Nếu hệ thống cũ (A) của bạn có nhiều phân vùng, ví dụ /boot, /home, /usr/ thì sau lệnh ở trên nội dung của chúng không được chép qua ổ mới do tham số -x ngăn cản việc này. Bạn có thể lặp lại, ví dụ

rsync -avx --progress /boot/ /mnt/new_disk_B/boot/

Xong, đơn giản quá nhen. Ồ không, còn tập hai là điều bạn phải lưu ý:

1. Nếu bạn xài docker với overlayfs, bạn có thể bỏ nó ra khỏi lệnh rsync đầu tiên (--exlude=/var/lib/docker/*), lý do là các hardlink hay sparse file bên trong /var/lib/docker/ (hoặc thư mục khác tùy do bạn cấu hình trong /etc/docker/daemon.json) sẽ khiến bạn chờ rất lâu.

Sau đó, dùng rsync riêng cho thư mục /var/lib/docker với tham số tương tự trên, bổ sung thêm -HSX. Ở đây, -S (hay --sparse) là tùy chọn để chép các tập tin sparse. Nếu không có gì quan trọng bạn cứ xóa luôn /var/lib/docker/ cho khỏe.

2. (Tùy chọn) Nếu có các tập tia đĩa ảo dùng với Virtualbox, qemu gì đó, bạn cũng gặp các tập tin sparse như trên. Khi đó bạn dùng tùy chọn -S trước, rồi tiếp theo, bỏ đi tùy chọn này, chạy lại cùng lệnh rsync nhưng với tùy chọn --inplace. Tùy chọn -S chạy lần đầu tiên sẽ tạo ra các block cần thiết trên ổ đĩa mới B, còn lần sau sẽ chỉ chép các block có thay đổi nội dung.

Nếu dữ liệu ít bạn có thể ngồi chờ. Nếu nhiều bạn cứ việc dùng máy thoải mái, sau khi chạy rsync lần đầu thì bạn thực hiện bước 1 tắt mạng, tắt tất cả các chương trình đang ghi vào ổ đĩa A rồi chạy lại các lệnh rsync cần thiết. Khi đó với các tập tin sparse thì việc dùng --inplace rất mau lẹ, nếu không bạn phải chờ chép 20G hay cả 100G gồm toàn những block không có dữ liệu =))

Về các tập tin Sparse bạn có thể tham khảo ArchLinux wiki hay https://gergap.wordpress.com/2013/08/10/rsync-and-sparse-files/



-- 904d1dac (Ky-Anh Huynh 2019-03-17 16:40:12 +0700 7) at https://github.com/linuxvn/about/blob/master/Notes-2019.md#rsync-with-sparse-file
🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞

k8s-the-hard-way-p1

https://github.com/linuxvn/about/blob/master/Notes-2019.md#k8s-the-hard-way-p1


tags: #k8s #hardway #helm #learning #devops

Nếu bạn đang bắt đầu tìm hiểu về k8s thì mình có luôn lời khuyên là đừng lặp lại sai lầm như mình=) Mình đã bắt đầu với mấy cái khóa học linh tinh trên edX, coursera và cả safaribooksonline. Mình coi rất nhiều rồi không hiểu gì hết luôn. Haha. Từ đâu 2016 mình bắt đầu thử với kops, rồi mãi tới cuối 2018, vẫn còn loay hoay với minikube tùm lum. Rốt cuộc, có quá nhiều thứ, tốn rất nhiều thời gian.

Thế bắt đầu từ đâu? Hãy thử luôn với k8s the hard way https://github.com/kelseyhightower/kubernetes-the-hard-way do một kỹ sư của Google nấu ra. Tài liệu này chỉ có thể thực hành theo khi bạn có thẻ credit/debit, có tài khoản Google. Bạn nhắm mắt làm theo là được.

Nếu dùng aws, bạn có thể theo dõi https://github.com/slawekzachcial/kubernetes-the-hard-way-aws. Với Virtualbox trên máy Linux 64 bạn có thể theo dõi triển khai do mình viết: https://github.com/icy/k8s-vbox-the-hard-way.

Ối, lại linh tinh lang tang. Bạn phải theo dõi tài liệu gốc, viết ra các kịch bản, rồi thêm thắt vào phần tự động hóa cho phù hợp hệ thống của bạn (terraform, script, ansible, ...) Có cần thiết như vậy không? Cần chứ, tại k8s có hai phần

1. Phần cốt lõi, k8s: Nó giúp trả lời các câu hỏi như, k8s có liên quan gì tới Docker (container)? Mà tại sao người ta không dùng Docker Swarm cho rồi? Rồi k8s so sánh với ảo hóa ra sao (sống lâu rồi cũng có người hỏi bạn như vậy).

2. Phần tảng băng nổi bên trên, nơi bạn triển khai ứng dụng. Phần này khá là dễ, bạn chỉ việc làm theo mấy tài liệu bập bập là xong ngay luôn. Yêu cầu cơ bản là biết copy và paste thôi :)

Tại vì phần 2 dễ, nên trước đây mình đã học nó trước tiên. Hóa ra là chỉ theo bóng, mất thời gian mà không hiểu bản chất vấn đề. Nay viết ra hy vọng giúp bạn có thể tiết kiệm được 3 năm kinh nghiệm =))



-- f267f05d (Ky-Anh Huynh 2019-03-26 05:11:29 +0700 28) at https://github.com/linuxvn/about/blob/master/Notes-2019.md#k8s-the-hard-way-p1
🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞

boss-interview

https://github.com/linuxvn/about/blob/master/Notes-2019.md#boss-interview


tags: #devops #jobs

Bài này dành cho [dev]ops... tàng tàng :)

Mình đã làm việc với nhiều công ty. Số long đong lận đận. May trong cái rủi, mình gặp nhiều người, làm việc với họ, hiểu họ một chút :) Rốt cuộc, đó chẳng phải là điều rất có giá trị sao? Mỗi người một vẻ, một kiểu, không thể nói ai hơn ai được.

Thế có vẻ trớt quớt, huề vốn nhỉ? Thì đó là chuyện đã qua mà. Còn trước mắt, nếu bạn đang boăn khoăn không biết chọn công ty nào, trên tay có hai, ba cái offer, thì dưới đây là vài mẹo rất hay để bạn loại khỏi vòng chiến những boss / leader tào lao hehe :)

Cuối buổi phỏng vấn, hay vòng cuối, thường bạn sẽ được đề nghị có câu hỏi gì cho công ty. Có một số câu hỏi có thể khiến người đi hỏi bể đầu, ví dụ, tại sao công ty lại tuyển thêm vị trí này?, hay hệ thống của anh (chị) bị sập bao nhiêu lần rồi?. Với câu hỏi cuối, hầu hết các trường hợp là trả lời cho qua chuyện, chẳng ai muốn vạch áo cho người ta xem lưng, nhỉ Nhưng câu hỏi này thật sự giúp bạn biết được bạn đã 101% vượt qua tất cả các vòng gửi xe chưa đấy.

Một câu hỏi khác nghe đơn giản nhưng phản ánh gần như toàn bộ cách làm việc của đội ops. Đó là, anh (chị) có dùng tài khoản **root** để quản lý các máy không. Một nơi toàn root không phải để chỗ cho lính lơ tơ mơ nghịch, hoặc có thể là một hệ thống hoàn toàn mất kiểm soát.

Bạn thử hỏi một câu nhẹ nhàng hơn, liên quan tới luật Murphy. Ví dụ, anh (chị) có cho rằng bộ sao lưu dữ liệu của anh (chị) đã bị hỏng hết không? Câu này sẽ cho bạn biết mức độ quan tâm tới chi tiết trong hệ thống, và một người kỹ tính như bạn sẽ rất phù hợp.

Vài câu hỏi vậy, nhưng đó là chuyện kỹ thuật. Quan trọng là bạn chọn được job để bạn thỏa sức bay cao, bay xa.

(Viết tự an ủi, tự nhiên nhớ Toàn Miami ^.^)



-- 3c9e6580 (Ky-Anh Huynh 2019-03-26 04:27:17 +0700 70) at https://github.com/linuxvn/about/blob/master/Notes-2019.md#boss-interview
🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞

welcome-to-berlin

https://github.com/linuxvn/about/blob/master/Notes-2019.md#welcome-to-berlin


tags: #berlin #relocation #devops #random

Mình viết bài này lâu rồi, nhưng để xó vì dự tính khác; hôm qua thôi, biết có bạn đang chuẩn bị hành lý qua Berlin, nên mình thấy nên viết lại, nhưng theo kiểu khác.

Bạn biết là, mình đi công tác ở đây vài tháng rồi. Xa bạn bè gia đình, xa những ngày nắng nóng hay những lúc mưa buồn của sài gòn. Hay nhớ những quán nhậu, cà phê vỉa hè. Ôi, nhớ nhất là những quán cà phê, chắc không nơi đâu trên thế giới có kiểu như sài gòn vậy =^^

Berlin không đẹp như Paris. Sau thế chiến hai, thành phố bị san phẳng, các tòa nhà ở đây tuổi đời đâu 70 trở lại thôi. Nhưng berlin nhiều cây cối công viên tàu điện và xe đạp (số xe vẫn thua Hà Lan?) Một bạn chỗ mình làm mỗi ngày hai cuốc xe đạp đi về, mỗi chiều 32 km. Tốc độ xoàng xoàng 41km/h. Quá khiếp. Mình từng đi làm với xe đạp ở Sài gòn, 7km hết chừng 1 tiếng, tốc độ rùa khỏi chê.

Ôi lan man thế, cho biết bạn mình cũng có khiếu văng nghệ không thua ai. Còn về kỹ thuật: Berlin khá cởi mở trong việc tuyển người các ngành công nghệ. Nếu có công ty ở đây nhận làm, hầu như bạn sẽ có thể bay qua đây trong hai tháng. Tìm việc khá dễ, bạn vào LinkedIn tìm thôi, nếu bạn chịu bỏ ra 30 đồng ông tơn (usd) thì bạn có nhiều job ngon nữa cơ; mà cũng chả cần mất số đó, tháng đầu LinkedIn cho miễn phí. Bạn cũng sẽ biết mức lương của senior devops engineer ở đây vào khoảng chính (phân phối chuẩn) từ 65k đến 70k euro mỗi năm trước thuế. Chế độ lao động thì tuyệt vời. Mỗi năm có ít nhất 24 ngày phép, chưa kể ngày nghỉ lễ công cộng, chỗ mình làm cho hẳn 29 ngày luôn, tha hồ đi chơi. Sau giờ làm việc thì khỏi ai dám gọi bạn nếu không muốn phạm luật hay trả tiền. Bia Đức tuyệt ngon. Ở Berlin, mại dâm cũng được luật cho phép. Thiên đường thế còn gì =))

Nếu nhận lương chừng 65k/năm, thì bạn còn lại nhiêu? Tiền thuế độc thân đâu khoảng 38 - 40%. Mỗi tháng bạn tiêu cơ bản đâu 300e (mỗi ngày 10e), nếu bạn chịu khó nấu ăn uống. Đắt nhất tiền nhà, tùy bạn muốn ở bao nhiêu, mình phải trả 760e mỗi tháng chưa kể điện nước internet. Nhưng nói chung, con số dư ra chả nhiêu, không thể giàu như mấy ku ở Việt Nam được.

Ở 21 tháng bạn thi bằng B1 tiếng Đức (giống ielts 6), thì được quyền định cư vĩnh viễn. Nếu lười, bạn cứ việc chờ 3 năm, quyền đó tự động có cho bạn. Sau 8 năm, bạn có quyền đổi màu quốc tịch (ôi, chắc mình không ham, nhỉ) Nhưng chưa vội xa vời; chỉ cần có quyền làm việc với Bluecard bạn đã có thể đi khắp châu Âu không bị xách mé rồi. Nhưng nếu bạn ăn thịt heo, thịt chó, thì nhớ nói nhỏ tí, vì niềm tin của người khác sẽ khác bạn nhiều lắm lắm.

Gần đây Úc mới mở ra visa 482 thay cho visa 587 xưa kia dường như chỉ ưu tiên cho du học sinh. Với 482 bạn có thể xin việc dễ dàng hơn ở Úc, chỉ với trình độ ietls tối thiểu 5.5. Mình ghét Úc là vậy, tao đây qua châu Âu sống khỏe re, việc gì phải bỏ tiền ra thi cái bằng chỉ có giá trị hai năm để chỉ chứng minh ta có thể nói tiếng Anh ở Úc?

Còn nhiều thứ lắm; nhưng lời khuyên là trước khi bước chân qua đây, nên nghĩ đến các vấn đề chiến lược lâu dài. Berlin và châu Âu dân số già đi. Người trẻ nuôi người già, nên hàng năm, mức chi trả cho bảo hiểm xã hội giảm dần, hiện nay là 48% và sẽ còn giảm tiếp. Dù luật có cơ chế để hạn chế rủi ro này, bạn cũng nên tính tới. Con gái nhỏ ở đây học ở trường công tiếng Đức, được duy nhất nước Đức nói thôi:) Từ 1/8, con nít được miễn vé tàu điện, ngoài khoản trợ cấp 200e mỗi tháng.

Người Sài gòn ít nhất là dân kỹ thuật giỏi, có thể đi khắp thế giới nhỉ. Chứ bọn tây, ít người qua Việt Nam làm Devops đó. Deal lương hơi khó. Có một số bạn chia sẻ trên kênh https://t.me/g7expat, có khi giúp ích cho bạn khỏi thiệt, không phải để bạn đứng núi này trông núi nọ. Chỗ mình, có các kỹ sư 50 60 tuổi vẫn lập trình PHP hay Java. Quan trọng là hạnh phúc, không phải tiền lương bạn nhé.



-- 349bb6ad (Ky-Anh Huynh 2019-05-26 22:56:11 +0700 39) at https://github.com/linuxvn/about/blob/master/Notes-2019.md#welcome-to-berlin
🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞

murphy-s-law

https://github.com/linuxvn/about/blob/master/Notes-2019.md#murphy-s-law


tags: #devops #strategy #murphy #essential

Trang wiki tóm tắt luật Murphy: "Anything that can go wrong will go wrong". Câu tiếng Anh này ngắn gọn đến nỗi không cần phải dịch, ai cũng hiểu.

Mình không nhớ biết đến luật này tự bao giờ. Nhưng rõ ràng nhiều bạn vẫn chưa biết luật này. Mình không rõ có tài liệu tiếng Việt nào viết về nó. Điều đáng ngạc nhiên là, rất khó để chứng minh cho bạn thông luật này. Dù nó được xác nhận nhiều bởi thực nghiệm, nó là một luật thống kê. 99 phảy với một trăm số chín xếp hàng ngay ngắn theo sau, vẫn không phải 100 (phần trăm).

Mình muốn viết bài về luật này rất lâu. Trong bài trước đây chẳng hạn root-is-rut, đã có nhiều ví dụ. Mình có thể hù bạn, mức độ kinh nghiệm của bạn trong nghề devops đo được bằng mức độ bạn hiểu và áp dụng luật Murphy tới đâu trong hệ thống của bạn =))

Mình kể lại ví dụ mà bạn đã biết trong bài về sao lưu postgresql: Tất cả các khách hàng không sao, chỉ trừ một chú bị trục trặc với kịch bản sao lưu mà đội ops giải gần hai tháng chưa xong triệt để (k8s/stolon.) Từ khi ngay lúc định hướng viết hỗ trợ sao lưu, vấn đề này đã được nêu ra. Nhưng với tất cả các lý do, thiết kế hướng tập trung để né tránh xung đột với ứng dụng bị bỏ qua. Một cách vi phạm luật Murphy rõ ràng :P

Một chuyện hài khác. Ai đi vé tàu không có vé, coi như đi lậu, sẽ bị phạt 60e một lần. Anh bạn cùng chỗ làm kể, anh ta đi 4 năm trời không sao hết. Đúng bữa anh ấy hết vé, lại quên đi nạp tiền, thì bị ngay đội tuần bắt. Mất ngay 60e tiền ngu chứ sao =)) Luật Murphy đây áp dụng chính xác quá luôn haha.

Luật Murphy áp dụng cho hệ thống nfs là nản lòng nhất. Các hệ thống nfs phụ thuộc vào hạ tầng mạng, thường nằm tách biệt với các tầng ứng dụng phía trên. Năm 2013, mình nhớ cty cũ bị lỗi liên quan nfs, cả đội ngoác mõm ra chờ mấy tiếng đồng hồ. Còn mới đây thôi, hôm sáng thứ hai đầu tuần, đội Noc ngồi nâng cấp core switch, dù có đầy đủ backup, failover, nhưng một chú switch nào đó hỏng đơ phải reboot lại, thế là tạch luôn cả bọn, tạch luôn hệ thống nfs. Cả một hệ thống đâu mấy chục máy và dịch vụ phải khởi động lại, mất hai ngày mới xong hết các lỗi, nhưng các hệ quả vẫn còn lại -- xem random-notes-1.

Luật này cũng liên quan tới phép quy nạp không hoàn toàn, xem đây: https://icy.theslinux.org/m/kyanh.net/2016/03/22/sau-1-2-3-4-5-6-se-la-gi/index.html Trong ngành ngân hàng hay ở mức quản lý cao cấp, có chuyện risk management. Trong cuộc sống có ngành bảo hiểm. Áp dụng cực đoan luật Murphy, bạn sẽ thấy chỉ còn một thứ có thể cứu vãn, niềm tin và sự may mắn của bạn :)

Nếu để ý tới luật Murphy, rất nhiều bài toán Ops sẽ được sáng tỏ :)



-- 87d3e54c (Ky-Anh Huynh 2019-05-27 03:16:02 +0700 40) at https://github.com/linuxvn/about/blob/master/Notes-2019.md#murphy-s-law
🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞

welcome-to-berlin-2

https://github.com/linuxvn/about/blob/master/Notes-2019.md#welcome-to-berlin-2


tags: #berlin #relocation #devops #random

Mình chính thức thông báo, mình đã chuyển qua làm việc lâu dài tại Berlin. Mình chuẩn bị khá lâu nhưng lúc đi thì cái vù, chỉ vài người biết. Một phần vì các thủ tục giấy tờ ở đây phức tạp, có thể tuyển thẳng mình về Saigon bất kỳ lúc nào nên mình không dám hó hé, sợ quê.

Berlin năng động, không như kiểu Sài gòn hay Singapore. Nhiều bạn cũng sắp qua đây, hỏi tùm lum thứ. Nên mình viết sơ vài ý quan trọng để bạn lên kế hoạch. Người Đức thích và giỏi lập kế hoạch, nên đầu tiên bạn cần luyện kỹ năng đó. Việc gì tới sẽ phải tới, vậy thôi.

1. Xin việc: Bạn apply qua LinkedIn, nên đăng ký một tài khoản Premium miễn phí tháng đầu, 30 Mỹ kim mỗi tháng kế tiếp (nếu vẫn xài) Trên đó, có khóa học Get things done cực hay, bạn nên xem qua nhé. Khi xin việc, cần hết sức chú ý hỏi về môi trường và phong cách làm việc. Càng cởi mở càng tốt; vì người Đức nổi tiếng kỷ luật mà. Ví dụ, bạn nên hỏi tao muốn làm ở nhà được không;)

2. Mức lương: Khó mà giàu ở đây. Muốn giàu, bạn đi Singapore hay Mỹ nhé. Còn để cân bằng sống và làm việc chả theo giương ai hết, Berlin là nơi khá tốt cho bạn đấy. Mức lương của mình thì bạn có thể hỏi riêng, nhưng bạn nên biết điểm khởi đầu của mình để khỏi tự bắn vào chân nhé.

3. Bằng cấp: Bạn nên có một bằng đại học được Đức công nhận. Mình may mắn có bằng mát-tơ ở Việt nam, trường đại học mình được công nhận, nhưng bằng của mình thuộc dạng dỏm, phải gửi qua Đức cho họ kiểm tra, ký giấy công nhận. Mất ít phí. Nhưng kết quả là tờ giấy còn đẹp hơn cả cái bằng gốc của mình hehe.

4. Thủ tục visa: Hơi khó, bạn xin visa làm việc (bluecard), nhưng lãnh sự quán Đức ở Sài gòn cấp visa ngắn hạn 3 tháng để bạn qua Đức xin tiếp visa dài hạn. Việc khó đầu tiên là đặt lịch hẹn làm thủ tục visa, thường việc này phải tiến hành trước vài tháng, trước cả khi bạn có offer từ các công ty đấy. Bạn sẽ phải gửi email để hỏi (xem trên https://vietnam.diplo.de/), còn trước đây mình canh mãi mới được, và lịch hẹn của mình có sau thời gian bắt đầu hợp đồng đến mấy tháng. Công ty có thể có visa agent hỗ trợ, nhưng bạn nên chủ động tìm hiểu hoàn chỉnh giấy tờ, thủ tục, đặt lịch hẹn,... nhé. Và quan trọng là thông báo đầy đủ tình trạng cho công ty để họ biết mà hỗ trợ hoặc ... chờ bạn onboard.

5. Qua tới Đức: Do bạn ở lâu hơn 2 tuần, bạn sẽ phải làm thủ tục đăng ký chỗ ở (Anmeldung). Việc này dễ, làm trong 10 phút là xong, nhưng oái ăm là bạn phải có một địa chỉ ổn định để bạn có thể nhận giấy tờ (rất nhiều) và làm các thủ tục tiếp theo (mở tài khoản ngân hàng, bảo hiểm, thuê nhà, ...) Bạn có thể ở tạm Airbnb và nhờ ai quen cho/thuê mượn địa chỉ đăng ký.

Không phải chỗ ở Airbnb nào cũng cho bạn giấy Wohnungsgeberbestätigung, mà có cho thì cũng phập phù khi bạn chuyển đi nơi khác (nhưng hay cái là bạn có thể đăng ký dịch vụ bưu điện tự động chuyển thư của bạn qua địa chỉ mới; cái này còn xịn hơn routing bằng iptables nhé.)

Thuê nhà ở Berlin khó hơn mua nhà ở quận 7 sài gòn, một phần vì quá đông người thuê, và phần chủ yếu là bạn mới qua đây, chưa ai biết bạn là ai, thu nhập thế nào: Một khi đã thuê nhà ở, chủ nhà rất khó có lý do để đuổi bạn đi, nên nhiều chủ nhà hỏi bảng lương của bạn trong vòng mấy tháng cuối thì mới cho thuê nhà đấy (nên nhớ, chính công ty bạn sắp xin vào cũng không dám hỏi bảng lương của bạn nhé.) Nhưng có nhà rồi, coi như khỏe re rè re luôn. Mình thuê nhà 65 mét vuông, hai phòng, hết khoảng 760e mỗi tháng.

Còn nhiều nữa, mình sẽ không tiếp tục viết bài mới mà sẽ chỉ cập nhật trong bài này. Chúc bạn may mắn.



-- 1f7403ea (Ky-Anh Huynh 2019-06-17 03:26:11 +0700 42) at https://github.com/linuxvn/about/blob/master/Notes-2019.md#welcome-to-berlin-2
🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞

git-revert-to-a-good-commit

https://github.com/linuxvn/about/blob/master/Notes-2019.md#git-revert-to-a-good-commit


tags: #git #devops #trick #diff

Hôm nay trên @linuxvn (https://t.me/linuxvn/55674) có bạn hỏi làm thế nào để quay lại một commit cũ/tốt trên master, sau khi lỡ nhầm merge nhánh dev vào nhánh master. Sau câu hỏi này là một màn tranh luận sôi nổi, dài lê thê mà mình chưa kịp coi. Người hỏi muốn reset, bỏ đi các commit lỗi để quay lại cái cũ, một kiểu Undo giống khi soạn thảo văn bản.

Vấn đề này hay gặp, bạn có thể xem trao đổi trên SO: https://stackoverflow.com/questions/4114095/how-do-i-revert-a-git-repository-to-a-previous-commit tất nhiên là trên đó cũng miên man đủ thứ giải pháp, mà thật ra mình coi nhiều lần vẫn không hiểu thế nào là tốt, hoặc là cũng chả cần hiểu nhắm mắt làm theo.

Sau đây, mình giới thiệu cho bạn cách truyền thống, cực kỳ chính xác.

Thứ nhất, sau khi commit, đã merge, thì bạn không nên Undo, xóa bỏ commit bằng git reset, một khi thay đổi đã được push lên kho hay chỗ nào đó. Lời nói gió bay, chỉ có thể sửa chữa chứ không rút lại được. Trong DevOps cũng có vài nguyên tắc sống hay vậy.

Tiếp theo, về cơ bản, giữa hai commit bất kỳ trong kho git của bạn là một khoảng cách khác biệt, mà bạn luôn thấy được bằng lệnh git diff. Phục hồi commit cũ, tức là xóa đi các khác biệt này, hay là áp dụng khác biệt đó theo chiều ngược (bạn sẽ rõ hơn ở phần sau).

Giả sử, bạn đang ở master và cần quay lại commit 3323e5b tốt. Hãy chuẩn bị bước đầu tiên là clone/checkout nhánh master ra một thư mục sạch sẽ, là thư mục mà khi bạn gõ git status -u thì không thấy gì ở đó.

$ git status -u           # đảm bảo không thấy gì
$ git checkout master     # chắc chắn bạn đang ở master
$ git diff HEAD..3323e5b  > patch.diff

Trong lệnh cuối cùng, thứ tự rất quan trọng. Commit tốt của bạn phải nằm sau cùng (đi ngược về quá khứ). Sau đó, bạn áp dụng bản diff này

$ patch -p1 < patch.diff
$ git status -u

Kiểm tra lại xem các file nào mới chưa được commit trong kết quả của lệnh git status -u ở trên. Nếu có, bạn thêm vào: đó là các tập tin có trong commit cũ (3323e5b):

$ git add some/new/files.txt
$ git commit -a "Revert to 3323e5b, thanks to @linuxvn"

Để chắc chắn, bạn kiểm tra lại kết quả

$ git diff 3323e5b..

lần này cần phải hiện ra ... không gì cả, tức là bạn đã hoàn toàn phục hồi lại commit cũ của bạn.

Cách này lúc nào cũng thành công, đơn giản, thậm chí bạn có thể tranh thủ điều chỉnh vài thứ. Và hơn hết, thay vì phải đi hiểu một đống lệnh như là git revert, git reset, ...bạn chỉ việc tập trung hiểu bản chất của vấn đề là, diff, diff, và diff ;)



-- 03607e98 (aiyo8aiK 2019-08-08 17:46:01 +0200 45) at https://github.com/linuxvn/about/blob/master/Notes-2019.md#git-revert-to-a-good-commit
🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞