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

prescolt · 10/6/20

Nipin đã nói:
hả hồi đầu năm tôi dùng amd vẫn cài được wsl2 bình thường mà nhỉ, bản mới lại đòi intel vt-x mới chạy à? (hay là cái virtualization của amd vẫn tương đương?)
mà để hôm nào xem lại xem performance đã khá hơn chưa, wsl1 ngừng phát triển rồi, wsl2 mới là tương lai

Xem thử đã upgrade lên wsl2 chưa nhé, càu wsl2 rồi nhưng muốn chay wsl2 thì phải nang cái đang chạy lên, nếu ko tương thích thì ruột nó vẫn là wsl1, lúc này no van ghi la version 1 như bên dưới
Intel Vt-X hay amd -V đều ok

xshatter · 10/6/20

prescolt đã nói:
Phiên bản cũ nó dựa vào linux container LXC để chạy, nó dóng vai trò điều phối quản lí, các phiên bản mới thì nó chỉnh là ảo hoá theo kiểu container luôn vì ko dùng LXC nữa mà nó tự viết 1 cái tương tự như LXC giao tiếp trực tiếp với kernel . Vậy khi đã có thành phần thay thay lxc thì nó chính là một chương trình ảo hoá theo mô hình container, chứ ko đơn thuần chỉ là điều phối tài nguyên và quản lí như trước. Từ linux docker chạy được trên windows là nó đã lột xác rồi

Tào lao nhé anh. LXC là LXC, docker là docker từ lúc mới ra docker đã chạy trong user space, tương tác trực tiếp với kernel. Hay anh đang nhầm lần docker machine? Docker chưa bao giờ là Hypervisor cả. Linux docker chạy đc trên win trc kia là nhờ docker machine, này thì ếu cần nữa vì đã có HyperV, WSL2 và đặc biệt là Window Container.

Sent using vozFApp

xshatter · 10/6/20

honeyfox đã nói:
Ví dụ như ko ai chạy DB trong docker ở production

Đó là quá khứ thôi. Giờ khác rồi.

Sent using vozFApp

gâu_ · 10/6/20

honeyfox đã nói:
Ví dụ như ko ai chạy DB trong docker ở production

còn tùy db gì, như postgresql hay mysql thì người ta dùng luôn service trên cloud, mà nguyên nhân chính là do bọn này được phát triển từ lâu, không phù hợp để deploy trên cloud, chứ như bọn db mới gần đây xem bọn nào chả hướng tới deploy trên k8s các kiểu cho gọn và dễ quản lý.

Ngay từ đầu chả ai bảo là docker hay gì gì là thần thánh đáp ứng được hết nhu cầu, cũng chả có phần mềm nào gọi là đáp ứng được hết trong lĩnh vực của nó, cái quan trọng ở đây là ông @prescolt còn không biết cách triển khai phần mềm cho nó đúng như cloud native, chạy docker thì như dạng docker desktop xong chê này nọ, trong khi chê những cái rõ ràng không phải do docker nó làm. Đừng lôi mấy cái phần mềm chuyên dụng đó ra, nếu lôi thì đọc lại phần in đậm.

Nipin · 10/6/20

prescolt đã nói:
Xem thử đã upgrade lên wsl2 chưa nhé, càu wsl2 rồi nhưng muốn chay wsl2 thì phải nang cái đang chạy lên, nếu ko tương thích thì ruột nó vẫn là wsl1, lúc này no van ghi la version 1 như bên dưới
Intel Vt-X hay amd -V đều ok

Xem tệp đính kèm 85166

lên rồi mà, tôi vẫn nhớ lúc downgrade xuống wsl1 nó mất gần chục phút

(cái wsl2 thì năm ngoái đúng là amd không chạy mà năm nay thì chạy rồi).

chukysovn · 10/6/20

có điều kiện thì mua mac, vì ngoài thân thiện với commandline còn màn hình xịn, pin ngon

via theNEXTvoz for iPhone

