thảo luận Code trên Mac với Win cái nào sướng hơn?

  • Người tạo chủ đề Người tạo chủ đề bamboo.bamboo
  • Ngày bắt đầu Ngày bắt đầu
các anh đánh tráo khái niệm vl, scale thì đương nhiên là do tổ chức code, tách DB ra managed db, cdn, cache, load balancer các kiểu, những vấn đề đấy thì cả docker hay ko docker đều phải làm cả.

thôi tôi giả sử tôi là junior mới vào công ty, tôi thích project có docker hơn vì tôi chỉ cần phải docker-compose build rồi docker-compose run là nó chạy, không phải setup bằng tay env, ko phải lo lắng dependencies này nọ trên máy của tôi ok chưa? tương tự như trên production/ staging, tôi expect là nó đã chạy đc trên máy tôi thì lên đó nó cũng sẽ chạy đc bởi vì docker làm môi trường là như nhau. dễ hiểu vl tôi ko hiểu sao các ông cứ phải kiếm cái này cái nọ để phản pháo lại cho bằng được? ego à? thích ngược dòng? elitist chỉ xài bash script bare metal vps?

còn nữa, docker thì liên quan gì đến code của ông, team ông ko có review code, review pull request, để code kém nó qua xong đổ tại docker wtf? đôi ko tôi ko hiểu các ông tranh luận cái vấn đề gì vì lôi toàn mấy thứ ko liên quan vào

xong còn bần đến mức lôi 1 thằng có 1m ccu có practice tệ như các ông để làm luận điểm nữa mới hài :)) các ông ko phân tích đúng sai, tốt xấu, bảo á à thằng này giàu vl 1m ccu mà còn xài bad practice, thế thì công ty mình, pet project của mình xài gì chả đc :)) ok tôi bảo rồi, có docker cũng đc ko có cũng đc, các ông cứ deploy như 5 10 năm trước nó vẫn chạy đc, vẫn scale tốt thôi, thế nhé, không cần học hỏi gì cái mới đâu.
practice tệ hay không thì họ đã đưa vào production chạy nhiều năm, đã ra lợi nhuận, không gặp phốt. tôi không hiểu là anh còn muốn gì nữa?
 
practice tệ hay không thì họ đã đưa vào production chạy nhiều năm, đã ra lợi nhuận, không gặp phốt. tôi không hiểu là anh còn muốn gì nữa?
ừ vậy thì nên học cái tốt của họ là sản phẩm tốt, cách tạo lợi nhuận, cách ko gặp phốt, cách sống nhiều năm, chứ ko phải nhìn vào spham thành công xong chọn phần tệ nhất rồi học anh nhỉ =)
 
Thread này sẽ ko đi xa the này nếu ko có “k8s rule them all”

via theNEXTvoz for iPhone
thực ra tôi cũng ko rành k8s vì trên cty devops lo việc đấy rồi, tôi chỉ biết docker thì tiện hơn setup mọi thứ bằng tay, đặc biệt rất dễ onboarding người mới. tưởng tượng onboarding bằng ssh bash script với docker thì tôi cũng ko biết so sánh kiểu gì.
 
ừ vậy thì nên học cái tốt của họ là sản phẩm tốt, cách tạo lợi nhuận, cách ko gặp phốt, cách sống nhiều năm, chứ ko phải nhìn vào spham thành công xong chọn phần tệ nhất rồi học anh nhỉ =)
thôi thì tuỳ anh. trong hackernews kia có một cái tranh luận thế này:

>> With a Kubernetes autoscaler, this takes you ~20 Minutes to setup pod autoscaling. If you run your k8s on say GKE, setting up node autoscaling is another 5 Minutes.nrb 4 months ago

>I totally agree with you, once you've factored in the dozens of hours gaining knowledge of k8s and hundreds+ of hours of experience dealing with it in production.
>You can get by with far less, but it's going to be pretty stressful when things go sideways in prod without knowing exactly why.

