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
thực ra thì nghĩ lại thì cũng possible, ngoài việc dùng docker ra thì cũng giống tôi chạy script thôi... có lẽ cái tôi quan tâm là quá trình CI/CD ra n cái website từ 1 source, cái đó không phải domain của docker rồi :/

cái quan trọng là docker nó chuẩn hóa cách đóng gói và chạy app, cùng 1 kiến thức đó có thể áp dụng cho nhiều loại app nhiều ngôn ngữ khác nhau, chứ viết script kia thì đặc thù cho 1 loại app nào đó thôi, vd như hồi trước tôi deploy node app lại phải dùng pm2, deploy java app thì phải tạo service bằng systemd, ... giờ thì tất cả chỉ cần đóng gói bằng docker, xong bỏ lên k8s chạy,
 
cái quan trọng là docker nó chuẩn hóa cách đóng gói và chạy app, cùng 1 kiến thức đó có thể áp dụng cho nhiều loại app nhiều ngôn ngữ khác nhau, chứ viết script kia thì đặc thù cho 1 loại app nào đó thôi, vd như hồi trước tôi deploy node app lại phải dùng pm2, deploy java app thì phải tạo service bằng systemd, ... giờ thì tất cả chỉ cần đóng gói bằng docker, xong bỏ lên k8s chạy,
ẹc, tôi deploy nodejs vẫn dùng systemd mà :v chính ra tôi thấy systemd mới là kiến thức áp dụng dc cho nhiều ngôn ngữ/hoàn cảnh khác nhau, mà cái này lại có sẵn không phải setup lằng nhằng. Tất nhiên massive scale thì k8s thì hợp lý hơn, cơ mà lúc đó tôi hi vọng là sẽ có thằng khác setup hộ :">

p/s: systemd tiện thế mà nhiều thằng anti kinh dị, vài tuần lại thấy lôi lên chửi :|
 
ẹc, tôi deploy nodejs vẫn dùng systemd mà :v chính ra tôi thấy systemd mới là kiến thức áp dụng dc cho nhiều ngôn ngữ/hoàn cảnh khác nhau, mà cái này lại có sẵn không phải setup lằng nhằng. Tất nhiên massive scale thì k8s thì hợp lý hơn, cơ mà lúc đó tôi hi vọng là sẽ có thằng khác setup hộ :">

p/s: systemd tiện thế mà nhiều thằng anti kinh dị, vài tuần lại thấy lôi lên chửi :censored:

rồi thím triển khai CI/CD với systemd thế nào, viết script cho jenkins chạy nữa à, thím cứ xài thử nhiều bọn CI/CD ở ngoài nó chỉ cần detect file Dockerfile trong repo là nó gợi ý sẵn các lựa chọn click click là xong cái CI/CD
diễn tả cũng hơi khó nhưng cơ bản là vầy, giờ thím có cái app chỉ cần đóng gói sẵn dạng docker thì mình tích hợp vào hệ thống + CI/CD trong 5-10p thôi, không cần quan tâm đó là ngôn ngữ gì
 
rồi thím triển khai CI/CD với systemd thế nào, viết script cho jenkins chạy nữa à, thím cứ xài thử nhiều bọn CI/CD ở ngoài nó chỉ cần detect file Dockerfile trong repo là nó gợi ý sẵn các lựa chọn click click là xong cái CI/CD
diễn tả cũng hơi khó nhưng cơ bản là vầy, giờ thím có cái app chỉ cần đóng gói sẵn dạng docker thì mình tích hợp vào hệ thống + CI/CD trong 5-10p thôi, không cần quan tâm đó là ngôn ngữ gì
thực ra tôi không phủ nhận là docker tiện, nhưng nhiều khi làm mấy thứ unconventional thì biết rõ về linux / sửa trực tiếp trên server các kiểu là điều bất khả kháng, hoặc ít nhất là cũng tiện hơn nhiều.

5-10 phút nghe thì ngắn, nhưng lúc deadline đến đít, lại gặp thằng dev gà code hay nhầm thì cũng khó chịu lắm. kiểu cái vụ phải deploy n sites tôi nói ở trên, mỗi lần deploy site mới thằng kia nó phải sửa lại source code của một cái webapp SSO khác để thêm CORS whitelist, lần nào cũng phải ngồi đợi nửa tiếng mỗi lần nó sửa code -> deploy (tôi chỉ là contractor, có rất nhiều phần không thuộc về kiểm soát của tôi). lúc đó nghĩ bụng, đệt có cái CORS thôi, tại sao không vào nginx config mà sửa trực tiếp trên đó mà phải lằng nhằng thế, 2h sáng cmnr... nói chung có rất nhiều lần dính thế này cho nên bài viết đầu tôi mới đưa ra quan điểm là cần dùng linux + làm quen công cụ của linux.