prescolt · 10/6/20

gâu_ đã nói:
còn tùy db gì, như postgresql hay mysql thì người ta dùng luôn service trên cloud, mà nguyên nhân chính là do bọn này được phát triển từ lâu, không phù hợp để deploy trên cloud, chứ như bọn db mới gần đây xem bọn nào chả hướng tới deploy trên k8s các kiểu cho gọn và dễ quản lý.

Ngay từ đầu chả ai bảo là docker hay gì gì là thần thánh đáp ứng được hết nhu cầu, cũng chả có phần mềm nào gọi là đáp ứng được hết trong lĩnh vực của nó, cái quan trọng ở đây là ông @prescolt còn không biết cách triển khai phần mềm cho nó đúng như cloud native, chạy docker thì như dạng docker desktop xong chê này nọ, trong khi chê những cái rõ ràng không phải do docker nó làm. Đừng lôi mấy cái phần mềm chuyên dụng đó ra, nếu lôi thì đọc lại phần in đậm.

Rõ ràng mình nói docker ko đáp ứng nhu cầu của mình về network, có k8s của cloud provider cũng vậy thôi, nhưng ông bạn chẳng phải khẳng dinh k8s của ông chạy ngon với caliso còn gì, còn tôi nói là cloud provider xịn cỡ nào cũng ko đáp ứng được. Xem cloudflare là điển hình của high traffic , máy chủ của nó nhưng service pps cao, thằng nào chạy k8s , toàn bộ stanalone cả, cùng lắm nhưng cái dịch vụ thống kê, controller api này nọ may ra deploy trên k8

gâu_ · 10/6/20

prescolt đã nói:
Rõ ràng mình nói docker ko đáp ứng nhu cầu của mình về network, có k8s của cloud provider cũng vậy thôi, nhưng ông bạn chẳng phải khẳng dinh k8s của ông chạy ngon với caliso còn gì, còn tôi nói là cloud provider xịn cỡ nào cũng ko đáp ứng được. Xem cloudflare là điển hình của high traffic , máy chủ của nó nhưng service pps cao, thằng nào chạy k8s , toàn bộ stanalone cả, cùng lắm nhưng cái dịch vụ thống kê, controller api này nọ may ra deploy trên k8

thím tự xem lại cái phát biểu lúc đầu của thím nhé, còn nếu thím nói docker hay abc gì không đáp ứng được nhu cầu từ đầu mình cũng chẳng rảnh mà đi vật nhau với thím

prescolt · 10/6/20

gâu_ đã nói:
thím tự xem lại cái phát biểu lúc đầu của thím nhé, còn nếu thím nói docker hay abc gì không đáp ứng được nhu cầu từ đầu mình cũng chẳng rảnh mà đi vật nhau với thím

Ngoài ra mô hình mạng docker thì nó đơn giản thôi cứ NAT rồi chạy, nhưng mấy ứng dụng tải cao về network chạy kiểu đó chỉ có thọt, chưa kể vụ IO,IRQ, interrupt ko tự chủ được
Đây nè nhé, nguyên văn của mình nói nó ko đáp ứng duoc tải cao về network, k8s cũng NAT chứ có khác biệt gì. Chứ từ đâu đã ko chê docker các lí do khác

xindungbantoi2 · 10/6/20

code trên centos/fedora/ubuntu minimal, bản no gui là trùm phé nhen tụi bây.
mấy thằng gà xài gui bày đặt lên tiếng docker rồi portable mysql/mssql rồi portable mongodb nghe mệt thiệt chứ...

tụi bây đạt đến trình độ thứ thằng techlead trên youtube đi rồi hãy bàn cãi

) còn xài chuột chứng tỏ gà

)

gâu_ · 10/6/20