bọn anh làm dự án to tát thế nào tôi không rõ, nhưng như bọn tôi làm smalltime fullstack (đặc biệt là solo dev) có cả tá việc phải lo trước khi nó tới mức độ scale cần lãng phí thời gian học giỏi k8s.
tất nhiên bọn tôi chỉ làm dự án là "smalltime", "hobby" thôi cho nên nói gì cũng bằng nhau, đúng không :)

p/s: còn vụ anh tranh luận là docker thì hợp cho newbie, cho fresher hơn thì nói thật kinh nghiệm thực tế của tôi là ngược lại (tất nhiên nếu anh là người setup environment cho các bạn kia từ đầu tới đít thì không nói)
 
tôi thì tuỳ anh. trong hackernews kia có một cái tranh luận thế này:

>> With a Kubernetes autoscaler, this takes you ~20 Minutes to setup pod autoscaling. If you run your k8s on say GKE, setting up node autoscaling is another 5 Minutes.nrb 4 months ago

>I totally agree with you, once you've factored in the dozens of hours gaining knowledge of k8s and hundreds+ of hours of experience dealing with it in production.
>You can get by with far less, but it's going to be pretty stressful when things go sideways in prod without knowing exactly why.

bọn anh làm dự án to tát thế nào tôi không rõ, nhưng như bọn tôi làm smalltime fullstack (đặc biệt là solo dev) có cả tá việc phải lo trước khi nó tới mức độ scale cần lãng phí thời gian học giỏi k8s.
tất nhiên bọn tôi chỉ làm dự án là "smalltime", "hobby" thôi cho nên nói gì cũng bằng nhau, đúng không :)

small time hobby project thì cần gì k8s hả anh? chỉ cần setup docker là đc rồi? tôi làm thì chỉ cần copy qua lại mấy file dockerfile là xong, hay anh định kiếm comment bảo học docker mất xxx giờ nên ko học vì anh toàn làm smalltime fullstack gì đó :)

mà thôi tôi thấy cũng đi vào ngõ cụt rồi, tôi summary lại docker để làm gì trước khi anh lại ép nó phải làm những thứ nó ko được thiết kế để làm:

- portability: dễ dàng clone ra nhiều instance khác, setup một lần xong có thể đem lên vps được luôn mà ko cần setup lại.
- sharability: dễ dàng chia sẻ, onboarding cho người khác vào project, vì chỉ cần gửi container là đc.

vì 2 đặc tính này nên k8s mới leverage để làm những cái scaling cao siêu hơn, dễ dàng tích hợp các services như ci cd vào.

nếu anh ko cần 2 đặc tính này thì thôi, cũng ko cần học cả docker, tôi sợ lá bài solo dev, small time, pet project only for life, hobby lắm rồi =)
 
small time hobby project thì cần gì k8s hả anh? chỉ cần setup docker là đc rồi? tôi làm thì chỉ cần copy qua lại mấy file dockerfile là xong, hay anh định kiếm comment bảo học docker mất xxx giờ nên ko học vì anh toàn làm smalltime fullstack gì đó :)

mà thôi tôi thấy cũng đi vào ngõ cụt rồi, tôi summary lại docker để làm gì trước khi anh lại ép nó phải làm những thứ nó ko được thiết kế để làm:

- portability: dễ dàng clone ra nhiều instance khác, setup một lần xong có thể đem lên vps được luôn mà ko cần setup lại.
- sharability: dễ dàng chia sẻ, onboarding cho người khác vào project, vì chỉ cần gửi container là đc.

vì 2 đặc tính này nên k8s mới leverage để làm những cái scaling cao siêu hơn, dễ dàng tích hợp các services như ci cd vào.

nếu anh ko cần 2 đặc tính này thì thôi, cũng ko cần học cả docker, tôi sợ lá bài solo dev, small time, pet project only for life, hobby lắm rồi =)
bây giờ bỏ qua docker nhé, nói ngôn ngữ lập trình đi, kiểu như thằng rust nhé, tôi có thể kể ra một list dài hơn 100 bullet points rằng dùng rust ngon ra sao (memory safe, fast, non zero abstraction, pattern matching, nongc -> portable các kiểu), bảo anh ngay lập tức phải viết hết mọi thứ sang rust, nếu không project của anh chỉ mãi chỉ là toy project, slow, bug ridden thì anh có nghe không hay cười khẩy bỏ qua?

