Bằng cách nào đó, tại một thời điểm, tôi quyết định viết một bài báo về việc phân phối dưới dạng các thùng chứa Docker và gói gỡ lỗi, nhưng khi bắt đầu, vì lý do nào đó, tôi đã bị đưa trở lại thời kỳ xa xôi của những chiếc máy tính cá nhân đầu tiên và thậm chí cả máy tính. Nói chung, thay vì so sánh khô khan giữa docker và deb, chúng tôi có những suy nghĩ này về chủ đề tiến hóa mà tôi trình bày để bạn xem xét.
Bất kỳ sản phẩm nào, bất kể là gì, bằng cách nào đó đều phải đến được máy chủ của sản phẩm, phải được cấu hình và khởi chạy. Đó là những gì bài viết này sẽ nói về.
Tôi sẽ nghĩ trong bối cảnh lịch sử, “những gì tôi thấy là những gì tôi hát về”, những gì tôi thấy khi mới bắt đầu viết mã và những gì tôi quan sát được bây giờ, những gì bản thân chúng tôi đang sử dụng vào lúc này và tại sao. Bài viết không giả vờ là một nghiên cứu chính thức, một số điểm còn bỏ sót, đây là quan điểm cá nhân của tôi về chuyện xưa và nay.
Vì vậy, ngày xưa... phương pháp truyền tải sớm nhất mà tôi tìm thấy là băng cassette từ máy ghi âm. Tôi có một chiếc máy tính BK-0010.01...
Thời đại của máy tính
Không, thậm chí còn có một khoảnh khắc sớm hơn nữa, còn có một chiếc máy tính и .
Vì thế khi tôi có , khi đó cách để chuyển chương trình là một mảnh giấy thông thường đựng trong hộp có viết chương trình, nếu cần, để chạy chương trình theo cách thủ công, nó sẽ được ghi vào máy tính. Nếu bạn muốn chơi (vâng, ngay cả chiếc máy tính cổ xưa này cũng có trò chơi) - bạn ngồi xuống và nhập chương trình vào máy tính. Đương nhiên, khi tắt máy tính, chương trình biến mất vào quên lãng. Ngoài các mã máy tính do chính tay ông viết ra trên giấy, các chương trình này còn được xuất bản trên các tạp chí “Radio” và “Technology for Youth”, đồng thời cũng được xuất bản thành sách vào thời đó.
Sự sửa đổi tiếp theo là một chiếc máy tính , nó đã có một số đặc điểm giống như lưu trữ dữ liệu cố định. Giờ đây, trò chơi hoặc chương trình không cần phải nhập thủ công mà sau khi thực hiện một số đường chuyền ma thuật bằng các nút, nó sẽ tự tải.
Kích thước của chương trình lớn nhất trong máy tính là 105 bước và kích thước của bộ nhớ vĩnh viễn trong MK-52 là 512 bước.
Nhân tiện, nếu có những người hâm mộ những chiếc máy tính này đang đọc bài viết này, thì trong quá trình viết bài, tôi đã tìm thấy cả trình mô phỏng máy tính cho Android và các chương trình dành cho nó. Chuyển tiếp về quá khứ!
Một đoạn lạc đề ngắn về MK-52 (từ Wikipedia)
MK-52 bay vào vũ trụ trên tàu vũ trụ Soyuz TM-7. Nó được cho là sẽ được sử dụng để tính toán quỹ đạo hạ cánh trong trường hợp máy tính trên máy bay bị lỗi.
Từ năm 52, MK-1988 với bộ mở rộng bộ nhớ Elektronika-Astro đã được cung cấp cho các tàu Hải quân như một phần của bộ máy tính dẫn đường.
Những chiếc máy tính cá nhân đầu tiên
Chúng ta hãy quay trở lại thời gian . Rõ ràng là ở đó có nhiều bộ nhớ hơn và việc nhập mã từ một tờ giấy không còn là một lựa chọn nữa (mặc dù lúc đầu tôi chỉ làm vậy vì đơn giản là không có phương tiện nào khác). Băng âm thanh dành cho máy ghi âm đang trở thành phương tiện lưu trữ và cung cấp phần mềm chính.
Bộ lưu trữ trên băng cassette thường ở dạng một hoặc hai tệp nhị phân, mọi thứ khác đều được chứa bên trong. Độ tin cậy rất thấp, tôi phải giữ 2-3 bản chương trình. Thời gian tải cũng đáng thất vọng và những người đam mê đã thử nghiệm các cách mã hóa tần số khác nhau để khắc phục những thiếu sót này. Vào thời điểm đó, bản thân tôi vẫn chưa tham gia vào lĩnh vực phát triển phần mềm chuyên nghiệp (không tính các chương trình đơn giản trong BASIC), vì vậy, rất tiếc, tôi sẽ không kể chi tiết mọi thứ được sắp xếp bên trong như thế nào. Thực tế là máy tính chỉ có RAM phần lớn đã quyết định tính đơn giản của sơ đồ lưu trữ dữ liệu.
Sự xuất hiện của phương tiện lưu trữ lớn và đáng tin cậy
Sau đó, đĩa mềm xuất hiện, quá trình sao chép được đơn giản hóa và độ tin cậy tăng lên.
Nhưng tình hình chỉ thay đổi đáng kể khi các kho lưu trữ cục bộ đủ lớn xuất hiện dưới dạng ổ cứng.
Kiểu phân phối đang thay đổi về cơ bản: các chương trình cài đặt xuất hiện quản lý quá trình định cấu hình hệ thống, cũng như dọn dẹp sau khi gỡ bỏ, vì các chương trình không chỉ được đọc vào bộ nhớ mà còn được sao chép vào bộ nhớ cục bộ, từ đó bạn cần phải có thể xóa những thứ không cần thiết nếu cần thiết.
Đồng thời, độ phức tạp của phần mềm được cung cấp ngày càng tăng.
Số lượng tệp trong quá trình phân phối tăng từ vài lên hàng trăm và hàng nghìn, xung đột giữa các phiên bản thư viện và những niềm vui khác bắt đầu khi các chương trình khác nhau sử dụng cùng một dữ liệu.
Vào thời điểm đó, sự tồn tại của Linux vẫn chưa mở ra với tôi; tôi sống trong thế giới của MS DOS và sau này là Windows, và viết bằng Borland Pascal và Delphi, đôi khi hướng tới C++. Nhiều người đã sử dụng InstallShield để phân phối sản phẩm vào thời điểm đó. , đã giải quyết khá thành công mọi nhiệm vụ được giao trong việc triển khai và cấu hình phần mềm.
kỷ nguyên Internet
Dần dần, sự phức tạp của các hệ thống phần mềm ngày càng trở nên phức tạp hơn; từ các ứng dụng nguyên khối và máy tính để bàn có sự chuyển đổi sang các hệ thống phân tán, máy khách mỏng và dịch vụ vi mô. Bây giờ bạn cần định cấu hình không chỉ một chương trình mà cả một tập hợp chúng và để tất cả chúng hoạt động cùng nhau.
Khái niệm hoàn toàn thay đổi, Internet xuất hiện, thời đại của dịch vụ đám mây đã đến. Cho đến nay, chỉ ở giai đoạn đầu, dưới dạng website, chưa có ai đặc biệt mơ tới dịch vụ. nhưng đó là một bước ngoặt trong cả quá trình phát triển và phân phối ứng dụng.
Đối với bản thân tôi, tôi lưu ý rằng tại thời điểm đó đã có sự thay đổi trong các thế hệ nhà phát triển (hoặc chỉ trong môi trường của tôi), và có cảm giác rằng tất cả các phương thức phân phối cũ tốt đã bị lãng quên ngay lập tức và mọi thứ bắt đầu lại từ đầu. bắt đầu: tất cả việc giao hàng bắt đầu được thực hiện theo kịch bản đầu gối và tự hào gọi đó là “Giao hàng liên tục”. Trên thực tế, một thời kỳ hỗn loạn đã bắt đầu, khi cái cũ bị lãng quên và không được sử dụng, còn cái mới đơn giản là không tồn tại.
Tôi nhớ những lần khi ở công ty nơi tôi làm việc (tôi sẽ không nêu tên), thay vì xây dựng thông qua ant (maven chưa phổ biến hoặc hoàn toàn không tồn tại), mọi người chỉ cần thu thập các lọ trong IDE và thanh thản cam kết nó ở SVN. Theo đó, việc triển khai bao gồm lấy tệp từ SVN và sao chép tệp qua SSH vào máy mong muốn. Nó thật đơn giản và vụng về.
Đồng thời, việc phân phối các trang web đơn giản bằng PHP được thực hiện theo cách rất nguyên thủy bằng cách sao chép tệp đã sửa qua FTP vào máy đích. Đôi khi không có điều đó - mã được chỉnh sửa trực tiếp trên máy chủ sản phẩm và sẽ đặc biệt sang trọng nếu có bản sao lưu ở đâu đó.
Gói RPM và DEB
Mặt khác, với sự phát triển của Internet, các hệ thống giống UNIX bắt đầu ngày càng phổ biến, đặc biệt, đó là thời điểm tôi phát hiện ra RedHat Linux 6, khoảng năm 2000. Đương nhiên, cũng có một số phương tiện nhất định để phân phối phần mềm; theo Wikipedia, RPM với tư cách là trình quản lý gói chính đã xuất hiện vào năm 1995, trong phiên bản RedHat Linux 2.0. Và kể từ đó cho đến ngày nay, hệ thống đã được cung cấp dưới dạng gói RPM và tồn tại và phát triển khá thành công.
Các bản phân phối của họ Debian đi theo con đường tương tự và triển khai phân phối dưới dạng gói gỡ lỗi, điều này vẫn không thay đổi cho đến ngày nay.
Trình quản lý gói cho phép bạn tự phân phối các sản phẩm phần mềm, định cấu hình chúng trong quá trình cài đặt, quản lý sự phụ thuộc giữa các gói khác nhau, xóa sản phẩm và dọn sạch các mục không cần thiết trong quá trình gỡ cài đặt. Những thứ kia. phần lớn, đó là tất cả những gì cần thiết, đó là lý do tại sao chúng tồn tại trong nhiều thập kỷ hầu như không thay đổi.
Điện toán đám mây đã bổ sung cài đặt cho trình quản lý gói không chỉ từ phương tiện vật lý mà còn từ kho lưu trữ đám mây, nhưng về cơ bản có rất ít thay đổi.
Điều đáng chú ý là hiện tại có một số động thái hướng tới việc rời bỏ deb và chuyển sang các gói snap, nhưng sau này sẽ nói nhiều hơn về điều đó.
Vì vậy, thế hệ nhà phát triển đám mây mới này, những người không biết DEB hay RPM, cũng dần phát triển, tích lũy kinh nghiệm, các sản phẩm trở nên phức tạp hơn và cần một số phương thức phân phối hợp lý hơn FTP, tập lệnh bash và các sản phẩm thủ công tương tự của sinh viên.
Và đây là lúc Docker xuất hiện, một kiểu kết hợp giữa ảo hóa, phân định tài nguyên và phương thức phân phối. Bây giờ nó là thời trang và trẻ trung, nhưng liệu nó có cần thiết cho mọi việc không? Đây có phải là thuốc chữa bách bệnh?
Theo quan sát của tôi, Docker thường được đề xuất không phải là một lựa chọn hợp lý mà đơn giản vì một mặt, nó được nhắc đến trong cộng đồng và những người đề xuất nó chỉ biết điều đó. Mặt khác, phần lớn họ im lặng về các hệ thống đóng gói cũ tốt - chúng tồn tại và thực hiện công việc của mình một cách lặng lẽ và không bị chú ý. Trong tình huống như vậy, thực sự không có lựa chọn nào khác - sự lựa chọn là hiển nhiên - Docker.
Tôi sẽ cố gắng chia sẻ kinh nghiệm của mình về cách chúng tôi triển khai Docker và kết quả đã xảy ra.
Kịch bản tự viết
Ban đầu, có các tập lệnh bash triển khai kho lưu trữ jar cho các máy được yêu cầu. Quá trình này được quản lý bởi Jenkins. Điều này hoạt động thành công vì bản thân kho lưu trữ jar đã là một tập hợp chứa các lớp, tài nguyên và thậm chí cả cấu hình. Nếu bạn dồn mọi thứ vào đó một cách tối đa thì việc mở rộng nó thành script không phải là điều khó khăn nhất bạn cần
Nhưng kịch bản có một số nhược điểm:
- các tập lệnh thường được viết vội vàng và do đó quá thô sơ đến mức chúng chỉ chứa một tình huống tốt nhất. Điều này được tạo điều kiện thuận lợi bởi thực tế là nhà phát triển quan tâm đến việc phân phối nhanh chóng và một tập lệnh thông thường đòi hỏi phải đầu tư một lượng tài nguyên kha khá
- do điểm trước đó, các tập lệnh không chứa quy trình gỡ cài đặt
- không có thủ tục nâng cấp được thiết lập
- Khi có sản phẩm mới xuất hiện, bạn cần viết kịch bản mới
- không hỗ trợ phụ thuộc
Tất nhiên, bạn có thể viết một tập lệnh phức tạp, nhưng, như tôi đã viết ở trên, đây là thời gian phát triển, không kém phần quan trọng, và như chúng ta biết, luôn không có đủ thời gian.
Tất cả điều này rõ ràng giới hạn phạm vi ứng dụng của phương pháp triển khai này chỉ ở những hệ thống đơn giản nhất. Đã đến lúc phải thay đổi điều này.
phu bến tàu
Tại một thời điểm nào đó, những sản phẩm trung gian mới đúc bắt đầu đến với chúng tôi, sôi sục với những ý tưởng và say sưa nói về chiếc docker. Chà, cầm cờ trong tay - hãy làm đi! Có hai lần thử. Cả hai đều không thành công - có thể nói là do tham vọng lớn nhưng thiếu kinh nghiệm thực tế. Có cần thiết phải ép buộc và kết thúc nó bằng mọi cách có thể không? Điều đó khó xảy ra - nhóm phải phát triển đến mức yêu cầu trước khi có thể sử dụng các công cụ thích hợp. Ngoài ra, khi sử dụng Docker image làm sẵn, chúng ta thường gặp phải tình trạng network hoạt động không chính xác (có thể do bản thân Docker bị ẩm) hoặc khó mở rộng container của người khác.
Chúng tôi đã gặp phải những bất tiện gì?
- Sự cố mạng ở chế độ cầu nối
- Thật bất tiện khi xem nhật ký trong vùng chứa (nếu chúng không được lưu trữ riêng trong hệ thống tệp của máy chủ)
- ElasticSearch thỉnh thoảng bị treo lạ bên trong container, nguyên nhân chưa xác định được, container chính thức
- Cần phải sử dụng vỏ bên trong thùng chứa - mọi thứ đều rất đơn giản, không có công cụ quen thuộc
- Kích thước lớn của thùng chứa được thu thập - đắt tiền để lưu trữ
- Do kích thước container lớn nên khó hỗ trợ nhiều phiên bản
- Thời gian xây dựng lâu hơn, không giống như các phương pháp khác (tập lệnh hoặc gói gỡ lỗi)
Mặt khác, tại sao việc triển khai một dịch vụ Spring dưới dạng một kho lưu trữ jar thông qua cùng một cuộc tranh luận lại tệ hơn? Việc cách ly tài nguyên có thực sự cần thiết? Có đáng để mất đi các công cụ tiện lợi của hệ điều hành bằng cách nhét một dịch vụ vào một vùng chứa được giảm thiểu đáng kể không?
Như thực tế đã chỉ ra, trên thực tế điều này là không cần thiết, gói deb là đủ trong 90% trường hợp.
Khi nào cuộc tranh luận cũ thất bại và khi nào chúng ta thực sự cần docker?
Đối với chúng tôi, đây là việc triển khai các dịch vụ bằng python. Rất nhiều thư viện cần thiết cho máy học và không có trong bản phân phối tiêu chuẩn của hệ điều hành (và có những phiên bản sai), hack với cài đặt, nhu cầu về các phiên bản khác nhau cho các dịch vụ khác nhau tồn tại trên cùng một hệ thống máy chủ đã dẫn đến điều này, cách hợp lý duy nhất để cung cấp hỗn hợp hạt nhân này là docker. Cường độ lao động của việc lắp ráp một container docker hóa ra thấp hơn so với ý tưởng đóng gói tất cả vào các gói gỡ lỗi riêng biệt với các gói phụ thuộc, và trên thực tế, không ai tỉnh táo sẽ thực hiện việc này.
Điểm thứ hai mà người ta dự định sử dụng Docker là triển khai các dịch vụ theo sơ đồ triển khai xanh lam. Nhưng ở đây tôi muốn độ phức tạp tăng dần: đầu tiên, các gói gỡ lỗi được tập hợp và sau đó một thùng chứa docker được tập hợp từ chúng.
Gói chụp nhanh
Hãy quay trở lại với các gói snap. Chúng lần đầu tiên xuất hiện chính thức trong Ubuntu 16.04. Không giống như các gói gỡ lỗi và gói vòng/phút thông thường, snap mang tất cả các phần phụ thuộc. Một mặt, điều này cho phép bạn tránh xung đột thư viện, mặt khác, gói kết quả có kích thước lớn hơn. Ngoài ra, điều này cũng có thể ảnh hưởng đến tính bảo mật của hệ thống: trong trường hợp phân phối nhanh, tất cả các thay đổi đối với các thư viện đi kèm phải được nhà phát triển tạo gói giám sát. Nói chung, không phải mọi thứ đều đơn giản như vậy và hạnh phúc phổ quát không đến từ việc sử dụng chúng. Tuy nhiên, đây là một giải pháp thay thế hoàn toàn hợp lý nếu cùng một Docker chỉ được sử dụng như một công cụ đóng gói chứ không phải để ảo hóa.
Do đó, hiện tại chúng tôi sử dụng cả gói gỡ lỗi và vùng chứa docker với sự kết hợp hợp lý, có lẽ trong một số trường hợp, chúng tôi sẽ thay thế bằng gói snap.
Chỉ những người dùng đã đăng ký mới có thể tham gia khảo sát. , xin vui lòng.
Bạn sử dụng gì để giao hàng?
-
Kịch bản tự viết
-
Sao chép thủ công sang FTP
-
gói gỡ lỗi
-
gói vòng/phút
-
gói chụp nhanh
-
Hình ảnh Docker
-
Hình ảnh máy ảo
-
Sao chép toàn bộ ổ cứng
-
con rối
-
ansible
-
Khác
109 người dùng bình chọn. 32 người dùng bỏ phiếu trắng.
Nguồn: www.habr.com