prescolt đã nói:
Ngoài ra mô hình mạng docker thì nó đơn giản thôi cứ NAT rồi chạy, nhưng mấy ứng dụng tải cao về network chạy kiểu đó chỉ có thọt, chưa kể vụ IO,IRQ, interrupt ko tự chủ được
Đây nè nhé, nguyên văn của mình nói nó ko đáp ứng duoc tải cao về network, k8s cũng NAT chứ có khác biệt gì. Chứ từ đâu đã ko chê docker các lí do khác

vấn đề là docker nó chẳng quy định network hoạt động như thế nào, thím dùng theo kiểu của thím rồi đánh giá vậy, thím cứ thử tự setup một cluster k8s đi rồi hiểu phần network service của nó có thể tích hợp được những gì

prescolt · 10/6/20

gâu_ đã nói:
vấn đề là docker nó chẳng quy định network hoạt động như thế nào, thím dùng theo kiểu của thím rồi đánh giá vậy, thím cứ thử tự setup một cluster k8s đi rồi hiểu phần network service của nó có thể tích hợp được những gì

Mình đã nói là k8s các model network của nó đều la virtual routing, chỉ đáp ứng băng thông, ko đáp ứng duoc về packet performance. Mình ko cần phải sử dụng, chỉ cần nhìn model của nó, các thành phần nó xài là sẽ đánh giá được hiệu năng của nó, vậy thôi.
Đây là model docker cơ bản

Đây là model docker chi tiết hơn, DNAT và SNAT là 2 kỷ thuật hay sử dung

Model caliso trong k8s , Sử dung ip route và iptables cho ACL eth0 trong C1 - calixx trong Host là tap interface, từ caliyy tới ethx là qua bridge interface (cùng host), nó ko ghi rõ nhưng chỉ có 2 kỹ thuật đó. Và tất cả các model này đều đáp ứng được về băng thông, nhưng ko đáp ứng duoc tầng suất gói tin, có nghĩa là nếu mình có service firewall gia sữ chay duoc trong C1..N thì chết ngắt ngay chỗ iptables. Trong model này chỉ có 2 chỗ hiệu năng ko bị suy giảm là ngay chỗ ethX và ethY

- Với model caliso nếu muốn ko bị chết ngay iptables thì phải đấu nối từ calixx (tap interface) vào ethx qua virtual sw (ví dụ openvswitch chỉ layer 2). Nếu có acl thì là ebtables, chỉ có MAC ko có IP. Mô hình này gọi là flatnet, phần route sẽ nằm ngoài. C1,C2 ... sử dụng IP public có thể hiểu được từ bạn internet, ko thể sử dụng ip lớp C. Và hiện tại K8S hoàn toàn ko có áp dụng mô hình này, căng lắm là float IP, tức là DNAT, bỏ routing đi, giá rẽ, moi ong một micro service, ip public éo nào chịu cho thấu.

gâu_ · 10/6/20

prescolt đã nói:
Mình đã nói là k8s các model network của nó đều la virtual routing, chỉ đáp ứng băng thông, ko đáp ứng duoc về packet performance. Mình ko cần phải sử dụng, chỉ cần nhìn model của nó, các thành phần nó xài là sẽ đánh giá được hiệu năng của nó, vậy thôi.

thế nó dùng phần cứng tương tự của ông để làm network service thì sao, đã bảo k8s nó chỉ quy định interface còn hiện thực thế nào do thằng tạo ra cluster k8s nó quyết định mà, phát biểu như thím chả khác nào tôi nói tôi có con xe 4 bánh, thím nhìn vào phán xe 4 bánh chạy chậm lắm trong khi thực tế thì nếu tôi gắn động cơ công suất cao thì nó lại chả chạy nhanh

prescolt · 10/6/20

gâu_ đã nói:
thế nó dùng phần cứng tương tự của ông để làm network service thì sao, đã bảo k8s nó chỉ quy định interface còn hiện thực thế nào do thằng tạo ra cluster k8s nó quyết định mà, phát biểu như thím chả khác nào tôi nói tôi có con xe 4 bánh, thím nhìn vào phán xe 4 bánh chạy chậm lắm trong khi thực tế thì nếu tôi gắn động cơ công suất cao thì nó lại chả chạy nhanh