tôi không phủ nhận là docker có rất nhiều ưu điểm, cái chính là tôi hỏi trong trường hợp của bọn tôi (và vài trường hợp cá biệt) thì docker đem lại có đủ nhiều benefit hay không thì tôi thấy các anh toàn đánh trống lảng đưa về usecase của mình, rất hài hước.

nên nhớ là cùng với k8s, thì ban đầu hai bạn kia claim là docker là nhất, không dùng docker là anh ngu/thiếu hiểu biết nhé?
 
> portability: dễ dàng clone ra nhiều instance khác, setup một lần xong có thể đem lên vps được luôn mà ko cần setup lại.

Cái này nó có lợi ích gì hơn so với việc tôi viết 1 script để deploy không?
PS: À mà tiện thể tôi muốn hỏi docker có lợi ích gì cho quá trình dev không? Ngoài việc không phải cài dependencies (postgres) lên máy (tôi thấy cái này vô nghĩa vãi, vì máy tôi là máy dev), thì docker còn có tác dụng gì nữa không?
 
> portability: dễ dàng clone ra nhiều instance khác, setup một lần xong có thể đem lên vps được luôn mà ko cần setup lại.

Cái này nó có lợi ích gì hơn so với việc tôi viết 1 script để deploy không?
có chứ, cái lợi là anh thêm thời gian setup docker trên vps :)

mà đậu má 2 cái xkcd image tôi đã post từ mấy post trước rồi, nhiều cậu cứ lờ đi coi như không thấy, hài thật.
muốn nói tiện, thì phải thử thống kê xem mình đã tiết kiệm dc bao nhiêu thời gian về việc này (vì như "small time" project, setup tất cả bằng tay thì việc này cũng chỉ làm vài lần là cùng), chứ khẳng định như đúng rồi thì ai tin.
 
có chứ, cái lợi là anh thêm thời gian setup docker trên vps :)

mà đậu má 2 cái xkcd image tôi đã post từ mấy post trước rồi, nhiều cậu cứ lờ đi coi như không thấy, hài thật.
muốn nói tiện, thì phải thử thống kê xem mình đã tiết kiệm dc bao nhiêu thời gian về việc này (vì như "small time" project, setup tất cả bằng tay thì việc này cũng chỉ làm vài lần là cùng), chứ khẳng định như đúng rồi thì ai tin.

Tôi bắt đầu thấy giống kiểu thay vì học sql, các bạn học ORM, thay vì học linux, shell script, các bạn học docker.
 
Tôi bắt đầu thấy giống kiểu thay vì học sql, các bạn học ORM, thay vì học linux, shell script, các bạn học docker.
cái này cũng không hẳn là sai, sinh ra abstraction layer cho công việc tiện hơn mà.
cái tôi ghét là các bạn cứ ép người khác dùng cái này cái kia cho bằng được.

p/s: nhiều bạn có thể bảo thế anh ép người ta dùng shell script thì sao, thì như tôi bảo rồi, anh muốn customize dockerfile thì anh vẫn phải biết shell command thôi, chứ có phải là nó tự phát minh ra tất cả mọi thứ mới đâu.
 
cái này cũng không hẳn là sai, sinh ra abstraction layer cho công việc tiện hơn mà.
cái tôi ghét là các bạn cứ ép người khác dùng cái này cái kia cho bằng được.

p/s: nhiều bạn có thể bảo thế anh ép người ta dùng shell script thì sao, thì như tôi bảo rồi, anh muốn customize dockerfile thì anh vẫn phải biết shell command thôi, chứ có phải là nó tự phát minh ra tất cả mọi thứ mới đâu.

