root-is-rut https://github.com/linuxvn/about/blob/master/Notes-2019.md#root-is-rut
tags: #root #shell #linux #rut
Nhiều chỗ phải xài
root shell, không né được. Không phải do công ty to nhỏ gì, không phải sản phẩm tốt xấu gì. Chẳng qua... xài root thì quá tiện, giống đi xe máy ở Sài Gòn vậy, chỗ nào cũng tới được. Ông ops/admin trước lười thì ông sau lãnh đủ, vậy thôi. Phần dưới nêu vài chuyện vui khi nghịch với lửa đây.
1.
hostname -f nhầm thành hostname f: Một số bàn phím trời đánh, nhả phím không được, nên sau lệnh hostname f thì toi, bạn phải đi lục tung history lên coi hostname cũ thế nào mà phục hồi lại. 2.
copy-&-paste: thế kỷ 21 rồi nhỉ, nhưng copy một chỗ rồi paste ra chỗ khác không phải lúc nào cũng đúng ý đâu nhe :) Cẩn thận nhất, trước khi dán vào terminal/shell, bạn thử dán ra chỗ nào đó trước. Không thì lâu lâu gà gà gật gật là y như rằng một mớ thứ nhảy múa trong terminal. Bạn thử chép nội dung log sau vào dán vào terminal xem: https://gist.github.com/icy/d8d2598acc31523317b93547d35bb304 :) 3.
shutdown nhầm: thôi khỏi cần nói gì thêm nhe, mất công haha 4. Mất
/dev/zero hay /dev/null hay /dev/log: Nghe buồn cười nhưng chuyện kỳ dị này cũng có thể xảy ra: Ví dụ nè https://icy.theslinux.org/m/kyanh.net/2015/06/06/the-slig-returns/index.html#slig29. Vấn đề là nhiều khi khó nhận biết cho tới khi .. khá trễ. Khi mất /dev/null thì bạn vẫn xài nó khá bình thường, ví dụ cat foo > /dev/null, cho tới khi... đĩa đầy chẳng hạn. 5.
Lock down: hihi, sudo có cú pháp trời đánh để nạp cấu hình bên ngoài, ví dụ #includedir /etc/sudoers.d. Nhiều bạn gà gà gật gật cho mình là siêu nhân, chỉnh lại cho đúng includedir /etc/sudoers.d, xong đi uống cà phê, ăn trưa rồi tắt server mount lên chỗ khác fix lại. 6.
/etc/nginx/sites-enabled/:wq: Ơ, bạn đoán ra cái gì đây không? Là do một chuyên gia vi/vim xài nano. Thiệt tình là sau khi lưu file đó xuống đĩa rồi thì anh em đi fix cả ngày không biết tại sao cấu hình mới không ăn =)) Lưu ý nhỏ nhẹ cuối cùng,
nohup luôn là biên giới trong cuộc chiến giữa dev và admin. Lần nào đĩa đầy là admin phải lọ mọ vào xài lsof soi lên nohup nằm ở đâu (file đó cũng hay bị xóa cho gọn đĩa ấy mà.) Tạm dừng ở đây, khi nào nhớ ra viết tiếp.
-- 0ce76975 (Ky-Anh Huynh 2019-04-24 04:41:54 +0700 31) at https://github.com/linuxvn/about/blob/master/Notes-2019.md#root-is-rut
🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞
nmap-for-prometheus https://github.com/linuxvn/about/blob/master/Notes-2019.md#nmap-for-prometheus
tags: #prometheus #nmap #network #scanning #lua
Mình có vài trăm hosts cần quét nhanh để lấy danh sách
target cho Prometheus. Script hiện có chạy tuần tự, dùng curl để kiểm tra, ví dụ http://foo:9100/metrics, có trả về mã 200 hay không; toàn bộ script chạy gần 2h mới xong. Dùng nmap chắc chắn nhanh hơn:
$ _ports="9100,9168,9200,9400,"
$ nmap \
>/dev/null \
-iL "hosts" \
-p "$_ports" \
-oN "_discovery.tmp" \
--script +"http-headers.nse" \
--script-args \
"http-headers.path='/metrics', http-headers.useget='true'"
trong đó,
hosts là file liệt kê tất cả các hosts cần quét, và _ports lưu danh sách tất cả các port (dư ra dấu phảy ở cuối không quan trọng lắm; khi bạn tạo danh sách các port bằng bash thì dễ dư ra như vậy đó.) Chỗ
+http-headers.nse có dấu cộng đằng trước. Cái này mình mất chút thời gian để hiểu tại sao. Kịch bản http-headers đi kèm với bộ cài đặt của nmap, không phải lo lắng tải ở chỗ khác. Kết quả dò lưu vào tập tin _discovery.tmp như sau # Nmap 7.70 scan initiated ...
Nmap scan report for k8s-001.lauxanh.net (10.0.0.2)
Host is up (0.0069s latency).
Not shown: 31 closed ports
PORT STATE SERVICE
9100/tcp open jetdirect
| http-headers:
| Content-Length: 143114
| Content-Type: text/plain; version=0.0.4
| Date: Tue, 30 Apr 2019 14:44:54 GMT
| Connection: close
|
|_ (Request type: GET)
Việc còn lại là làm sao đọc ra danh sách cách target từ
_discovery.tmp? Việc này không hề đơn giản, chưa kể kết quả của nmap chỉ cho biết cổng mở mà không biết thực sự exporter có trả về 200 hay không. Làm sao đây? Điều chỉnh trực tiếp kịch bản http-headers.nse (/usr/share/nmap/scripts/http-headers.nse), ví dụ https://gist.github.com/icy/191de6e6a30e7ac8f8068d288264d51a/revisions#diff-8a0ced239ddcc2ee44a526a3e5fd8163 sau đó chạy $ sudo nmap --script-updatedb
$ nmap ...
$ grep service/200 _discovery.tmp
|_ service/200: k8s-001.lauxanh.net:9100/metrics
|_ service/200: k8s-002.lauxanh.net:9100/metrics
# ...
Tuyệt vời ông mặt trời. Điều đáng buồn là mình viết vầy cho bạn xài, còn mình vì một lý do thiên địa trời đánh, không xài được những gì viết trên đây cho hệ thống thật sự. Khi nào uống cà phê kể sau ha.
Cuối cùng,
curl đọc là si du a eo (see-url) nhe các bạn. Nếu bạn biết tác giả của curl nói điều này ở đâu thì cho mình xin cái link. Cảm ơn bạn nhiều. -- 897a75b1 (Ky-Anh Huynh 2019-05-03 08:47:48 +0700 32) at https://github.com/linuxvn/about/blob/master/Notes-2019.md#nmap-for-prometheus
🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞
hdfs-metadata-backup https://github.com/linuxvn/about/blob/master/Notes-2019.md#hdfs-metadata-backup
tags: #hadoop #metadata #backup
Hệ thống
tập tin của Hadoop, gồm hai phần cơ bản là datanode và namenode. Như con trỏ trong lập trình C, namenode là về địa chỉ (metadata), còn datanode là về nội dung con trỏ lưu trữ. Hệ thống có hai
namenode chẳng hạn, thì chỉ có một active thôi, còn lại ở chế độ chờ standby; chuyện gì xảy ra nếu cả hai cùng sập? Không địa chỉ đồng nghĩa với lạc đường, bạn chỉ còn nước format và nạp lại hệ thống hdfs hoàn toàn mới. Sao lưu sao lưu sao lưu. Các hướng dẫn trên mạng đầy ra, bạn cứ thử gõ
hdfs metadata backup rồi làm theo, đại ý: $ hdfs dfsadmin -fetchImage backup_dir
Đọc theo làm theo, y chang vậy, thì rắc rối bắt đầu. Thật sự chỗ
backup_dir, phải thỏa mãn điều kiện tiên quyết: Đó là một thư mục đã tồn tại. Nghĩa là, lệnh chính xác phải như sau $ mkdir -pv backup_dir/
$ hdfs dfsadmin -fetchImage backup_dir/
Kết quả là các tập tin
fsimage_* được tạo ra trong backup_dir/. Nội dung giống như trong thư mục, ví dụ, /home/hdfs/data/nn/current/*, tùy vào cấu hình của bạn, là nơi lưu trữ metadata của hdfs đang chạy. Một số tài liệu chỉ nói đơn giản là bạn chép nguyên cục đó ra $ tar cfvz my_nn_backup.tgz /home/hdfs/data/nn/current/
Tại sao có hai cách, kết quả khác nhau thế nào? Có vẻ như việc dùng lệnh
hdfs dfsadmin trông sang chảnh và hợp lý hơn. Đúng thế, cho tới khi bạn phải phục hồi hệ thống thật sự. Trời đất, các tài liệu mình tìm được đều nói tới việc chép lại các tập tin ảnh đó ra thôi. Thế nên mình thử # giả sử không có namenode nào đang chạy
# giả lập nhờ systemctl stop hadoop-* trên tất cả các namenode
# nn chính là viết tắt của namenode
$ rm -rf /home/hdfs/data/{nn,snn}/current/
$ mkdir -pv /home/hdfs/data/{nn,snn}/current/
$ cp /backup/fsimage_* /home/hdfs/data/nn/current/
$ systemctl start hadoop-namdenode
# tạch toàn tập, không lên nổi. Viagra bó tay.
Tới đây bạn sẽ gần như tuyệt vọng. Hệ thống báo là
namenode chưa được format. Nếu chọn format mới hdfs namenode -format đồng nghĩa với việc xóa sạch cài lại cluster mới (FIXME), đó không phải là phục hồi từ bộ sao lưu. Nào google tìm, thật may bạn thấy bài viết này, bởi vì có thể tất cả các bài trước đây đều thiếu hai điều rất quan trọng như sau:
1. Bạn phải backup
/home/hdfs/data/nn/current/VERSION 2. Bạn phải tạo checksum cho từng tập tin
fsimage_* Hai việc này không hề có khi dùng
hdfs dfsadmin -fetchImage ... $ cd /home/hdfs/data/nn/current/
$ cp /backup/fsimage_* ./
$ cp /backup/VERSION ./
$ for _file in fsimage_*; do md5sum $_file > $_file.md5; done
Rốt cuộc, mình chả hiểu lệnh với
-fetchImage để làm gì nữa luôn: nó tạo ra ảo tưởng rằng mọi thứ đã sẵn sàng cho trường hợp tệ nhất, nhưng thực ra, cách đơn giản phải làm chính là cách thứ hai tar cfvz my_nn_backup.tgz /home/hdfs/data/nn/current/. Tập tin
VERSION là gì, tại sao nó quan trọng? Từ từ, việc cần làm trước là thử phục hồi từ bộ backup bạn đang có. You will never know if you don't go -- một câu trong bài hát phim hoạt hình Shrek. Sau đó, đọc thêm: https://hortonworks.com/blog/hdfs-metadata-directories-explained/
-- 1c954e4b (Ky-Anh Huynh 2019-05-09 04:48:08 +0700 34) at https://github.com/linuxvn/about/blob/master/Notes-2019.md#hdfs-metadata-backup
🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞
postgresql-file-system-level-backup https://github.com/linuxvn/about/blob/master/Notes-2019.md#postgresql-file-system-level-backup
tags: #database #pgsql #backup #snapshot #googlecloud
Hệ thống mình phục vụ khá nhiều khách hàng; mỗi triển khai (deployment) gồm nhiều loại database khác nhau, chạy trên
k8s. Các kịch bản sao lưu chạy tốt cho tất cả triển khai, ngoại trừ một khách hàng A có dữ liệu khá lớn và tăng liên tục, trên postgresql. Do một quyết định thiết kế cũ mà triển khai dựa trên Stolon (https://github.com/sorintlab/stolon), nhưng hỡi ôi, nhiều thứ Stolon còn chưa sẵn sàng, ví dụ không hỗ trợ rsync https://github.com/sorintlab/stolon/issues/389. Trong hệ thống của A, khi kịch bản sao lưu chạy thì ứng dụng ngất ngư. Về bản chất, kịch bản sao lưu dùng
pg_basebackup, dựa trên streaming protocol của pgsql; không có nhiều tùy chọn khi dùng công cụ đó, kể cả việc nén khi gửi dữ liệu giữa các máy. Các kiểu sao lưu khác, xem thêm tại https://www.postgresql.org/docs/9.1/backup-file.html: 1. Dump dump dumb...
2. Dùng
rsync để gửi bin/WAL log ra chỗ khác (đây là một trong hai cách mà công cụ như barman hỗ trợ) 3. Dùng
file-system backup (sao lưu nguyên cục /var/lib/psql/data/) Dùng
pgsql trong k8s nghe phát mệt; quá tuyệt vọng với sự phức tạp của các phương án khác, mình đã thử phương án đơn giản nhất, là lấy snapshot của đĩa slave trong Stolon cluster. Trong lòng đầy nghi hoặc, bởi đảm bảo cho snapshot này tốt, dữ liệu có thể phục hồi được nghe nó xa vời quá. Xưa giờ, chưa bao giờ mình tin vào việc lấy snapshot của đĩa chạy database; thế nên, mình đã thiết kế kịch bản rất kỹ như sau: 1. Xác định chính xác pod
slave trong Stolon cluster. (Tóm tắt cho bạn chưa biết, Stolon nó bật một node master, vài node slave, và nó có cơ chế hoán đổi tự động;) 2. Lấy đúng đĩa ứng với
pvc (persistent volume claim) đang dùng bởi pod đó. 3. Tạo snapshot từ đĩa trên, tạo một đĩa mới cùng kích thước,
4. Sau đó, kết nối đĩa mới tạo ra vào một máy tạm thời trên GCE, dùng một docker image được chỉnh riêng để kiểm tra đĩa này. Docker container được tạo ra gồm một tiến trình cho để chạy
postgres, một tiến trình khác theo dõi log sinh ra từ postgres. 5. Sau khi xác định điểm lỗi hay điểm dừng, toàn bộ đĩa và máy tạm thời được xóa đi, và gửi thông báo tới các kênh theo dõi.
Kết quả rất bất ngờ như sau:
1. Việc tạo snapshot rất nhanh. Nếu tạo mới hoàn toàn (base), mất khoảng 10 phút. Các snapshot sau đó còn nhanh hơn nữa, do nó chỉ phải gồm các thay đổi so với bản snapshot trước đó. Tất cả các snapshot đều được
nén, nên kích thước nhỏ đáng kinh ngạc (mặc dù cũng xem xem kết quả nén khi dùng pg_basebackup) 2. Khi chạy
postgres kiểm tra, do dữ liệu gốc ở pod slave, nên xuất hiện tập tin recover.conf trong thư mục /var/lib/pgsql/data/, cần phải xóa đi. Sau đó, postgres tự phục hồi lại dựa theo thông tin binary cuối cùng đang có, có thể bỏ qua WAL log cuối cùng. (Thực ra, bộ snapshot hầu như không có thêm WAL log nào ghi kèm, do mình chưa bật.) 3. Việc chạy phục hồi (restore) thử chưa gặp trường hợp nào lỗi; và cũng khá nhanh, mất khoảng dưới 20 phút, trong đó, thời gian chủ yếu ở chỗ tạo snapshot mới, và tạo đĩa mới từ snapshot đang có.
So với việc tốn hơn 6 tiếng đồng hồ khi dùng
pg_basebackup, thì việc dùng snapshot của google cloud quá đơn giản, ổn định, nhanh nữa, và muốn PITR thì chỉ việc tạo snapshot thường xuyên hơn. Tất nhiên, điều mình trông đợi nhất, là phương án này bị lỗi, bị sai một lúc nào đó. Bởi khi đó mới có chuyện để viết tiếp à.
-- c39d5bf7 (Ky-Anh Huynh 2019-05-11 00:54:01 +0700 37) at https://github.com/linuxvn/about/blob/master/Notes-2019.md#postgresql-file-system-level-backup
🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞
random-notes-1 https://github.com/linuxvn/about/blob/master/Notes-2019.md#random-notes-1
tags: #notes #random #retrospective #puppet #salt #ansible
Bữa có mẹo dùng
nmap, giờ mình ghi lại kết quả để so sánh. Kịch bản cũ dò hơn 450 host, mỗi máy dò 33 cổng, thời gian mất từ 1h đến 2h mới xong. Kịch bản nmap mất dưới 1 phút, tìm ra khoảng 730 target cho Prometheus. Trong ghi chú trước về sao lưu
postgresql, cách dùng disk snapshot vẫn ổn chưa gặp sai sót gì; việc sao lưu vào lúc khoảng 5h chiều (gmt+2). Có thể giải thích là do database hoạt động ít quá, mỗi ngày tăng trung bình 1gb - 5gb theo mình nhớ. Còn team vẫn loay hoay đủ cách để chạy pg_basebackup; dùng stolon lại thêm k8s thiệt khổ đời. Cách hai của việc sao lưu
postgresql, là dùng rsync. Cách này yêu cầu phải tắt dịch vụ postgresql như đề cập trong tài liệu của chính thức, với các ghi chú về hạn chế, điều kiện và biến thể. Tuy nhiên, nếu từng triển khai barman, sẽ thấy barman dùng rsync thôi, không cần tắt dịch vụ gì trước đó. Như thế tốt quá. Nhưng phải đọc mã nguồn của barman (viết bằng Python) mới hiểu được cặn kỹ. Ai rảnh không? Hôm qua mình chạy
dry-run cho một thay đổi nhờ salt xong, rồi chạy thiệt. Hệ thống production tạch luôn, báo động ầm ầm: Lúc thử thì bình thường, lúc apply thiệt thì có thêm thay đổi do một bạn khác, làm việc khác, broadcast các thay đổi về nfs. Bị cho lên trụ điện nhưng may mình có log làm bằng chứng, nên leo xuống được ngay. Hú hồn. Chuyện gì cũng có thể xảy ra, anh em cứ thi nhau đẩy hàng vào master, test một chỗ apply chỗ khác, im im làm không thông báo ai, thì có ngày bắn vào chân mình thôi. puppet, salt, ansible... bạn chọn cái nào? Ví dụ vừa rồi giúp bạn hiểu, hãy chọn cách mà bạn có thể làm đúng đắn nhất. Một số tình huống có tính chiến lược thì mình không bàn tới. Trong hệ thống của mình có hơn 450 host, một nửa quản lý bằng salt, nửa còn lại bằng puppet:) Nên để cho tiện, mình bí mật dùng ansible trị cả hai :)) -- 4c34c754 (Ky-Anh Huynh 2019-05-26 21:16:31 +0700 38) at https://github.com/linuxvn/about/blob/master/Notes-2019.md#random-notes-1
🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞
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-back-stk-and-huy https://github.com/linuxvn/about/blob/master/Notes-2019.md#welcome-back-stk-and-huy
tags: #linux #vn #saigonlug
ArchLinuxVn chào mừng sự trở lại của các bạn An stk và Huy-Ngo trên nhóm telegram @linuxvn. Sau thế chiến thứ ba, các bạn đã lưu lạc quá lâu, đi làm kinh tế ở đâu không biết nhưng lúc trở lại đã tăng gấp đôi băng thông cho hệ thống mirror (f.archlinuxvn.org) là điều thật đáng trân trọng. ArchLinuxVn chỉ còn là cái tên từ hồi xưa. Nhiều bạn giờ nâng cấp lên phiên bản MacOS của ArchLinux. Giờ ngồi với nhau người ta không hỏi Linux là gì, mà hỏi Docker là gì, rồi k8s là gì.... Kể ra, không phải vì ai cũng đã hiểu Linux, chẳng qua Linux không còn phải là cách dễ kiếm cơn như ngày xưa nữa. Sự trở lại của An stk và Huy Ngo còn được đánh dấu bởi việc phiên bản kế tiếp của MacOS chuyển qua shell mặc định trên hệ thống là
zsh, thay vì Bash-3. Mình đã gặp rất nhiều trục trặc khi hỗ trợ cho người dùng Bash trên máy MacOS, giờ chắc đau đầu hơn. Nhưng thật sự GPL có vấn đề với bọn nhà giàu. Biết sao, buồn một phút. Cảm ơn các bạn An stk và Huy Ngô.
-- 6ea273a4 (Ky-Anh Huynh 2019-06-17 02:36:17 +0700 41) at https://github.com/linuxvn/about/blob/master/Notes-2019.md#welcome-back-stk-and-huy
🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞
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
🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞
random-notes-2 https://github.com/linuxvn/about/blob/master/Notes-2019.md#random-notes-2
tags: #notes #random #retrospective #linuxvn
Hôm nay là ngày đen tối, buồn quá nên ngồi kể linh tinh chuyện. Chuyện như thế này https://t.me/linuxvn/51920, không phải là chuyện buồn, đó là chuyện ... cay đắng. Buồn bực là một cách bộ não đang tự cải tiến, nên thật ra đó cũng là điều may mắn. Đành tự an ủi, lâu lắm rồi ngày xưa là do lỗi mình, nhưng lần này cũng lỗi cho mình nốt.
Nhóm Telegram @linuxvn đâu có 400 nick tụ tập rồi. Admin có Kỳ Anh, Đức, Quang, Nhâm, Vũ Nhân, (và DuyDo) cũng không phải làm gì phức tạp, trừ Đức dành nhiều thời gian cho mirror. Hy vọng sang năm số Admin lên được 300. Một số thành viên siêu nhân mới xuất hiện gần đây, là điều rất đáng yêu. Còn vài điều hấp dẫn nữa, kể dịp khác. Cảm ơn tất cả các bạn đã tham gia vào nhóm.
Có kênh đăng tin công việc https://t.me/devopsjobs nhưng do mình không còn liên lạc với thị trường trong nước, mình nghĩ bạn nào đó có thể phụ trách giúp. Xin hãy liên lạc trên nhóm @linuxvn.
Thang-Man có hỏi https://t.me/linuxvn/50223 và các bạn chú ý https://t.me/linuxvn/50228. Gần tuần nay đội BI+ops chỗ mình đi cài Sqoop mãi không xong, mới thấy giá trị của AWS EMR thế nào :)
Trước đó thì cả tuần mình ướt mồ hôi trán với uwsgi+python nằm sau Apache. Các worker sau khi reload sẽ khiến phát sinh lỗi 500 trên Apache. Sau khi phát hiện ra phải bật thread lên (https://t.me/linuxvn/51063), thì vẫn còn lỗi 500, mà mình đoán là do Apache bị mất kết nối tới socket của uwsgi. Thôi mệt, mình đi nuôi con chó giữ nhà (watchdog), đọc apache log (dùng
tail -F, với F viết hoa, không phải thường nhé), phát hiện thấy lỗi 500 là lập tức restart apache worker (apache2ctl -k graceful); thế là ngủ ngon, lỗi 500 vẫn đầy nhưng hầu như không ai phát hiện ra, trừ mình. Sau khi được chào mừng thì Huy-Ngo và An-stk lặn mất tăm. Điều đáng tiếc là Huy-Ngo bận rộn nên không chăm sóc cho mirror được nữa. Có bạn nào có thể giúp audit mirror xin giơ một tay.
Bạn nào dùng proxy trước k8s để ý tới haproxy+SNI và chủ đề này https://t.me/linuxvn/50112 (https://t.me/linuxvn/50117). haproxy quả thật thú vị và đơn giản hơn nginx ;)
Sau 8 năm mua máy ảnh (và chụp ảnh, tất nhiên :D) mình mới phát hiện ra mình thích chụp cái gì. Sau cũng hơn chừng đó năm làm admin+devops, tóm lại là mình vẫn không hiểu mình thích được cái gì. Thiệt là điên, nhỉ ;)
-- 20cf83d4 (Ky-Anh Huynh 2019-07-24 04:06:42 +0700 43) at https://github.com/linuxvn/about/blob/master/Notes-2019.md#random-notes-2
🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞
theslinuxcom-dynamic-dns https://github.com/linuxvn/about/blob/master/Notes-2019.md#theslinuxcom-dynamic-dns
tags: #dns #bot #theslinux
Ngắn gọn: Bạn có thể có tên miền con ở theslinux.com với hỗ trợ dynamic dns. Ví dụ, foobar.theslinux.com với địa chỉ IP internet nhà bạn.
Để bắt đầu, bạn trò chuyện với bot foor3_bot. Tài khoản Telegram của bạn phải có nickname, và bạn là thành viên của @linuxvn. Bắt đầu với lệnh sau
1.
/dns help : luôn có kết quả; 2. /dns help full : chỉ có kết quả chi tiết hơn. Nếu ở lệnh
/dns help full bạn thấy ngắn, tức là nick của bạn chưa được xác nhận, hãy nhờ bạn Đức hoặc Anh trên @linuxvn. Sau đó, bạn tạo một gist bí mật (hay công cộng tùy bạn), như ví dụ sau https://gist.github.com/icy/b3c600d2bec2994c429f2bbe09a4267d. Rồi gõ lệnh push:
/dns push https://gist.github.com/icy/b3c600d2bec2994c429f2bbe09a4267d
và ngồi chờ vài phút. Dùng
/dns get hay /dns log để xem thông tin mà hệ thống xử lý thông tin của bạn. Để dùng
dynamic dns, bạn chỉ việc dùng git clone, cập nhật và push liên tục lên Github thôi: $ git clone https://gist.github.com/icy/b3c600d2bec2994c429f2bbe09a4267d mydns
$ cd mydns # edit...
$ git push
Mã nguồn sẽ được tải về tự động. Tất cả các tập tin trong mã nguồn của bạn được duyệt qua, nên bạn có thể đặt tên sao cho dễ nhớ.
Nào cùng nghịch thôi.
-- 63911449 (Ky-Anh Huynh 2019-07-27 15:51:58 +0700 44) at https://github.com/linuxvn/about/blob/master/Notes-2019.md#theslinuxcom-dynamic-dns
🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞
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
🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞
pair-debugging https://github.com/linuxvn/about/blob/master/Notes-2019.md#pair-debugging
tags: #pair #debugging #problem #solving #hdfs
Chắc các bạn đã nghe về
pair programming, phương pháp phổ biến từ lâu; chậm nhất đâu khoảng 2007, vì lúc đó mình được biết một job yêu cầu PP với RoR. Hôm nay mình giới thiệu với các bạn về
PD, hay pair debugging. Có thể bạn đã đọc đâu đó trong sách vở và/hay từ các blogger lập trình viên nổi tiếng. Còn mình kể lại chuyện thực tế thôi ha, có gì cứ coi như mình là kẻ thất học vậy. Hệ thống
big data chỗ mình bị đầy đĩa. Trong đó nào là kafka, nào là hdfs, nào là yarn manager tá lả thứ. Sau khi đĩa mới được thêm vào, đảm bảo cấu hình được chỉnh rồi các tiến trình được khởi động lại theo đúng bài vở, thì hệ thống vẫn báo là một trong 5 node của cluster rớt ra ngoài. Thế là mình ngồi mò tìm mãi chẳng hiểu sao. Thực ra mình cũng không phát hiện ra lỗi như vậy, công việc của mình đã xong như vừa nói. Một bạn data engineer tò mò ngồi xem trên Grafana rồi báo lại. Mình cực chẳng đã phải kiểm tra, thấy
hdfs báo ngon lành hết, xanh lè. Mà sao bạn data engineer cứ thắc mắc. Một hồi chát có vẻ không hiểu nhau nên thôi cả hai quyết định dọn về gần nhau cho tiện. Hai cái ghế, một màn hình, một bàn phím, một console, tình anh em đồng nghiệp nào mình cùng thực hiện PD hay là pair debugging. Do mình còn lơ tơ mơ về
PD và cả big data platform, nên mình quyết định theo phương án là bạn engineer có ý tưởng gì là hai bên cùng thử hết. Nào là khởi động lại prometheus exporter phòng khi có lỗi, khởi động lại các tiến trình hdfs trên tất cả các node. Rồi khởi động lại các ứng dụng, .... với hy vọng rằng sẽ giải quyết được vấn đề. Cũng có vẻ hiệu quả. Khi vừa mới restart thì hệ thống xanh, nhưng sau đó vài phút thì hệ thống lại báo có một node rớt ra ngoài. Điều này khiến cả hai bạn nghĩ rằng do app tịt chỗ nào đó. Nên cứ tha hồ restart. Mỗi lần vậy cũng không dễ dàng gì, vì phải restart xong là ngồi đợi cho đến khi log sạch sẽ mới chuyển qua restart node khác. Ừ, về log thì biết rồi, các ứng dụng java nó quăng ra qua nhiều thứ nhưng điều quan trọng thì tìm không thấy đâu.
Rồi đi xem trang wiki, xem các tài liệu chỉ dẫn để lại. À, tại vì bạn engineer ngồi setup xong bộ big data cluster này phải đi nghỉ phép vài tháng rồi, không ai biết thực sự chuyện gì đang xảy ra.
Mò, hai bạn ngồi trên đống lửa production, từ 9h sáng cho tới gần 1h chiều. Có ý kiến gì thì cứ thử. Mệt quá, hai bạn cùng nghỉ.
Khi bạn kia đi rồi thì mình ngồi coi lại log, và cấu hình, và trong 3 phút đã phát hiện ra vấn đề tại đâu: Còn thiếu một file cấu hình nữa, quên update. Chỉ việc thêm đĩa mới vào đó, khởi động lại. Khỏe re.
Bài học là gì?
PD nó tai hại nếu hai ông thần cứ giả bộ như không biết gì cứ ngồi thử / sai. Khi vấn đề xảy ra, chỉ cần hít một hơi thật sâu, coi chính xác lỗi gì, đọc log kỹ rồi fix thôi. Khi giải quyết vấn đề thì cần tập trung, chứ nhiều ý kiến linh tinh không có cơ sở thử cho khỏi mất tình đồng nghiệp chẳng ăn nhằm gì đâu. Hehe.
-- 359b7585 (Ky-Anh Huynh 2019-09-04 18:51:50 +0200 46) at https://github.com/linuxvn/about/blob/master/Notes-2019.md#pair-debugging
🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞
elasticsearch-workshop-observability https://github.com/linuxvn/about/blob/master/Notes-2019.md#elasticsearch-workshop-observability
tags: #elasticsearch #observability #berlin
Hôm đầu tháng 10 mình có dịp tham gia workshop do công ty Elasticsearch tổ chức. Từ khóa của sự kiện là
observability. Workshop này hoàn toàn miễn phí, tổ chức ở một khách sạn lớn, có đồ ăn uống sáng, trưa ngon lành, nhưng có lẽ... xa nên phòng hơi vắng. Mình gặp nói chuyện với một anh chàng gốc Bắc Âu ở Berlin, nói rằng đi xem thế nào, tại lên chức lâu rồi nên không còn nhanh tay lẹ mắt cài đặt gì nữa :) Có thể, vì nhiều người lên chức quá, nên mới có Elasticsearch bản cloud, cài đặt tích hợp sẵn mọi thứ từ APM, Log, Metrics, rồi Machine Learning, nhìn cái menu mà choáng ngợp, nghĩ ngay mình còn phải học thêm 10 năm nữa chưa xong cái nghề ops này :) Bản cloud đúng khỏe, cài đặt cấu hình gì cũng có sẵn rồi, rẹt rẹt. Làm mình bồi hồi nhớ lại thuở ngồi kỳ cọ mấy cái cấu hình sao cho mấy node ES nối nhau. Khổ gì đâu.
observability là gì? Nghe thấy lạ, khó đọc (dù sao, cũng dễ đọc hơn high availability), giải thích thì loằng ngoằng như ở đây https://www.elastic.co/blog/observability-with-the-elastic-stack . Tóm tùm lum lại, là một chỗ chung để theo dõi toàn bộ hệ thống, ở góc độ lớn hơn của người làm ops, của developer hay quản lý.... Nói chung, ý tưởng thì hay, còn thực hiện thì đấy, có ES lo rồi. Mới đây N26 công ty start-up về tài chính ngân hàng cũng có workshop về observability, nhưng hỏng biết có gì ở trong đấy. Từ khóa này cũng khá là hot trong sự kiện mà O'Reilly tổ chức (tóm tắt của mình: https://gist.github.com/icy/d32c504eb1d41adea11cff4ba0865808.) Có mấy cái lặt vặt như
filebeat, kibana,... mình nghĩ nhiều bạn biết rồi. Trong khi thực hiện bài lab, thì có điều hài hước là nhiều người gõ ngay vi/vim rồi đứng hình, lý do trình duyệt không hỗ trợ, trong khi về cơ bản nano vẫn chạy ổn. Thật chớt quớt, nhưng lượm lặt lớn nhất của buổi workshop này chính là, mình tin rằng lựa chọn dùng nano là hợp lý, đúng đắn. Mình bồi hồi nhớ lại cách đây mấy năm khi mới vào ai đá tao, mấy bạn trong team hỏi thế chú xài gì, vim hay Emacs, xong có vẻ vô cùng thất vọng vì có một thằng trời đánh nó trả lời là ... nano :)) À, ngoài ra còn
filebeat, tuy được quảng bá rầm rộ nhưng trong buổi workshop bà con cài lên xuống muốn xỉu lơ luôn. Và mình cũng mất đâu gần gần hai buổi cho nó, đơn giản là muốn nó hỗ trợ k8s thì xài bản mới, mà xài bản mới thì nó không thèm nói chuyện với logstash hay es cũ. Ơ hay, rảnh quá ha. Chưa kể xài mem/cpu gì nhiều. Thôi, goodbye! Còn mấy cái cao siêu như
observability thì để dành lại cho các bạn tự tìm hiểu thôi; mình có biết gì đâu. Nếu cần thì mình chỉ đơn giản bỏ devops mà chuyển qua opssex thôi, đổi job title, đổi lương, công việc vẫn như cũ.^^ PS: Nhờ workshop mà mình còn gặp bạn T. cũng ở Sài gòn qua Bá linh tìm ngoại tệ . Rồi từ đó phát hiện nguyên băng Lazada bên này luôn. Điều này làm mình có chút cảm hứng để viết tiếp một chút về Bá linh, mà bạn sẽ được đọc thêm sau.
-- 195d3db1 (Ky-Anh Huynh 2019-11-22 15:02:35 +0100 47) at https://github.com/linuxvn/about/blob/master/Notes-2019.md#elasticsearch-workshop-observability
🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞
helm-nightmare-p3 https://github.com/linuxvn/about/blob/master/Notes-2019.md#helm-nightmare-p3
tags: #k8s #helm #panic
Mình bắt đầu gõ những dòng này thì cô gái tóc vàng với khuôn mặt thanh tú ngồi đối diện đứng lên xuống ga. Ngồi suốt một buổi mà cả hai không nói với nhau điều gì, rồi ra đi không từ biệt. Có lẽ cả hai cùng ngại nói đến helm, chăng? Phiên bản mới 3.0 mới ra có gì hay? Thôi, đành viết lại vài dòng để nhớ cô gái không quen và sẽ chẳng bao giờ quen.
Cô nhớ cho! Tới tháng 5 này thì các helm
stable trước đây sẽ không còn được liệt kê trên kho Helm, và cuối năm 2020 nhân dịp bảo hiểm xã hội thay đổi cách tính theo hướng có hại nhiều hơn lợi cho người lao động, dự án quy tụ các bản chart cứng (stable) sẽ dẹp luôn. Nhưng khoan nói về helm3. Nhiều người vẫn hạnh phúc với helm2. Cũng khoan nói về helm2. Hãy nói tại sao có helm, và lý giải một phần tại sao
kustomize ra đời. Về cơ bản, các tài nguyên trên k8s có các thuộc tính cơ bản: phiên bản api, thể loại (
.kind), tên riêng (.metadata.name), đặc tả (.spec). Phần đặc tả phức tạp nhất, và người dùng phổ thông xài yaml để viết. Khâu cuối cùng ngay trước khi deploy là file yaml, nhưng trước đó, chín người mười ý, đặc biệt là 9 người từ 10 công ty khác nhau, họ cãi nhau và bắt đầu thêm mắm muối vào file yaml đó. Để dễ hiểu, hãy tưởng tượng đây là file yaml ban đầu: apiversion: lauxanh/v1stable
kind: PornVideos
metadata:
name: demo
labels:
say: "hello, world!"
spec:
filename: demo.mp3
vip_account: true
sau đó 9 ông devops vào sửa lại như sau:
apiversion: lauxanh/v1stable
kind: {{ .Values.PornKind }}
metadata:
name: {{ .Values.PortName }}
labels:
{{ .Values.Action }}: {{ .Values.Message }}
spec:
filename: {{ .Values.PornFileName }}
vip_account: {{ .Vallues.VipIsRequired }}
{{- if .Values.OhMyLauxanh }}
{{ toYaml .Values.OhMyLauxanh | indent 2 }}
{{- end }}
{{- if .Values.Zalando.Users }}
zalando_group: {{ .Values.Zalando.group_name }}
{{- end }}
{{- if .Values.HelloFresh.Users }}
spec: {{ .Values.HelloFresh.Is.Not.Zalando }}
{{- end }}
# company X
# company Y
# company Z
Mỗi dạng thông tin trong file yalm mà k8s có thể hỗ trợ người ta bỏ luôn, thay bởi một biến của helm. Bao nhiêu kiểu đặc tả, bao nhiêu tham số thì cũng xem xem chừng đấy biến số trong tập tin giá trị của helm. Bạn xem thử tui nói đúng hông: https://github.com/helm/charts/blob/master/stable/grafana/templates/deployment.yaml Ý tuởng cơ bản là hay, từ file ban đầu, hỗ trợ nhiều công ty, nhiều môi trường, nhiều biến thể khác nhau. Mục đích tốt, nhưng sau một thời gian thì nhiều thứ quá, nhìn loạn cả óc. Đó là lý do ra đời cái gọi làm helm cứng, stable: nó stable bởi muốn thay đổi nó là chuyện chẳng dễ dàng gì, ít ai dám đụng vào.
Câu hỏi là, tại sao không xem ngay một đặc tả trong file
yaml là một biến số luôn. Nghĩa là, trong ví dụ ở trên, ta tự động có các biến số sau $awesome.$metadata.$name = "demo"
$awesome.$metadata.$labels.$say = "Hello, world!"
$awesome.$spec.$filename = "demo.mp3"
$awesome.$spec.$vip_account = "true"
(stripped; please read more on Github)
-- 621232f4 (Ky-Anh Huynh 2019-12-12 10:56:44 +0100 48) at https://github.com/linuxvn/about/blob/master/Notes-2019.md#helm-nightmare-p3
🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞
hello, 2020 https://github.com/linuxvn/about/blob/master/Notes-2020.md#hello, 2020
tags: #misc #k8s
Có vài bản nháp trong
git stash, không được xuất bản trên kênh tin, do mình lười không hoàn thiện. Bài này viết nhanh tóm vài ý chính. Một bạn hỏi bắt đầu học với
k8s thế nào. Câu trả lời: Nếu có kiến thức cơ bản về Linux thì thử coi dự án kubernetes the hard way để tự cài lại các thành phần của một k8s cluster. Sau đó, bỏ qua helm mà tìm các ví dụ về kustomization để học: Bạn cần hiểu cách nói chuyện với k8s cluster chứ không phải nhờ công cụ nào khác làm hộ. Một bạn khác hỏi học devops thế nào? Câu trả lời: Mình chịu. Tốt nhất là xin vào chỗ công ty nào đó có người họ hướng dẫn cho. Đừng quên mua đọc vài cuốn sách xịn: nhớ là mua sách, bản hard-copy hay pdf gì nhé. Khi nào bạn bỏ tiền ra đầu tư thì bạn mới thu được kết quả tốt nhất; nói cách khác, đừng đầu tư bằng tiền của người khác.
Một bạn nhắn hỏi sao em gửi CV mấy chục cái rồi không ai gọi em đi phỏng vấn, hay gọi rồi em rớt. Lúc mình xin việc thì mình cũng phải nộp nhiều chỗ lắm, rớt nhiều, thậm chí gửi xe xong rồi vẫn phải dắt xe ra gửi lại. Muốn viết CV tốt thì mình chỉ có một câu ngắn gọn: Mỗi công ty viết một CV riêng cho công ty đó. Đừng viết điều bạn nghĩ: hãy viết điều công ty cần.
Một bạn nghe đâu bị nợ lương. Chỉ có cách duy nhất để đòi như hướng dẫn sau
https://icy.theslinux.org/m/kyanh.net/2018/01/07/luat-2-kien-cong-ty-no-luong/index.html
Nếu cần hỗ trợ gì thì liên hệ mình nhé. Đừng làm gì khác dại dột mà mất sạch tiền đấy. Mình sẽ tư vấn miễn phí cho bạn các vấn đề liên quan tới luật; đơn giản, mình không phải là luật sư.
Chương trình Bluecard của Đức không yêu cầu bạn phải có bằng đại học: Có công ty ở đây nhận là bạn có thể xách vali tìm đường kíu nước được rồi. Bạn nhanh chân kẻo vài năm nữa sẽ không nhiều cơ hội, mặc dù nghe đâu, có khi qua Nga Pháp gì đó sẽ tốt hơn chứ không phải Đức.
Cuối cùng, nick telegram của mình trên
linuxvn sẽ ít được dùng nữa, bạn có thể tag/mention khi nào cần: @Respect_DoNotMakePersonalAttacks. Khi nào có ai ăn hiếp bạn thì bạn cứ báo mình tiếng, mình giải quyết ngay cho. Giờ mình phải lên núi luyện công đây. Hây hây. PS: Bản nháp của hello-2020 có nói về cả pháo hoa; nhưng do sơ suất mà nhiều hình ảnh sống động mỗi chỗ một cái, nên thôi bạn ráng chờ qua năm. Đằng nào thì 2020 cũng không phải năm mở đầu thập kỷ mới mà.
-- 524cf2d9 (Ky-Anh Huynh 2020-03-03 05:06:52 +0100 13) at https://github.com/linuxvn/about/blob/master/Notes-2020.md#hello, 2020
🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞
adminless https://github.com/linuxvn/about/blob/master/Notes-2020.md#adminless
tags: #linuxvn
Thế là giai đoạn độ quá từ Linux lên MacOS đã sắp xong. Từ 1/4/2020, tất cả bà con ở
linuxvn đều bình đẳng như nhau, ai cũng được phần, hỏi theo nhu cầu, trả lời theo năng lực, chát theo tinh thần MacOS (là gì tính sau!) Tất nhiên, cũng có một số bạn bình đẳng hơn một số bạn khác. Cụ thể là bạn Đức vẫn phải còn giữ quyền Admin đề phòng thế lực thù địch chống phá kênh linuxvn. Nick của mình sẽ để chơi vậy thôi, hỏng xài thường xuyên; hy vọng mình sẽ tham gia được với nick khác sớm.
Chúc một ngày vui vẻ.
-- b8f5d87e (Ky-Anh Huynh 2020-04-01 08:03:46 +0200 14) at https://github.com/linuxvn/about/blob/master/Notes-2020.md#adminless
🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞
senior-junior-vs-junior-senior-engineer https://github.com/linuxvn/about/blob/master/Notes-2020.md#senior-junior-vs-junior-senior-engineer
tags: #misc
Một bạn hỏi junior thì làm gì, rồi senior làm gì. Mình có dịp đi phỏng vấn rải rác vài chỗ nên tóm tắt lại đây cho các bạn coi, hy vọng có ích. Bạn nào có thực lực sẵn rồi, lương tháng khoảng 3k mỹ kim trở lên thì không cần đọc tiếp :))
Trước hết, senior/junior là cái tựa công ty đặt ra, còn nói chung không có tiêu chuẩn cụ thể. Mỗi người kha khá một số món, công ty cần một số món, nếu khớp nhau nhiều thì bạn trở thành senior của công ty thôi.
Có thể hiểu, sự khác nhau cơ bản giữa senior/junior là ở cách bạn quyết định vấn đề và lựa chọn giải pháp kỹ thuật. Nó liên quan nhiều hơn tới câu trả lời của bạn.
Ví dụ: Bạn có biết nhiều về devops không? Một bạn tầm tầm thì trả lời, có có, biết jenkins, biết github, biết gitlab, bla bla. Một bạn khác trả lời: Xưa giờ tôi chỉ làm mỗi cái jenkins, tôi viết plugin cho nó, sau rồi thì tôi chán quá phải xài github, thấy cuộc đời khỏe hẳn.
Hay: Bạn có biết gì về Docker không? Dạ có, tôi xài docker chạy app, thiết kế tối ưu dung lượng xài Alpine, giờ tôi xài k8s. Tôi không xài Docker Swarm hàng dỏm lắm. Một bạn khác trả lời: Tôi có xài Docker. Nhưng docker nhiều vấn đề quá, ví dụ nó làm hỏng cái iptables của tôi. Nói còn yêu cầu cả root, nên tôi thử chạy Docker ở user thường mấy ngày rồi không được. Tôi vẫn xài Docker Swarm, nó có nhiều cái rất khó chịu, nhưng lại đơn giản cho đội phát triển, họ làm gì cũng nhanh gọn. Lâu lâu có bug thì fix cũng lẹ.
Có đi phỏng vấn ở đâu thì câu trả lời của bạn cũng quan trọng. Và có những thứ bạn không bao giờ bịa ra được nếu bạn không hiểu gì về nó. Muốn trở thành senior, hãy có câu trả lời senior. Muốn có câu trả lời senior, hãy dành thời gian đào sâu nghiên cứu cái gì đó.
-- e9ea3358 (Ky-Anh Huynh 2020-06-10 08:25:33 +0200 15) at https://github.com/linuxvn/about/blob/master/Notes-2020.md#senior-junior-vs-junior-senior-engineer
🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞
october-update https://github.com/linuxvn/about/blob/master/Notes-2020.md#october-update
tags: #jobless #misc
Lâu quá rồi chả viết gì. Nên sau đây là vài thông báo nho nhỏ:
1. Mirror của ArchLinuxVn (Arch, ArchArm, TheSexLinux, Viettug.org) đã sập mấy tháng nay rồi. Nhà mạng Vịt teo xài nat mấy chục lớp, nên cổng 80 đóng cái sầm. Thôi, ta chia tay nhau từ đây.
2. Nhóm
linuxvn đông quá rồi, hơn 7 ngàn nick (ấy là sau khi nhân lên với 100/10). Mong các bạn trao đổi sôi nổi, các chuyện tình cảm nhắng nhít thì chắc không phải để trao đổi trên đó rồi. Con bot thích thì nó chết, khi nào có điện nó sống lại. 3. https://t.me/dailyops: Kênh nhỏ đăng các mẹo linh tinh, được cập nhật mỗi ngày, hoặc buồn thì mỗi tháng hoặc mỗi năm. Nếu không bận làm tình thì bạn có thể vào xem nhé. Để đăng tin lên đó bạn chỉ cần gửi nhắn cho bạn nào đó trên linuxvn.
Hết, viết gì nữa? Hỏng lẽ nói xấu Helm, hay codebuild tiếp? Cái bọn điên ấy, xấu quá rồi, xấu còn hơn xxx muôn năm của chúng ta.
Thôi dẹp, xin chào. Chắc là bài cuối cùng của năm 2020 đây nhé. Cảm ơn bạn đã theo dõi.
-- 4f7631f9 (Ky-Anh Huynh 2020-10-15 21:43:11 +0200 16) at https://github.com/linuxvn/about/blob/master/Notes-2020.md#october-update
🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