Với model caliso nếu muốn ko bị chết ngay iptables thì phải đấu nối từ calixx (tap interface) vào ethx qua virtual sw (ví dụ openvswitch , linux bridge , hoặc open Flow chỉ layer 2). Nếu có acl thì là ebtables layer 2 (MAC-physical PORT trên switch ảo), chỉ có MAC ko có IP. Mô hình này gọi là flatnet, phần route sẽ nằm ngoài. C1,C2, firewall layer 3 cũng nằm ngoài C1,C2 ... sử dụng IP public có thể hiểu được từ bên ngoài internet, ko thể sử dụng ip lớp C. Và hiện tại K8S hoàn toàn ko có áp dụng mô hình này, căng lắm là float IP, tức là DNAT, bỏ routing đi, giá rẽ, moi ông một micro service, scale hang trăm theo Y , ip public éo nào chịu cho thấu. Cỏn nếu đã dùng flatnet thì xài container làm gì nữa, người ta xài VPS mẹ rồi.

Chậm hiểu vãi

Nipin · 10/6/20

Nix đã nói:
Đó là assumely bad practice chứ ko phải là ko chạy đc trong docker..
Thêm nữa, đã là practice thì sẽ có case good hoặc bad, production db docker đc xem là bad practice vì generally isolated filesystem, tuy nhiên nếu config mount data volume ra host và manage/backup tốt thì lại solve đc vấn đề đó, trong khi lại tận dụng đc ưu điểm của docker là isolate đc các db instance, tránh trường hợp các service dùng chung db instance và gây crash.

tôi tưởng best practice là mỗi service một machine chứ nhỉ? mấy vụ maintain/backup/snapshot các kiểu cũng đỡ nhức đầu hơn hẳn... tất nhiên network latency là một vấn đề, cơ mà đã "web scale" (lol) thì phải dùng k8s, phải dùng cả chục cả trăm cái node chứ ai lại chỉ dùng một cái máy.
// ờ tôi nói vui thế thôi, bạn nào đừng đọc word to word rồi phản biện, hôm nay tôi lười không trả lời đâu.

kyo_pyro · 10/6/20

Phục bác @prescolt kiên trì vãi chưởng :burn_joss_stick:

. Giải thích cho người không muốn hiểu

gâu_ · 10/6/20

prescolt đã nói:
Với model caliso nếu muốn ko bị chết ngay iptables thì phải đấu nối từ calixx (tap interface) vào ethx qua virtual sw (ví dụ openvswitch , linux bridge , hoặc open Flow chỉ layer 2). Nếu có acl thì là ebtables layer 2 (MAC-physical PORT trên switch ảo), chỉ có MAC ko có IP. Mô hình này gọi là flatnet, phần route sẽ nằm ngoài. C1,C2, firewall layer 3 cũng nằm ngoài C1,C2 ... sử dụng IP public có thể hiểu được từ bên ngoài internet, ko thể sử dụng ip lớp C. Và hiện tại K8S hoàn toàn ko có áp dụng mô hình này, căng lắm là float IP, tức là DNAT, bỏ routing đi, giá rẽ, moi ông một micro service, scale hang trăm theo Y , ip public éo nào chịu cho thấu. Cỏn nếu đã dùng flatnet thì xài container làm gì nữa, người ta xài VPS mẹ rồi.

Chậm hiểu vãi

https://blog.mellanox.com/2019/05/kubernetes-for-network-engineers/
trích dẫn 1 đoạn thôi nhé, không hiểu cứ đọc đâu ra rồi bắt phải thế này thế kia

In the Kubernetes networking model, in order to reduce complexity and make app porting seamless, a few rules are enforced as fundamental requirements:

Containers can communicate with all other containers without NAT.

Nodes can communicate with all containers without NAT, and vice-versa.

The IP that a container sees itself as is the same IP that others see it as.