Tôi cũng không bảo abstraction là sai, nhưng vấn là nhiều bạn học ORM xong không thèm học sql nữa, cái gì cũng ORM. Có người 3 năm kinh nghiệm còn không viết nổi 1 câu query.
 
Hình như nhiều anh ở đây cứ gôm docker với k8s vào làm 1 nhỉ. Tôi chẳng biết k8s là gì nhưng xài docker trên cái toy project đúng là tiện thật, nhất là việc deploy, ci/cd nhanh hơn nhiều. Tưởng tượng CI mà ngồi viết shellscript dựng lại môi trường thì đúng là thảm họa
 
Hình như nhiều anh ở đây cứ gôm docker với k8s vào làm 1 nhỉ. Tôi chẳng biết k8s là gì nhưng xài docker trên cái toy project đúng là tiện thật, nhất là việc deploy, ci/cd nhanh hơn nhiều. Tưởng tượng CI mà ngồi viết shellscript dựng lại môi trường thì đúng là thảm họa

Anh nói như vậy là vì anh có nhiều kinh nghiệm về docker so với shell script. Còn đối với người có nhiều kinh nghiệm viết shell script thì ngược lại.

Mà thú thực tôi chẳng viết unit test và integration test bao giờ, nên cũng chẳng cần ci/cd, vì dự án của tôi chỉ là dự án con kiến, logic thuần crud.
 
câu trả lời vẫn là tùy người, tùy việc và tùy thời điểm. nghe chung chung vậy thôi nhưng đúng là nó chung chung thật, chỉ có trải qua mới biết. mấy ông cứ lấy kinh nghiệm cá nhân của mình ra khè là không đúng. ví dụ như dân số việt nam 100 triệu người, lấy ngẫu nhiên 1000 người ra khảo sát, trong 1000 người có 999 người thích ăn thịt chó, rồi kết luận 99,9% dân số việt nam thích ăn thịt chó là sai bét.

đây là vài trường hợp nghiêng về phía linux:
  • nếu ai đến với linux trước, sử dụng và phụ thuộc nhiều vào các công cụ trên linux thì khả năng macos sẽ là ác mộng. mặc dù linux và macos đều xuất phát từ unix nhưng lại không sở hữu các công cụ tương đồng nhau. lý do thì rõ ràng, hướng đi khác nhau, giấy phép khác nhau, đối tượng hướng đến cũng khác luôn.
  • bố cục bàn phím cũng là một nỗi đau khi chuyển từ linux sang macos, cái này ai dùng nhiều phím tắt mới hiểu, mấy ông cầm chuột rê khả năng lại thấy sướng hơn vì trackpad của macbook.
  • macos không có trình quản lý gói. trình quản lý gói brew đúng là thảm họa, nó chậm chạm và vài gói phải đổi tên để tương thích các công cụ có sẵn trên macos. các trình quản lý gói trên linux và cơ sở hạ tầng vẫn là tốt nhất.
  • người phát triển nhân linux, một số công cụ đặc thù trên linux thì tội gì phải dùng hệ điều hành khác.
  • người không thích các thông báo cập nhật làm phiền từ hệ điều hành.
  • macos không ổn đinh hơn linux, chả có cái gì ổn định cả, cái nào cũng có lỗi, cả phần cứng lẫn phần mềm luôn.
  • trình quản lý file trên macos như hạch, rối rắm, khó dùng.