// nhân tiện thì hiện tại mấy cái toy projects tôi deploy toàn dùng git hook post-receiver, chạy script build + restart trực tiếp trên server, tuy đúng là primitive so với các bạn dùng ci/cd, k8s cơ mà tôi dùng nó mấy năm rồi thấy cũng chả có vấn đề gì. bạn nào thấy ci/cd quá overkill thì có thể tham khảo, tôi đảm bảo là trên thế giới không phải chỉ có mình tôi làm vậy đâu :)
 
5-10p là thời gian tích hợp lần đầu thôi thím, còn sau đó thì làm việc với code và git repo thôi chứ quan tâm gì nữa tới phần còn lại nữa đâu
dùng kiểu của thím đơn giản cho dự án nhỏ thôi, tới lúc cần autoscale thì chết đứng
 
dùng quen ssh, scp, rsync command các kiểu rồi có khi lại chán gui :v
thực ra tôi không phủ nhận là docker tiện, nhưng nhiều khi làm mấy thứ unconventional thì biết rõ về linux / sửa trực tiếp trên server các kiểu là điều bất khả kháng, hoặc ít nhất là cũng tiện hơn nhiều.

5-10 phút nghe thì ngắn, nhưng lúc deadline đến đít, lại gặp thằng dev gà code hay nhầm thì cũng khó chịu lắm. kiểu cái vụ phải deploy n sites tôi nói ở trên, mỗi lần deploy site mới thằng kia nó phải sửa lại source code của một cái webapp SSO khác để thêm CORS whitelist, lần nào cũng phải ngồi đợi nửa tiếng mỗi lần nó sửa code -> deploy (tôi chỉ là contractor, có rất nhiều phần không thuộc về kiểm soát của tôi). lúc đó nghĩ bụng, đệt có cái CORS thôi, tại sao không vào nginx config mà sửa trực tiếp trên đó mà phải lằng nhằng thế, 2h sáng cmnr... nói chung có rất nhiều lần dính thế này cho nên bài viết đầu tôi mới đưa ra quan điểm là cần dùng linux + làm quen công cụ của linux.

// nhân tiện thì hiện tại mấy cái toy projects tôi deploy toàn dùng git hook post-receiver, chạy script build + restart trực tiếp trên server, tuy đúng là primitive so với các bạn dùng ci/cd, k8s cơ mà tôi dùng nó mấy năm rồi thấy cũng chả có vấn đề gì. bạn nào thấy ci/cd quá overkill thì có thể tham khảo, tôi đảm bảo là trên thế giới không phải chỉ có mình tôi làm vậy đâu :)

Có tôi a ợ.
Cơ bản cũng vì nhu cầu chưa cần tới Docker làm j cũng chỉ có <10 cái nhỏ nên tôi chưa cần Docker làm j . Tôi có có script build run start stop sẻvice đủcả luôn.
Nên cần thì lên thẳng server mà xử.
P/s: Mà cái bộ editor của VOZ bị cái lỗi dính chữ khó chịu v~ n. Nói thì ngoác mồm kêu có lỗi đâu ( ko xài ếch xanh ếch vàng hay emoj j thêm nhé )
 
5-10p là thời gian tích hợp lần đầu thôi thím, còn sau đó thì làm việc với code và git repo thôi chứ quan tâm gì nữa tới phần còn lại nữa đâu
dùng kiểu của thím đơn giản cho dự án nhỏ thôi, tới lúc cần autoscale thì chết đứng
đến mức cần autoscale thì tôi cũng mừng :">
 
Lội page đọc hay quá. toàn các pro :adore: Mấy bác tiện cho em hỏi có cách nào bypass vụ google detect selenium không cho login không nhỉ?
 