There is a vast amount of network implementations for Kubernetes. Among all these implementations Flannel and Calico are probably the most popular ones that are used as network plugins for the Container Network Interface (CNI). CNI, can be seen as the simplest possible interface between container runtimes and network implementations, with the goal of creating a generic plugin-based networking solution for containers.

Bonus thêm cái spec của CNI để coi nó quy định những gì nhé
https://github.com/containernetworking/cni/blob/master/SPEC.md#routes

prescolt · 10/6/20

gâu_ đã nói:
https://blog.mellanox.com/2019/05/kubernetes-for-network-engineers/
trích dẫn 1 đoạn thôi nhé, không hiểu cứ đọc đâu ra rồi bắt phải thế này thế kia

Bonus thêm cái spec của CNI để coi nó quy định những gì nhé
https://github.com/containernetworking/cni/blob/master/SPEC.md#routes

Thôi tôi xin thua, tôi dám chắc bạn còn ko hiểu cái kia viết cái gì

Containers can communicate with all other containers without NAT. --> Cùng lớp mạng thì cần éo gì NAT, nếu container khác lớp thì virtual routing qua iptables, chẳng thằng nào đi cấp 1 nhóm service chạy khác pod
Nodes can communicate with all containers without NAT, and vice-versa. --> Từ chính node ket nối tới container cần éo gì NAT, chung 1 host interface đấu nối tẹt ga thì NAT chỗ nào
The IP that a container sees itself as is the same IP that others see it as. --> Có hệ thống nào mà để container cấp IP trùng nhau trên các Pod

Bạn ko hiểu về mạng, nhưng lại dốt bền Mục thứ 4 còn thiếu nó ko nói, để tôi nói cho nhé
Internet IP kết nối tới container phải thông qua NAT
Internet -(Routing)- >Node -(NAT)-container
Node -(direct inteface, tap bridge )-> container (local C class traffic same host, same node, same pod)
Node -(direct inteface, virtual routing --VXLAN)-> container (local C traffic cross CIDR, cross node, cross pod)
Mà tôi nghĩ bạn cũng ko hiểu mấy cái trên nên thôi tôi stop ở đây, thời gian éo đâu đi giải thích

nntgwww · 10/6/20

xindungbantoi2 đã nói:
code trên centos/fedora/ubuntu minimal, bản no gui là trùm phé nhen tụi bây.
mấy thằng gà xài gui bày đặt lên tiếng docker rồi portable mysql/mssql rồi portable mongodb nghe mệt thiệt chứ...

tụi bây đạt đến trình độ thứ thằng techlead trên youtube đi rồi hãy bàn cãi ) còn xài chuột chứng tỏ gà )

Hết ai lại đi hâm mộ thằng techlead :rolleyes:

Nix · 10/6/20

Nipin đã nói:
tôi tưởng best practice là mỗi service một machine chứ nhỉ? mấy vụ maintain/backup/snapshot các kiểu cũng đỡ nhức đầu hơn hẳn... tất nhiên network latency là một vấn đề, cơ mà đã "web scale" (lol) thì phải dùng k8s, phải dùng cả chục cả trăm cái node chứ ai lại chỉ dùng một cái máy.
// ờ tôi nói vui thế thôi, bạn nào đừng đọc word to word rồi phản biện, hôm nay tôi lười không trả lời đâu.

thì rõ là best practice là thế...tôi nói good thôi mà =))

) ...thì tất nhiên làm gì có cái container nào tốt hơn là cả cái machine đc...nhưng trend giờ ai cũng đú microservice, resources gì cũng trả bằng tiền cả mà

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

Member

Member

Member

Đã tốn tiền

Member

Member

Member

Đã tốn tiền

Member

Member

Đã tốn tiền

Member

Đã tốn tiền

Member

Member

Senior Member

Đã tốn tiền

Member

Member

Member

Chủ đề tương tự

Thống kê chủ đề

Chia sẻ trang này