Xin chào tất cả mọi người!
Tôi thực sự muốn đi thẳng vào chủ đề, nhưng sẽ đúng hơn nếu kể một chút về câu chuyện của tôi:
Nhập
Tôi là một lập trình viên có kinh nghiệm trong việc phát triển các ứng dụng trang đơn giao diện người dùng, scala/java và nodejs trên máy chủ.
Trong một thời gian khá dài (chắc chắn là một vài hoặc ba năm), tôi đã cho rằng Docker là thiên đường và nói chung là một công cụ rất tuyệt vời và mọi nhà phát triển đều có thể sử dụng nó. Và từ đó, mọi nhà phát triển nên cài đặt Docker trên máy cục bộ của họ. Còn ý kiến của tôi thì sao, hãy xem qua các vị trí tuyển dụng được đăng trên cùng hh. Mỗi giây đều có đề cập đến docker và nếu bạn sở hữu nó, đây sẽ là lợi thế cạnh tranh của bạn 😉
Trên đường đi, tôi đã gặp nhiều người với thái độ khác nhau đối với Docker và hệ sinh thái của nó. Một số người cho rằng đây là một điều thuận tiện đảm bảo chức năng đa nền tảng. Người thứ hai không hiểu tại sao họ phải chạy trong container và lợi nhuận thu được từ việc đó là gì, người thứ ba không quan tâm và cũng không bận tâm (họ chỉ viết mã và về nhà - tôi ghen tị với họ, bởi đường :)
Lý do sử dụng
Tại sao tôi sử dụng docker? Có lẽ vì những lý do sau:
- Khởi chạy cơ sở dữ liệu, 99% ứng dụng sử dụng chúng
- khởi chạy nginx để phân phối giao diện người dùng và ủy quyền cho chương trình phụ trợ
- bạn có thể đóng gói ứng dụng trong một hình ảnh docker, bằng cách này, ứng dụng của tôi sẽ hoạt động ở bất cứ nơi nào docker tồn tại, vấn đề phân phối được giải quyết ngay lập tức
- khám phá dịch vụ ngay lập tức, bạn có thể tạo microservice, mỗi vùng chứa (được kết nối với mạng chung) có thể dễ dàng tiếp cận vùng chứa khác thông qua bí danh, rất tiện lợi
- Thật thú vị khi tạo một thùng chứa và “chơi” trong đó.
Điều tôi luôn KHÔNG thích ở docker:
- Để ứng dụng của tôi hoạt động, tôi cần chính Docker trên máy chủ. Tại sao tôi cần điều này nếu ứng dụng của tôi chạy trên jre hoặc nodejs và môi trường dành cho chúng đã có trên máy chủ?
- nếu tôi muốn chạy hình ảnh được lắp ráp cục bộ (riêng tư) của mình trên một máy chủ từ xa thì tôi cần kho lưu trữ docker của riêng mình, tôi cần sổ đăng ký để hoạt động ở đâu đó và tôi cũng cần định cấu hình https, vì docker cli chỉ hoạt động trên https. Ôi chết tiệt... tất nhiên là có các tùy chọn để lưu hình ảnh cục bộ thông qua
docker savevà chỉ gửi hình ảnh qua scp... Nhưng đó là chuyển động cơ thể rất nhiều. Và bên cạnh đó, nó giống như một giải pháp “nạng” cho đến khi kho lưu trữ của riêng bạn xuất hiện docker-compose. Nó chỉ cần thiết để chạy container. Đó là tất cả. Anh ấy không thể làm gì khác.Docker-composecó rất nhiều phiên bản của tập tin, cú pháp riêng của nó. Cho dù nó có được khai báo đến đâu, tôi cũng không muốn đọc tài liệu của họ. Tôi sẽ không cần nó ở bất cứ nơi nào khác.- Khi làm việc nhóm, hầu hết mọi người viết Dockerfile rất quanh co, không hiểu nó được cache như thế nào, thêm mọi thứ cần và không cần vào image, kế thừa từ image không có trong Dockerhub hoặc kho lưu trữ riêng, tạo ra một số thứ họ cần và không cần.
docker-composecác tập tin có cơ sở dữ liệu và không có gì tồn tại. Đồng thời, các nhà phát triển tự hào tuyên bố rằng Docker rất tuyệt, mọi thứ đều hoạt động cục bộ cho họ và quan trọng là HR viết vào vị trí tuyển dụng: “Chúng tôi sử dụng Docker và chúng tôi cần một ứng viên có kinh nghiệm làm việc như vậy”. - Tôi liên tục bị ám ảnh bởi những suy nghĩ về việc nâng cao mọi thứ trong Docker: postgresql, kafka, redis. Thật đáng tiếc là không phải mọi thứ đều hoạt động trong vùng chứa, không phải mọi thứ đều dễ dàng cấu hình và chạy. Điều này được hỗ trợ bởi các nhà phát triển bên thứ ba chứ không phải bởi chính nhà cung cấp. Và nhân tiện, câu hỏi ngay lập tức được đặt ra: các nhà cung cấp không lo lắng về việc duy trì sản phẩm của họ trong Docker, tại sao lại như vậy, có thể họ biết điều gì đó?
- Câu hỏi luôn đặt ra về tính bền vững của dữ liệu vùng chứa. và sau đó bạn nghĩ, tôi có nên gắn thư mục máy chủ hay tạo ổ đĩa docker hay tạo vùng chứa dữ liệu hiện tại không?
deprecated? Nếu tôi gắn một thư mục thì tôi cần đảm bảo rằng uid và gid của người dùng trong vùng chứa khớp với id của người dùng đã khởi chạy vùng chứa, nếu không các tệp do vùng chứa tạo sẽ được tạo bằng quyền root. Nếu tôi sử dụngvolumethì dữ liệu sẽ chỉ được tạo trong một số/usr/*và sẽ có câu chuyện tương tự với uid và gid như trong trường hợp đầu tiên. Nếu bạn đang khởi chạy một thành phần của bên thứ ba, bạn cần đọc tài liệu và tìm câu trả lời cho câu hỏi: “Thành phần ghi tệp trong thư mục vùng chứa nào?”
Tôi luôn không thích việc phải mày mò với Docker quá lâu ở giai đoạn đầu: Tôi đã tìm ra cách khởi chạy các vùng chứa, những hình ảnh nào để khởi chạy, tạo các Makefile chứa bí danh cho các lệnh Docker dài. Tôi ghét docker-compose vì tôi không muốn tìm hiểu một công cụ khác trong hệ sinh thái docker. VÀ docker-compose up Điều đó làm tôi khó chịu, đặc biệt nếu họ vẫn gặp nhau ở đó build các công trình xây dựng, thay vì các hình ảnh đã được lắp ráp sẵn. Tất cả những gì tôi thực sự muốn là tạo ra một sản phẩm hiệu quả và nhanh chóng. Nhưng tôi không thể tìm ra cách sử dụng docker.
Giới thiệu Ansible
Gần đây (ba tháng trước), tôi đã làm việc với một nhóm DevOps, hầu hết mọi thành viên trong nhóm đều có thái độ tiêu cực với Docker. Vì lý do:
- docker quy tắc iptables (mặc dù bạn có thể tắt nó trong daemon.json)
- docker bị lỗi và chúng tôi sẽ không chạy nó trong phiên bản chính thức
- nếu docker daemon gặp sự cố thì tất cả các container có cơ sở hạ tầng đều gặp sự cố tương ứng
- không cần docker
- tại sao docker nếu có Ansible và máy ảo
Cũng ở công việc đó, tôi được làm quen với một công cụ khác - Ansible. Tôi đã nghe về nó một lần, nhưng tôi không cố gắng viết vở kịch của riêng mình. Và bây giờ tôi bắt đầu viết nhiệm vụ của mình và sau đó tầm nhìn của tôi hoàn toàn thay đổi! Bởi vì tôi nhận ra: Ansible có các mô-đun để chạy cùng một bộ chứa docker, bản dựng hình ảnh, mạng, v.v. và các bộ chứa có thể chạy không chỉ cục bộ mà còn trên các máy chủ từ xa! Niềm vui của tôi không có giới hạn - Tôi đã tìm thấy một công cụ BÌNH THƯỜNG và vứt bỏ các tệp Makefile và docker-compose của mình, chúng được thay thế bằng các tác vụ yaml. Mã đã được giảm bằng cách sử dụng các cấu trúc như loop, when, Vv
Docker để chạy các thành phần của bên thứ ba như cơ sở dữ liệu
Gần đây tôi đã làm quen với đường hầm ssh. Hóa ra việc “chuyển tiếp” cổng của máy chủ từ xa sang cổng cục bộ là rất dễ dàng. Máy chủ từ xa có thể là máy trên đám mây hoặc máy ảo chạy trong VirtualBox. Nếu đồng nghiệp của tôi hoặc tôi cần một cơ sở dữ liệu (hoặc một số thành phần bên thứ ba khác), chúng tôi có thể chỉ cần khởi động máy chủ với thành phần này và tắt nó khi không cần đến máy chủ. Chuyển tiếp cổng mang lại hiệu quả tương tự như cơ sở dữ liệu chạy trong vùng chứa docker.
Lệnh này chuyển tiếp cổng cục bộ của tôi tới một máy chủ từ xa chạy postgresql:
ssh -L 9000: localhost: 5432 [email được bảo vệ]
Sử dụng máy chủ từ xa sẽ giải quyết được vấn đề phát triển nhóm. Một máy chủ như vậy có thể được nhiều nhà phát triển sử dụng cùng một lúc; họ không cần phải có khả năng định cấu hình postgresql, hiểu Docker và những điều phức tạp khác. Trên máy chủ từ xa, bạn có thể cài đặt cùng một cơ sở dữ liệu trong Docker nếu khó cài đặt một phiên bản cụ thể. Tất cả những gì nhà phát triển cần là cung cấp quyền truy cập ssh!
Gần đây tôi đã đọc được rằng đường hầm SSH là một chức năng hạn chế của VPN thông thường! Bạn có thể chỉ cần cài đặt OpenVPN hoặc các triển khai VPN khác, thiết lập cơ sở hạ tầng và cung cấp cho các nhà phát triển sử dụng. Điều này thật tuyệt vời!
May mắn thay, AWS, GoogleCloud và những dịch vụ khác cung cấp cho bạn một năm sử dụng miễn phí, vì vậy hãy sử dụng chúng! Chúng có giá rẻ nếu bạn tắt chúng khi không sử dụng. Tôi luôn tự hỏi tại sao tôi lại cần một máy chủ từ xa như gcloud, có vẻ như tôi đã tìm thấy chúng.
Là một máy ảo cục bộ, bạn có thể sử dụng cùng một Alpine, được sử dụng tích cực trong các vùng chứa docker. À, hoặc một số bản phân phối nhẹ khác để máy khởi động nhanh hơn.
Điểm mấu chốt: bạn có thể và nên chạy cơ sở dữ liệu cũng như các tính năng cơ sở hạ tầng khác trên máy chủ từ xa hoặc trong hộp ảo. Tôi không cần docker cho những mục đích này.
Một chút về hình ảnh và phân phối docker
Tôi đã viết rồi trong đó tôi muốn truyền đạt rằng việc sử dụng hình ảnh docker không mang lại bất kỳ sự đảm bảo nào. Hình ảnh Docker chỉ cần thiết để tạo vùng chứa docker. Nếu bạn đang nâng cấp lên hình ảnh docker, thì bạn đang nâng cấp để sử dụng các vùng chứa docker và bạn sẽ chỉ sử dụng chúng.
Bạn đã thấy ở đâu mà các nhà phát triển phần mềm chỉ chuyển sản phẩm của họ trong hình ảnh docker chưa?
Kết quả của hầu hết các sản phẩm là các tệp nhị phân cho một nền tảng cụ thể; chúng chỉ được thêm vào hình ảnh docker, được kế thừa từ nền tảng mong muốn. Bạn có bao giờ thắc mắc tại sao lại có nhiều hình ảnh tương tự nhau trên dockerhub không? Nhập nginx chẳng hạn, bạn sẽ thấy 100500 hình ảnh từ những người khác nhau. Những người này không tự phát triển nginx, họ chỉ đơn giản thêm nginx chính thức vào hình ảnh docker của họ và thêm vào đó các cấu hình của riêng họ để thuận tiện cho việc khởi chạy các container.
Nói chung, bạn có thể chỉ cần lưu trữ nó trong tgz, nếu ai đó cần chạy nó trong docker, thì hãy để họ thêm tgz vào Dockerfile, kế thừa từ môi trường mong muốn và tạo các bun bổ sung không thay đổi chính ứng dụng trong tgz. Bất cứ ai tạo hình ảnh docker sẽ biết tgz là gì và anh ta cần làm gì. Đây là cách tôi sử dụng docker
Tóm lại: Tôi không cần đăng ký docker, tôi sẽ sử dụng một số loại S3 hoặc chỉ lưu trữ tệp như google drive/dropbox
Docker trong CI
Tất cả các công ty tôi từng làm việc đều giống nhau. Họ thường là cửa hàng tạp hóa. Nghĩa là, họ có một ứng dụng, một nhóm công nghệ (à, có thể là một vài hoặc ba ngôn ngữ lập trình).
Các công ty này sử dụng docker trên máy chủ của họ nơi quy trình CI chạy. Câu hỏi: Tại sao bạn cần xây dựng dự án trong vùng chứa docker trên máy chủ của mình? Tại sao không chỉ chuẩn bị môi trường cho quá trình xây dựng, chẳng hạn như viết Playbook Ansible sẽ cài đặt các phiên bản cần thiết của nodejs, php, jdk, sao chép khóa ssh, v.v. vào máy chủ nơi quá trình xây dựng sẽ diễn ra?
Bây giờ tôi hiểu rằng điều này đang tự bắn vào chân mình, bởi vì docker không mang lại bất kỳ lợi nhuận nào với sự cô lập của nó. Các vấn đề tôi gặp phải với CI trong docker:
- một lần nữa bạn cần một hình ảnh docker để xây dựng. bạn cần tìm một hình ảnh hoặc viết dockerfile của riêng bạn.
- 90% là bạn cần chuyển tiếp một số khóa ssh, dữ liệu bí mật mà bạn không muốn ghi vào hình ảnh docker.
- vùng chứa được tạo và chết, tất cả bộ đệm sẽ bị mất cùng với nó. bản dựng tiếp theo sẽ tải xuống lại tất cả các phần phụ thuộc của dự án, việc này tốn thời gian và không hiệu quả, còn thời gian là tiền bạc.
Các nhà phát triển không xây dựng dự án trong các container docker (tôi thực sự đã từng là một người hâm mộ như vậy, tôi cảm thấy tiếc cho bản thân mình trong quá khứ xD). Trong java có thể có nhiều phiên bản và thay đổi chúng bằng một lệnh thành phiên bản bạn cần ngay bây giờ. Trong nodejs cũng vậy, có nvm.
Đầu ra
Tôi tin rằng docker là một công cụ rất mạnh mẽ và linh hoạt, đây chính là nhược điểm của nó (nghe lạ nhỉ, đúng vậy). Với sự trợ giúp của nó, các công ty có thể dễ dàng sử dụng nó khi cần thiết và không cần thiết. Các nhà phát triển khởi chạy vùng chứa của họ, một số môi trường của họ, sau đó tất cả đều được đưa vào CI và sản xuất một cách suôn sẻ. Nhóm DevOps đang viết một số loại mã để chạy các vùng chứa này.
Chỉ sử dụng docker trên gần đây nhất giai đoạn trong quy trình làm việc của bạn, đừng kéo nó vào dự án ngay từ đầu. Nó sẽ không giải quyết được vấn đề kinh doanh của bạn. Anh ấy sẽ chỉ chuyển vấn đề sang cấp độ KHÁC và đưa ra giải pháp của riêng mình, bạn sẽ phải làm việc gấp đôi.
Khi cần docker: Tôi đi đến kết luận rằng docker rất giỏi trong việc tối ưu hóa một quy trình nhất định, nhưng không giỏi trong việc xây dựng chức năng cơ bản
Nếu bạn vẫn quyết định sử dụng docker thì:
- cực kỳ cẩn thận
- đừng ép các nhà phát triển sử dụng docker
- bản địa hóa việc sử dụng nó ở một nơi, không trải rộng nó trên tất cả các kho lưu trữ Dockefile và docker-compose
PS:
- Gần đây tôi đã gặp và họ nói rằng nó hoạt động rất tốt với Ansible và cho phép bạn thống nhất quá trình xây dựng hình ảnh (bao gồm cả hình ảnh docker)
Cảm ơn bạn đã đọc, chúc bạn có những quyết định sáng suốt trong công việc và những ngày làm việc hiệu quả!
Nguồn: www.habr.com