Thread hay quá, tôi có vài cái vps 5$ thì xài k8s có đc ko :rolleyes:, hiện tại thì combo shell script + docker vẫn ổn. Trình tôi cũng ko hinh dung ra k8s để làm gì =((
 
Thread hay quá, tôi có vài cái vps 5$ thì xài k8s có đc ko :rolleyes:, hiện tại thì combo shell script + docker vẫn ổn. Trình tôi cũng ko hinh dung ra k8s để làm gì =((

k8s toàn GUI nhấn nhấn ấy mà, sao pro bằng shell đc. Phen muốn trải nghiệm thì có mấy thằng như digital oc nó cho phen free node master, phen chỉ cần trả tiền cho worker node thôi (min là $10).

Sent using vozFApp
 
thực ra tôi không phủ nhận là docker tiện, nhưng nhiều khi làm mấy thứ unconventional thì biết rõ về linux / sửa trực tiếp trên server các kiểu là điều bất khả kháng, hoặc ít nhất là cũng tiện hơn nhiều.

5-10 phút nghe thì ngắn, nhưng lúc deadline đến đít, lại gặp thằng dev gà code hay nhầm thì cũng khó chịu lắm. kiểu cái vụ phải deploy n sites tôi nói ở trên, mỗi lần deploy site mới thằng kia nó phải sửa lại source code của một cái webapp SSO khác để thêm CORS whitelist, lần nào cũng phải ngồi đợi nửa tiếng mỗi lần nó sửa code -> deploy (tôi chỉ là contractor, có rất nhiều phần không thuộc về kiểm soát của tôi). lúc đó nghĩ bụng, đệt có cái CORS thôi, tại sao không vào nginx config mà sửa trực tiếp trên đó mà phải lằng nhằng thế, 2h sáng cmnr... nói chung có rất nhiều lần dính thế này cho nên bài viết đầu tôi mới đưa ra quan điểm là cần dùng linux + làm quen công cụ của linux.

// nhân tiện thì hiện tại mấy cái toy projects tôi deploy toàn dùng git hook post-receiver, chạy script build + restart trực tiếp trên server, tuy đúng là primitive so với các bạn dùng ci/cd, k8s cơ mà tôi dùng nó mấy năm rồi thấy cũng chả có vấn đề gì. bạn nào thấy ci/cd quá overkill thì có thể tham khảo, tôi đảm bảo là trên thế giới không phải chỉ có mình tôi làm vậy đâu :)

Cái đoạn bôi đen thì tôi thấy do bên sever deploy thế nào nữa.

Có 1 cái server thì có thể SSH thẳng vào rồi sửa.

Có n cái server, hay chạy qua docker, AWS EB hay mấy cái loại autoscale thì nó khác chứ. Ko lẽ SSH vao sửa. Mà đã auto scale thì web nào lớn no scale lên chục cái container cũng có.

Mà đã production đi làm cty thì chả ai SSH vào sửa kiểu vậy. Có đc credential, chứng chỉ để vào production éo dễ. Cái đó system admin nắm chứ dev có mà dc cầm.

Tôi thấy anh nói đợi thằng dev sửa code thì tôi chắc chắn nó ko có xài thể loại 1 cái server đâu.

Với lại CORS whitelist thì sửa trong code là đúng. Sửa bên server mốt quên mất thì sao?.

(Khúc dưới ko liên quan nữa nhá)
BTW còn chuyện docker gì gi đó trong 2pic này tôi thấy đa phần anh em nào xài thì cũng đi làm cty rồi. Giải pháp đó đáp ứng chuyện công việc project lớn. Nhu cầu thuần về app.

Còn ba cái pet project, chạy mấy cái script thuê cái VPS thôi rôi SSH deploy bằng tay là đúng thôi. Nhu cầu sao lựa cơm gắp mắm.

Giờ với anh mod thì docker có thể đáp ứng 8 90% usecase. Còn 10% usecase như anh Nip thì nó đặc biệt ko xài docker là bình thường thôi. Mà cái gì cũng có pros cons cả. Cãi nhau ỏm tỏi. 1 bên thì lôi special usecase, 1 bên thì general usecase cãi nhau tới tết công gô.
 
Sửa lần cuối:
>Có 1 cái server thì có thể SSH thẳng vào rồi sửa.

>Có n cái server, hay chạy qua docker, AWS EB hay mấy cái loại autoscale thì nó khác chứ. Ko lẽ SSH vao sửa. Mà đã auto scale thì web nào lớn no scale lên chục cái container cũng có.

nếu vẫn load balance bằng nginx thì chỉ cần ssh vào cái node load balancer đó sửa trực tiếp nginx thôi chứ đâu phải là sửa n cái server?
cơ mà tôi chưa biết mùi autoscale thế nào, có khi dùng k8s các kiểu cả nginx cũng là managed hết không có quyền sửa nginx config thì các bạn đúng :)
 
Còn giờ quay lại mục đích chính của cái 2pic này thì tôi thấy dùng linux hay mac cũng ok thôi. Tôi thấy d
>Có 1 cái server thì có thể SSH thẳng vào rồi sửa.

>Có n cái server, hay chạy qua docker, AWS EB hay mấy cái loại autoscale thì nó khác chứ. Ko lẽ SSH vao sửa. Mà đã auto scale thì web nào lớn no scale lên chục cái container cũng có.

nếu vẫn load balance bằng nginx thì chỉ cần ssh vào cái node load balancer đó sửa trực tiếp nginx thôi chứ đâu phải là sửa n cái server?
cơ mà tôi chưa biết mùi autoscale thế nào, có khi dùng k8s các kiểu cả nginx cũng là managed hết không có quyền sửa nginx config thì các bạn đúng :)
load balancer cũng ko chắc chỉ có 1 cái nữa là. Nên khi đã autoscale thì nên quên cái chuyện SSH đi. Thường cloud provider nó cung cấp template để chạy thêm lệnh, modify server. Deploy thì nó read cái đó rồi thi hành theo thôi.

Mấy cái autoscale thì cty tôi chạy hệ sinh thái AWS thôi. Tôi cũng chưa vô dc project nào xài docker. Toàn nghịch localhost. Nhưng đảm bảo deploy pet project gì đó thì chắc chắn ko xài.

Nhưng căn bản thì SSH sửa file config là ko work trong case đó.
 
Còn giờ quay lại mục đích chính của cái 2pic này thì tôi thấy dùng linux hay mac cũng ok thôi. Tôi thấy d

load balancer cũng ko chắc chỉ có 1 cái nữa là. Nên khi đã autoscale thì nên quên cái chuyện SSH đi. Thường cloud provider nó cung cấp template để chạy thêm lệnh, modify server. Deploy thì nó read cái đó rồi thi hành theo thôi.
???

ý tôi là, trừ khi các bạn nhà giàu tới level của mấy thằng như google, netflix, nó route từ IP (một IP có thể trỏ đến nhiều server khác nhau tuỳ vị trí), còn lại bình thường thì dù có deploy ra một đống server thì đằng trước vẫn phải có một cái reversed proxy để load balance (thường dùng nginx) là cái IP mà domain name record trả vào đúng không?

hay theo ý bạn là không có?
 
???

ý tôi là, trừ khi các bạn nhà giàu tới level của mấy thằng như google, netflix, nó route từ IP (một IP có thể trỏ đến nhiều server khác nhau tuỳ vị trí), còn lại bình thường thì dù có deploy ra một đống server thì đằng trước vẫn phải có một cái reversed proxy để load balance (thường dùng nginx) là cái IP mà domain name record trả vào đúng không?

hay theo ý bạn là không có?
Cty tôi xài AWS thôi. Xài AWS ELB thi đâu có SSH vô dc.
 
https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/java-se-nginx.html
theo tôi đọc cái này thì tuy không ssh trực tiếp vào server thì vẫn config trực tiếp dc nginx mà?
tất nhiên khác biệt bây giờ là bạn phải thành thạo aws dashboard, nhưng tôi thấy kiến thức vẫn tương tự thôi chứ có vứt đi hết đâu?

Tôi ko nhớ có chỉnh trong dashboard hay ko. Giờ ko có quyền vô pj nữa. Nhưng config anh lưu trong code thì nó mới bền lâu. Vì cái eb chạy nhiều môi trường như staging, production. Mỗi cái môi trường thì lại config nữa.

Bữa truocs penetration test bị tụi cty bắt là phải xóa cái dong request powered by Nginx trong cái HTTP header.

tạo cái thư mục .ebextension. rồi thêm 1 file config.


Mã:
files:
  /etc/nginx/conf.d/server_token_off.conf:
    mode: "000644"
    owner: root
    group: root
    content: |
      server_tokens off;

mỗi lần deploy thì thằng eb read cái file này rồi sửa lại. tắt cái server_token off. Còn code thì đẩy lên git, thôi. Sau này đảm bảo là đã config thêm cái gì đều nhớ. Cái config thì chung với src code mà. Nên nếu thằng dev server bên anh xài cái gì tương tự thằng này thì sửa code là đúng. Mà sửa xong phải deploy lại nên anh phải chờ cũng đúng thôi. Nó deploy lại src code. chứ ko phải mỗi config nên lâu là đúng.
 
Sửa lần cuối:
Tôi ko nhớ có chỉnh trong dashboard hay ko. Giờ ko có quyền vô pj nữa. Nhưng config anh lưu trong code thì nó mới bền lâu. Vì cái eb chạy nhiều môi trường như staging, production. Mỗi cái môi trường thì lại config nữa.

Bữa truocs penetration test bị tụi cty bắt là phải xóa cái dong request powered by Nginx trong cái HTTP header.

tạo cái thư mục .ebextension. rồi thêm 1 file config.


Mã:
files:
  /etc/nginx/conf.d/server_token_off.conf:
    mode: "000644"
    owner: root
    group: root
    content: |
      server_tokens off;

mỗi lần deploy thì thằng eb read cái file này rồi sửa lại. tắt cái server_token off. Còn code thì đẩy lên git, thôi. Sau này đảm bảo là đã config thêm cái gì đều nhớ. Cái config thì chung với src code mà. Nên nếu thằng dev server bên anh xài cái gì tương tự thằng này thì sửa code là đúng. Mà sửa xong phải deploy lại nên anh phải chờ cũng đúng thôi. Nó deploy lại src code. chứ ko phải mỗi config nên lâu là đúng.
tôi cũng đồng ý là cái gì lâu dài thì nhét hết vào code cho nó bền, cho nên lúc tôi nêu ví dụ kia tôi nói rõ là trong context nào mà. hotfix/dirtyfix là chuyện thường gặp chứ có phải là hiếm có lắm đâu?

thêm nữa giả sử là cái code kia là project cũ bạn cần maintain, mà project cũ chọn stack ngu mấy cái bạn cần đếch có thì phải làm sao (giả sử thôi nhé)? lúc đấy là quyết định đập bỏ xây lại từ đầu chấp nhận delay mấy tháng, hoặc mạo hiểm sửa code cũ tự thêm tính năng cuối cùng khả năng sẽ nát bét, hay sửa nó bằng mấy cái bên ngoài vừa nhanh tiện vừa an toàn... tất nhiên đây là giả sử thôi nhưng tôi muốn nhấn mạnh vào chỗ biết càng nhiều thì có càng nhiều lựa chọn.

p/s: nói generic vs special cũng không đúng, ngay từ đầu tôi đã bảo là có nhiều trường hợp dùng docker cũng không có ý nghĩa, là ai đó chê tôi không biết docker/không biết deploy vào cố ép tôi dùng docker cho trường hợp đó thôi.
 
tôi cũng đồng ý là cái gì lâu dài thì nhét hết vào code cho nó bền, cho nên lúc tôi nêu ví dụ kia tôi nói rõ là trong context nào mà. hotfix/dirtyfix là chuyện thường gặp chứ có phải là hiếm có lắm đâu?

thêm nữa giả sử là cái code kia là project cũ bạn cần maintain, mà project cũ chọn stack ngu mấy cái bạn cần đếch có thì phải làm sao (giả sử thôi nhé)? lúc đấy là quyết định đập bỏ xây lại từ đầu chấp nhận delay mấy tháng, hoặc mạo hiểm sửa code cũ tự thêm tính năng cuối cùng khả năng sẽ nát bét, hay sửa nó bằng mấy cái bên ngoài vừa nhanh tiện vừa an toàn... tất nhiên đây là giả sử thôi nhưng tôi muốn nhấn mạnh vào chỗ biết càng nhiều thì có càng nhiều lựa chọn.

p/s: nói generic vs special cũng không đúng, ngay từ đầu tôi đã bảo là có nhiều trường hợp dùng docker cũng không có ý nghĩa, là ai đó chê tôi không biết docker/không biết deploy vào cố ép tôi dùng docker cho trường hợp đó thôi.
Thì hotfix/dirtyfix nhưng phải xem tech stack nữa. nên ý tôi bảo khoan vội phán xet vì sao nó ko thể làm trong vòng 30s dc mà phải đơi 30p. dù sao hotfix 30p là ok rồi. Cái này cũng do staging ko kỹ thôi.

Còn đổi tech stack hay gì đó thì ít nhất cũng có cái tư liệu tham khảo cái file token off đó quên comment lý do thôi. chứ có comment thì tụi vào sau cũng hiểu vì sao cần config đó. Nói chung mấy cái đó xa quá rồi.
 
Thì hotfix/dirtyfix nhưng phải xem tech stack nữa. nên ý tôi bảo khoan vội phán xet. dù sao hotfix 30p là ok rồi.
không nói cái khác, theo cái ss của bạn thì bạn cũng đồng ý việc nhiều khi phải sửa nginx config đúng không?

mà cái kia không phải là hotfix, fix 1 lần mà 30p thì tôi cũng chịu, cái kia là thằng đó sửa trong code, mỗi lần sửa xong nó sẽ mất tầm 20~30p để cái code đó có hiệu lực thông qua ci/cd, aka nếu nó config (trong code) sai thì phải đợi deploy xong mới biết được, do có n websites cho nên lần deploy đó mất x phát 30p chứ không phải 1 lần là xong, khá nản (đừng hỏi tôi tại sao lại thọt thế, tôi cũng muốn biết).
 

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.836
Quay lại
Lên đầu trang