đây là vài trường hợp nghiêng về phía macos:
  • xì tiền rồi lấy máy dùng, không như linux phải mày mò cài đặt, thậm chí còn đếch chạy được vì không có firmware, hoặc xảy ra một lỗi mà chính thằng phát triển cũng đếch biết là lỗi gì.
  • linux và các phần mềm xung quanh có một đống lỗi, điển hình là với wifi, bluetooh, trình quản lý âm thanh, giải mã video, quản lý năng lương, quản lý cửa sổ....
  • với người dùng cá nhân thì xử lý video, hình ảnh, âm thanh và dựng hình thì macos ăn đứt linux. thật ra linux trên máy tính cá nhân đứng bét bảng khoản này. nhưng khi áp dụng cho quy mộ lớn thì linux lại trên cơ macos vì lúc này các nhà cung cấp dịch vụ được cấp phép GPU firmware, phần mềm xử lý chạy hiệu quả hơn.
  • thời gian sử dụng macbook lâu hơn so với laptop chạy linux. vẫn là vẫn đề giấy phép với GPU firmware và các trình duyệt web khiến linux không thể sử dụng GPU một cách hiệu quả cho dựng hình và giải mã video. về khoản giải mã video thì linux với macos vẫn phải gọi window là bố. macos chỉ hỗ trợ các tiêu chuẩn công nghiệp như HEVC, còn những tiêu chuẩn do thằng khác đặt ra thì nó đéo nghe, chẳng hạn như VP9 .
  • phát triển và sử dụng phần mềm cũng như phần cứng trong hệ sinh thái táo thối.
 
Mà thú thực tôi chẳng viết unit test và integration test bao giờ, nên cũng chẳng cần ci/cd, vì dự án của tôi chỉ là dự án con kiến, logic thuần crud.
Thì ít nhất anh cũng phải đảm bảo nó build đc, boot lên nó chạy đc với db mẫu. Tôi khoái Java là vậy, compile xong, nó start đc là gần như mấy bug vớ vẩn giảm hẳn rồi( do thằng spring boot + hibernate nó tự check depends, controller, validate model... ngay lúc start rồi). Dùng mấy bọn như python, nodejs thì không có diễm phúc này, có khi lên đến prod rồi mới lồi ra cái model viết sai chính tả nếu ko viết unit test :beat_plaster:
À mà công nhận thằng spring boot có hơi steep learning curve thật (nếu muổn hiểu nó chứ ko phải code theo kiểu pattern cooy paste) nhưng sau khi dùng thử cả đống fw từ mọi miền ngôn ngữ thì chưa thấy thằng nào cân bằng đc nhiều thứ như nó
Anh nói như vậy là vì anh có nhiều kinh nghiệm về docker so với shell script. Còn đối với người có nhiều kinh nghiệm viết shell script thì ngược lại
Thật ra là vì mấy cái tool ci/cd tôi xài (gitlab) nó hỗ trợ docker là chính, push code lên nó tự build, tự test tự tạo image rồi tôi chỉ việc viết script ssh deploy cái image đó lên prod là xong.
 
Sửa lần cuối:
Cái này tôi ko tin lắm nhé. Bên VNG nhiều người khủng phết (Có bạn tôi nhé :)), nhưng bảo xử lý tầm 200k ccu mà ko có mấy cái a kể thì risk quá. K8 nó làm mấy cái back-up kiểu đấy tốt lắm.
p/s: Có ai dùng Cirrus chưa :( cho hỏi vài cái với (Hàng IBM lởm vãi tè)
Nghe có vẻ vô lý, nhưng thế thật đó.

Zalo ko docker cmj hết, toàn script restart staart stop thẳng trên sẻver qua ssh. ( ít nhất là 2018) ==> Sau 2018 thì tôi ko rõ nữa.

CCU của zalo thì các thím khỏi nghĩ là ít nhé. Nhưng cũng 1 phần là do hồi đó cồng kềnh quá rồi ko có kế hoạch hoăc chưa tính đến chuyện xài Docker hay K8s
 
Sửa lần cuối:
Nghe có vẻ vô lý, nhưng thế thật đó.

Zalo ko docker cmj hết, toàn script restart staart stop thẳng trên sẻver qua ssh. ( ít nhất là 2018) ==> Sau 2018 thì tôi ko rõ nữa.

CCU của zalo thì các thím khỏi nghĩ là ít nhé. Nhưng cũng 1 phần là do hồi đó cồng kềnh quá rồi ko có kế hoạch hoăc chưa tính đến chuyện xài Docker hay K8s
Giờ vẫn vậy thôi, lần gần nhất cách đây 1 tháng thôi, mấy cái core c ++ hết chứ đếch có k8s muti instance gì sất. Mình chưa thấy ai build ưng dung chạy trên ngôn ngữ này đi theo mô hình muti instance cả, bản thân hiệu năng nó qua tốt trên stanalone nếu code tốt

via theNEXTvoz for iPhone
 
Giờ vẫn vậy thôi, lần gần nhất cách đây 1 tháng thôi, mấy cái core c ++ hết chứ đếch có k8s muti instance gì sất. Mình chưa thấy ai build ưng dung chạy trên ngôn ngữ này đi theo mô hình muti instance cả, bản thân hiệu năng nó qua tốt trên stanalone nếu code tốt

via theNEXTvoz for iPhone
Bây h vẫn thế ợ.
Xưa chỉ nản lúc checkout cái corelib = SVN, build Java project xài Ant thôi :( lâu v~ nồi , vì tất cả lib ở đó hết. Ko biết h đã chuyển sang Git vs maven cho tiên chưa ta
 
Hình như nhiều anh ở đây cứ gôm docker với k8s vào làm 1 nhỉ. Tôi chẳng biết k8s là gì nhưng xài docker trên cái toy project đúng là tiện thật, nhất là việc deploy, ci/cd nhanh hơn nhiều. Tưởng tượng CI mà ngồi viết shellscript dựng lại môi trường thì đúng là thảm họa
K8s core của nó là docker nhung lên thành cloud service thôi, như kvm và openstack thôi. Chảng lẽ đi mở rộng docker trên một host
Nhiều bạn nói có docker deploy nhanh gọn, ngày xưa lúc chưa có docker, ko có ansible hay teraform thì chẳng le ssh từng con, ngừoi ta củng viết tool xài nội bộ thôi, bản thận tui củng tự viết tool làm cai việc này, đến bây giờ vẫn xài, nhưng các bạn tôi training thi tôi yều cầu xài ansible . Nhưng tôi vẫn xài hàng tui tự viết cho hệ thống riêng, đơn giản là thích vậy và vẫn làm nhanh lẹ , có thể tuỳ biến đủ kiểu theo bất cứ nhu cầu quái đản nào
via theNEXTvoz for iPhone
 
Sửa lần cuối:
Thì ít nhất anh cũng phải đảm bảo nó build đc, boot lên nó chạy đc với db mẫu. Tôi khoái Java là vậy, compile xong, nó start đc là gần như mấy bug vớ vẩn giảm hẳn rồi( do thằng spring boot + hibernate nó tự check depends, controller, validate model... ngay lúc start rồi). Dùng mấy bọn như python, nodejs thì không có diễm phúc này, có khi lên đến prod rồi mới lồi ra cái model viết sai chính tả nếu ko viết unit test :beat_plaster:
À mà công nhận thằng spring boot có hơi steep learning curve thật (nếu muổn hiểu nó chứ ko phải code theo kiểu pattern cooy paste) nhưng sau khi dùng thử cả đống fw từ mọi miền ngôn ngữ thì chưa thấy thằng nào cân bằng đc nhiều thứ như nó

Thật ra là vì mấy cái tool ci/cd tôi xài (gitlab) nó hỗ trợ docker là chính, push code lên nó tự build, tự test tự tạo image rồi tôi chỉ việc viết script ssh deploy cái image đó lên prod là xong.

Tôi dùng static language (f#) nên tất nhiên phải build thành công tôi mới commit. Code của tôi tách business logic với infrastructure logic (auth, pesistance...). Như tôi đã nói business của tôi rất ít nên unit test cho cái này hầu như không có. Infrastructure thì tôi cũng chỉ viết unit test cho postgres. Tôi không viết integration test.

Thật ra tôi cũng muốn setup 1 cái CI/CD để chạy unit test -> deploy, nhưng tôi thắc mắc không biết có cần phải dùng đến docker không?
 

Thống kê chủ đề

Ngày tạo
bamboo.bamboo,
Người trả lời cuối
2TbP,
Trả lời
597
Lượt xem
77.876
Quay lại
Lên đầu trang