🥇 ডেলিভারি টুলের বিবর্তন, বা ডকার, ডেব, জার এবং আরও অনেক কিছু সম্পর্কে চিন্তাভাবনা

এক পর্যায়ে আমি ডকার কন্টেইনার এবং ডেব প্যাকেজ আকারে ডেলিভারি সম্পর্কে একটি নিবন্ধ লেখার সিদ্ধান্ত নিয়েছিলাম, কিন্তু যখন আমি শুরু করেছি, কিছু কারণে আমাকে প্রথম ব্যক্তিগত কম্পিউটার এবং এমনকি ক্যালকুলেটরগুলির দূরবর্তী সময়ে নিয়ে যাওয়া হয়েছিল। সাধারণভাবে, ডকার এবং ডেবের শুষ্ক তুলনার পরিবর্তে, আমরা বিবর্তনের বিষয়ে এই চিন্তাগুলি পেয়েছি, যা আমি আপনার বিবেচনার জন্য উপস্থাপন করছি।

যে কোনো পণ্য, তা যাই হোক না কেন, অবশ্যই কোনোভাবে পণ্য সার্ভারে পৌঁছাতে হবে, কনফিগার এবং চালু করতে হবে। এই নিবন্ধটি সম্পর্কে হবে কি.

আমি একটি ঐতিহাসিক প্রেক্ষাপটে চিন্তা করব, "আমি যা দেখি তা হল আমি যা গান করি," আমি যখন প্রথম কোড লিখতে শুরু করি তখন আমি কী দেখেছিলাম এবং এখন আমি কী পর্যবেক্ষণ করছি, আমরা নিজেরাই এই মুহূর্তে কী ব্যবহার করছি এবং কেন। নিবন্ধটি একটি পূর্ণাঙ্গ অধ্যয়নের ভান করে না, কিছু পয়েন্ট মিস করা হয়েছে, এটি কী ছিল এবং এখন কী তা আমার ব্যক্তিগত দৃষ্টিভঙ্গি।

সুতরাং, ভাল পুরানো দিনে... আমি যে ডেলিভারির প্রথম পদ্ধতিটি পেয়েছি তা হল টেপ রেকর্ডার থেকে ক্যাসেট টেপ। আমার একটি কম্পিউটার BK-0010.01 ছিল...

ক্যালকুলেটরের যুগ

না, আরও আগের মুহূর্ত ছিল, ক্যালকুলেটরও ছিল এমকে -61 и এমকে -52.

তাই যখন আমি ছিল এমকে -61, তারপরে প্রোগ্রামটি স্থানান্তর করার উপায়টি ছিল একটি বাক্সে একটি সাধারণ কাগজের টুকরো যার উপর একটি প্রোগ্রাম লেখা ছিল, যা প্রয়োজন হলে এটি ম্যানুয়ালি চালানোর জন্য, ক্যালকুলেটরে লেখা হয়েছিল। আপনি যদি খেলতে চান (হ্যাঁ, এমনকি এই অ্যান্টিলুভিয়ান ক্যালকুলেটরটিতেও গেম ছিল) - আপনি বসুন এবং ক্যালকুলেটরে প্রোগ্রামটি প্রবেশ করুন। স্বাভাবিকভাবেই, ক্যালকুলেটরটি বন্ধ হয়ে গেলে, প্রোগ্রামটি বিস্মৃতিতে অদৃশ্য হয়ে যায়। তার নিজের হাতে কাগজে লেখা ক্যালকুলেটর কোডগুলি ছাড়াও, প্রোগ্রামগুলি "রেডিও" এবং "যুবদের জন্য প্রযুক্তি" পত্রিকায় প্রকাশিত হয়েছিল এবং সেই সময়ের বইগুলিতেও প্রকাশিত হয়েছিল।

পরবর্তী পরিবর্তন একটি ক্যালকুলেটর ছিল এমকে -52, এতে ইতিমধ্যেই অ-উদ্বায়ী ডেটা স্টোরেজের কিছু আভাস রয়েছে। এখন গেম বা প্রোগ্রামটি ম্যানুয়ালি প্রবেশ করতে হবে না, তবে বোতামগুলির সাথে কিছু জাদুকরী পাস করার পরে এটি নিজেই লোড হয়ে গেছে।

ক্যালকুলেটরের বৃহত্তম প্রোগ্রামের আকার ছিল 105 ধাপ, এবং MK-52-এ স্থায়ী মেমরির আকার ছিল 512 ধাপ।

যাইহোক, যদি এই ক্যালকুলেটরগুলির অনুরাগী থাকে যারা এই নিবন্ধটি পড়ছেন, নিবন্ধটি লেখার প্রক্রিয়াতে আমি অ্যান্ড্রয়েডের জন্য একটি ক্যালকুলেটর এমুলেটর এবং এটির জন্য প্রোগ্রাম উভয়ই পেয়েছি। অতীতে ফরোয়ার্ড!

MK-52 সম্পর্কে একটি সংক্ষিপ্ত ডিগ্রেশন (উইকিপিডিয়া থেকে)

MK-52 সয়ুজ TM-7 মহাকাশযানে মহাকাশে উড়েছিল। অন-বোর্ড কম্পিউটার ব্যর্থ হলে অবতরণ গতিপথ গণনা করতে এটি ব্যবহার করার কথা ছিল।

52 সাল থেকে, ইলেকট্রোনিকা-অ্যাস্ট্রো মেমরি সম্প্রসারণ ইউনিট সহ MK-1988 একটি নেভিগেশনাল কম্পিউটিং কিটের অংশ হিসাবে নৌবাহিনীর জাহাজগুলিতে সরবরাহ করা হয়েছে।

প্রথম ব্যক্তিগত কম্পিউটার

ফিরে যাওয়া যাক সেই সময়ে BC-0010. এটা স্পষ্ট যে সেখানে আরও মেমরি ছিল, এবং কাগজের টুকরো থেকে কোড টাইপ করা আর কোনও বিকল্প ছিল না (যদিও প্রথমে আমি এটিই করেছিলাম, কারণ অন্য কোনও মাধ্যম ছিল না)। টেপ রেকর্ডারগুলির জন্য অডিও ক্যাসেটগুলি সফ্টওয়্যার সংরক্ষণ এবং বিতরণের প্রধান মাধ্যম হয়ে উঠছে।

একটি ক্যাসেটের স্টোরেজ সাধারণত এক বা দুটি বাইনারি ফাইলের আকারে থাকত, বাকি সবকিছু ভিতরেই থাকত। নির্ভরযোগ্যতা খুব কম ছিল, আমাকে প্রোগ্রামের 2-3 কপি রাখতে হয়েছিল। লোডিং সময়গুলিও হতাশাজনক ছিল, এবং উত্সাহীরা এই ত্রুটিগুলি কাটিয়ে উঠতে বিভিন্ন ফ্রিকোয়েন্সি এনকোডিংয়ের সাথে পরীক্ষা করেছিলেন। সেই সময়ে, আমি নিজে এখনও পেশাদার সফ্টওয়্যার বিকাশের সাথে জড়িত ছিলাম না (বেসিকে সাধারণ প্রোগ্রামগুলি গণনা করছি না), তাই, দুর্ভাগ্যবশত, আমি আপনাকে বিশদভাবে বলব না কীভাবে ভিতরে সবকিছু সাজানো হয়েছিল। কম্পিউটারের বেশিরভাগ অংশে শুধুমাত্র র‌্যাম থাকার বিষয়টি ডেটা স্টোরেজ স্কিমের সরলতা নির্ধারণ করে।

নির্ভরযোগ্য এবং বড় স্টোরেজ মিডিয়ার উত্থান

পরে, ফ্লপি ডিস্কগুলি উপস্থিত হয়েছিল, অনুলিপি প্রক্রিয়াটি সরলীকৃত হয়েছিল এবং নির্ভরযোগ্যতা বৃদ্ধি পেয়েছে।
কিন্তু পরিস্থিতি নাটকীয়ভাবে পরিবর্তিত হয় যখন পর্যাপ্ত বড় স্থানীয় স্টোরেজ HDD আকারে উপস্থিত হয়।

ডেলিভারির ধরন মৌলিকভাবে পরিবর্তিত হচ্ছে: ইনস্টলার প্রোগ্রামগুলি উপস্থিত হয় যা সিস্টেমটি কনফিগার করার প্রক্রিয়া পরিচালনা করে, পাশাপাশি অপসারণের পরে পরিষ্কার করে, যেহেতু প্রোগ্রামগুলি কেবল মেমরিতে পড়া হয় না, তবে ইতিমধ্যে স্থানীয় স্টোরেজে অনুলিপি করা হয়, যেখান থেকে আপনার প্রয়োজন। প্রয়োজনে অপ্রয়োজনীয় জিনিস পরিষ্কার করতে সক্ষম হন।

একই সঙ্গে সরবরাহকৃত সফটওয়্যার নিয়ে জটিলতা বাড়ছে।
বিতরণে ফাইলের সংখ্যা কয়েক থেকে শত এবং হাজারে বৃদ্ধি পায়, লাইব্রেরি সংস্করণ এবং অন্যান্য আনন্দের মধ্যে দ্বন্দ্ব শুরু হয় যখন বিভিন্ন প্রোগ্রাম একই ডেটা ব্যবহার করে।

সেই সময়ে, লিনাক্সের অস্তিত্ব এখনও আমার কাছে উন্মুক্ত ছিল না; আমি MS DOS এবং পরবর্তীতে, Windows এর জগতে বাস করতাম এবং Borland Pascal এবং Delphi-এ লিখতাম, মাঝে মাঝে C++ এর দিকে তাকাতাম। অনেক লোক তখন পণ্য সরবরাহ করতে InstallShield ব্যবহার করেছিল। ru.wikipedia.org/wiki/InstallShield, যা সফ্টওয়্যার স্থাপন এবং কনফিগার করার সমস্ত বরাদ্দকৃত কাজগুলিকে বেশ সফলভাবে সমাধান করেছে।

ইন্টারনেট যুগ

ধীরে ধীরে, সফ্টওয়্যার সিস্টেমের জটিলতা আরও জটিল হয়ে উঠছে; মনোলিথ এবং ডেস্কটপ অ্যাপ্লিকেশন থেকে বিতরণ সিস্টেম, পাতলা ক্লায়েন্ট এবং মাইক্রোসার্ভিসে একটি রূপান্তর রয়েছে। এখন আপনাকে কেবল একটি প্রোগ্রাম নয়, তাদের একটি সেট কনফিগার করতে হবে এবং যাতে তারা সবাই একসাথে কাজ করে।

ধারণাটি সম্পূর্ণরূপে পরিবর্তিত হয়েছে, ইন্টারনেট এসেছে, ক্লাউড পরিষেবার যুগ এসেছে। এখন পর্যন্ত, শুধুমাত্র প্রাথমিক পর্যায়ে, ওয়েবসাইট আকারে, কেউ বিশেষভাবে পরিষেবার স্বপ্ন দেখেনি। তবে এটি অ্যাপ্লিকেশনগুলির বিকাশ এবং বিতরণ উভয় ক্ষেত্রেই একটি টার্নিং পয়েন্ট ছিল।

নিজের জন্য, আমি লক্ষ করেছি যে সেই মুহুর্তে বিকাশকারীদের প্রজন্মের মধ্যে একটি পরিবর্তন হয়েছিল (বা এটি শুধুমাত্র আমার পরিবেশে ছিল), এবং একটি অনুভূতি ছিল যে সমস্ত ভাল পুরানো ডেলিভারি পদ্ধতিগুলি এক মুহুর্তে ভুলে গিয়েছিল এবং সবকিছুই শুরু হয়েছিল শুরু: সমস্ত ডেলিভারি হাঁটু স্ক্রিপ্টে করা শুরু হয়েছিল এবং গর্বের সাথে এটিকে "কন্টিনিউয়াস ডেলিভারি" বলা হয়েছিল। প্রকৃতপক্ষে, বিশৃঙ্খলার একটি সময় শুরু হয়েছে, যখন পুরানোটি ভুলে যায় এবং ব্যবহার করা হয় না এবং নতুনটি কেবল বিদ্যমান থাকে না।

আমার সেই সময়ের কথা মনে আছে যখন আমাদের কোম্পানিতে আমি যেখানে কাজ করতাম (আমি নাম বলব না), পিঁপড়ার মাধ্যমে নির্মাণের পরিবর্তে (ম্যাভেন তখনো জনপ্রিয় ছিল না বা আদৌ বিদ্যমান ছিল না), লোকেরা কেবল আইডিই-তে জার সংগ্রহ করেছিল এবং নির্মলভাবে প্রতিশ্রুতিবদ্ধ ছিল। এটি SVN এ। তদনুসারে, স্থাপনায় SVN থেকে ফাইলটি পুনরুদ্ধার করা এবং SSH এর মাধ্যমে পছন্দসই মেশিনে অনুলিপি করা অন্তর্ভুক্ত। এটা এত সহজ এবং আনাড়ি.

একই সময়ে, পিএইচপি-তে সাধারণ সাইটগুলির ডেলিভারিটি খুব আদিম উপায়ে করা হয়েছিল কেবলমাত্র FTP-এর মাধ্যমে সংশোধিত ফাইলটিকে লক্ষ্য মেশিনে অনুলিপি করার মাধ্যমে। কখনও কখনও এটি ছিল না - কোডটি পণ্য সার্ভারে লাইভ সম্পাদনা করা হয়েছিল এবং কোথাও ব্যাকআপ থাকলে এটি বিশেষত চটকদার ছিল৷

RPM এবং DEB প্যাকেজ

অন্যদিকে, ইন্টারনেটের বিকাশের সাথে সাথে, ইউনিক্স-এর মতো সিস্টেমগুলি আরও বেশি জনপ্রিয়তা অর্জন করতে শুরু করে, বিশেষত, সেই সময়ে আমি প্রায় 6 সালে রেডহ্যাট লিনাক্স 2000 আবিষ্কার করেছি। স্বাভাবিকভাবেই, সফ্টওয়্যার সরবরাহের জন্য কিছু নির্দিষ্ট উপায়ও ছিল; উইকিপিডিয়া অনুসারে, প্রধান প্যাকেজ ম্যানেজার হিসাবে RPM ইতিমধ্যেই 1995 সালে RedHat Linux 2.0 এর সংস্করণে উপস্থিত হয়েছিল। এবং তারপর থেকে এবং আজ অবধি, সিস্টেমটি RPM প্যাকেজ আকারে বিতরণ করা হয়েছে এবং বেশ সফলভাবে বিদ্যমান এবং বিকাশ করছে।

ডেবিয়ান পরিবারের বন্টন একই পথ অনুসরণ করে এবং ডেব প্যাকেজ আকারে ডেলিভারি প্রয়োগ করে, যা আজ অবধি অপরিবর্তিত রয়েছে।

প্যাকেজ ম্যানেজার আপনাকে সফ্টওয়্যার পণ্যগুলি নিজেরাই সরবরাহ করতে, ইনস্টলেশন প্রক্রিয়া চলাকালীন সেগুলি কনফিগার করতে, বিভিন্ন প্যাকেজের মধ্যে নির্ভরতা পরিচালনা করতে, পণ্যগুলি সরাতে এবং আনইনস্টলেশন প্রক্রিয়া চলাকালীন অপ্রয়োজনীয় আইটেমগুলি পরিষ্কার করার অনুমতি দেয়। সেগুলো. বেশিরভাগ অংশে, এটিই প্রয়োজন, যে কারণে তারা কার্যত অপরিবর্তিত কয়েক দশক ধরে চলেছিল।

ক্লাউড কম্পিউটিং শুধুমাত্র ফিজিক্যাল মিডিয়া থেকে নয়, ক্লাউড রিপোজিটরি থেকেও প্যাকেজ ম্যানেজারগুলিতে ইনস্টলেশন যোগ করেছে, কিন্তু মৌলিকভাবে সামান্য পরিবর্তন হয়েছে।

এটি লক্ষণীয় যে বর্তমানে ডেব থেকে দূরে সরে যাওয়ার এবং স্ন্যাপ প্যাকেজগুলিতে স্যুইচ করার দিকে কিছু পদক্ষেপ রয়েছে, তবে পরে আরও কিছু।

সুতরাং, এই নতুন প্রজন্মের ক্লাউড বিকাশকারীরা, যারা DEB বা RPM উভয়ই জানত না, তারাও ধীরে ধীরে বৃদ্ধি পেয়েছে, অভিজ্ঞতা অর্জন করেছে, পণ্যগুলি আরও জটিল হয়ে উঠেছে, এবং FTP, ব্যাশ স্ক্রিপ্ট এবং অনুরূপ ছাত্রদের কারুশিল্পের চেয়ে আরও কিছু যুক্তিসঙ্গত বিতরণ পদ্ধতির প্রয়োজন ছিল।
এবং এখানেই ডকার ছবিতে আসে, ভার্চুয়ালাইজেশন, রিসোর্স ডিলিমিটেশন এবং ডেলিভারি পদ্ধতির এক ধরনের মিশ্রণ। এটি এখন ফ্যাশনেবল এবং তারুণ্য, তবে এটি কি সবকিছুর জন্য প্রয়োজন? এটা কি নিরাময়?

আমার পর্যবেক্ষণ থেকে, প্রায়শই ডকারকে যুক্তিসঙ্গত পছন্দ হিসাবে প্রস্তাব করা হয় না, তবে কেবল কারণ, একদিকে, এটি সম্প্রদায়ের মধ্যে আলোচনা করা হয়, এবং যারা এটি প্রস্তাব করেন তারা কেবল এটি জানেন। অন্যদিকে, বেশিরভাগ অংশের জন্য তারা ভাল পুরানো প্যাকেজিং সিস্টেম সম্পর্কে নীরব - তারা বিদ্যমান এবং তাদের কাজটি নিঃশব্দে এবং অলক্ষিতভাবে করে। এমন পরিস্থিতিতে, সত্যিই অন্য কোন বিকল্প নেই - পছন্দটি স্পষ্ট - ডকার।

আমরা কীভাবে ডকারকে বাস্তবায়ন করেছি এবং এর ফলে কী ঘটেছে সে সম্পর্কে আমি আমার অভিজ্ঞতা ভাগ করে নেওয়ার চেষ্টা করব।

স্ব-লিখিত স্ক্রিপ্ট

প্রাথমিকভাবে, ব্যাশ স্ক্রিপ্ট ছিল যা প্রয়োজনীয় মেশিনে জার সংরক্ষণাগার স্থাপন করে। এই প্রক্রিয়াটি জেনকিন্স দ্বারা পরিচালিত হয়েছিল। এটি সফলভাবে কাজ করেছে, যেহেতু জার সংরক্ষণাগারটি ইতিমধ্যেই ক্লাস, সংস্থান এবং এমনকি কনফিগারেশন ধারণকারী একটি সমাবেশ। আপনি যদি এটির মধ্যে সবকিছুকে সর্বোচ্চে রাখেন, তবে এটিকে একটি স্ক্রিপ্টে প্রসারিত করা আপনার প্রয়োজন সবচেয়ে কঠিন জিনিস নয়

কিন্তু স্ক্রিপ্টের বেশ কিছু অসুবিধা আছে:

স্ক্রিপ্টগুলি সাধারণত তাড়াহুড়ো করে লেখা হয় এবং তাই এতটাই আদিম যে সেগুলিতে শুধুমাত্র একটি সেরা-কেস দৃশ্যকল্প থাকে। এটি এই বিষয়টির দ্বারা সহজতর হয় যে বিকাশকারী দ্রুত বিতরণে আগ্রহী এবং একটি সাধারণ স্ক্রিপ্টের জন্য একটি শালীন পরিমাণ সম্পদের বিনিয়োগ প্রয়োজন
পূর্ববর্তী পয়েন্টের ফলস্বরূপ, স্ক্রিপ্টগুলিতে আনইনস্টল করার পদ্ধতি নেই
কোন প্রতিষ্ঠিত আপগ্রেড পদ্ধতি
যখন একটি নতুন পণ্য প্রদর্শিত হয়, আপনাকে একটি নতুন স্ক্রিপ্ট লিখতে হবে
কোন নির্ভরতা সমর্থন

অবশ্যই, আপনি একটি পরিশীলিত স্ক্রিপ্ট লিখতে পারেন, কিন্তু, যেমনটি আমি উপরে লিখেছি, এটি উন্নয়নের সময়, এবং কম নয়, এবং আমরা জানি, সর্বদা পর্যাপ্ত সময় নেই।

এই সমস্ত স্পষ্টতই এই স্থাপনার পদ্ধতির প্রয়োগের পরিসরকে শুধুমাত্র সহজতম সিস্টেমগুলিতে সীমাবদ্ধ করে। এই পরিবর্তনের সময় এসেছে।

ডকশ্রমিক

কিছু সময়ে, সদ্য মিডল মিডলগুলি আমাদের কাছে আসতে শুরু করেছিল, ধারণাগুলি নিয়ে উদ্বেলিত হয়েছিল এবং ডকারকে নিয়ে উচ্ছ্বসিত হয়েছিল। আচ্ছা, পতাকা হাতে - চলুন! দুটি প্রচেষ্টা ছিল। উভয়ই ব্যর্থ হয়েছিল - ধরা যাক, দুর্দান্ত উচ্চাকাঙ্ক্ষার কারণে, তবে বাস্তব অভিজ্ঞতার অভাব। এটা জোর করে এবং প্রয়োজনীয় কোনো উপায়ে এটি শেষ করা প্রয়োজন ছিল? এটি অসম্ভাব্য - উপযুক্ত সরঞ্জামগুলি ব্যবহার করার আগে দলটিকে প্রয়োজনীয় স্তরে বিকশিত হতে হবে। এছাড়াও, রেডিমেড ডকার ইমেজগুলি ব্যবহার করার সময়, আমরা প্রায়শই এই সত্যটির সম্মুখীন হই যে নেটওয়ার্কটি সঠিকভাবে কাজ করে না (যা ডকারের স্যাঁতসেঁতে হওয়ার কারণে হতে পারে) বা অন্য লোকেদের পাত্রে প্রসারিত করা কঠিন ছিল।

আমরা কোন অসুবিধার সম্মুখীন হয়েছিলাম?

ব্রিজ মোডে নেটওয়ার্ক সমস্যা
একটি পাত্রে লগগুলি দেখতে অসুবিধাজনক (যদি সেগুলি হোস্ট মেশিনের ফাইল সিস্টেমে আলাদাভাবে সংরক্ষণ করা না হয়)
ইলাস্টিক সার্চ মাঝে মাঝে পাত্রের ভিতরে অদ্ভুতভাবে জমে যায়, কারণ নির্ধারণ করা হয়নি, ধারকটি অফিসিয়াল
একটি পাত্রের ভিতরে একটি শেল ব্যবহার করা প্রয়োজন - সবকিছু খুব ছিনতাই করা হয়েছে, কোনও পরিচিত সরঞ্জাম নেই
সংগৃহীত পাত্রে বড় আকার - সংরক্ষণের জন্য ব্যয়বহুল
পাত্রের বড় আকারের কারণে, একাধিক সংস্করণ সমর্থন করা কঠিন
দীর্ঘ বিল্ড সময়, অন্যান্য পদ্ধতির বিপরীতে (স্ক্রিপ্ট বা ডেব প্যাকেজ)

অন্যদিকে, একই ডেবের মাধ্যমে জার সংরক্ষণাগার আকারে একটি স্প্রিং পরিষেবা স্থাপন করা কেন খারাপ? সম্পদ বিচ্ছিন্নতা সত্যিই প্রয়োজনীয়? একটি ব্যাপকভাবে হ্রাস পাত্রে একটি পরিষেবা স্টাফ করে সুবিধাজনক অপারেটিং সিস্টেম সরঞ্জাম হারানোর মূল্য কি?

অনুশীলন হিসাবে দেখানো হয়েছে, বাস্তবে এটি প্রয়োজনীয় নয়, 90% ক্ষেত্রে ডেব প্যাকেজ যথেষ্ট।

ভাল পুরানো ডেব কখন ব্যর্থ হয় এবং কখন আমাদের সত্যিই ডকার দরকার?

আমাদের জন্য, এটি পাইথনে পরিষেবাগুলি স্থাপন করছিল। মেশিন লার্নিংয়ের জন্য প্রচুর লাইব্রেরি প্রয়োজন এবং অপারেটিং সিস্টেমের স্ট্যান্ডার্ড ডিস্ট্রিবিউশনে অন্তর্ভুক্ত নয় (এবং সেখানে কী ভুল সংস্করণ ছিল), সেটিংস সহ হ্যাক, একই হোস্ট সিস্টেমে বসবাসকারী বিভিন্ন পরিষেবার জন্য বিভিন্ন সংস্করণের প্রয়োজনীয়তার কারণে এটি, যে এই পারমাণবিক মিশ্রণটি সরবরাহ করার একমাত্র যুক্তিসঙ্গত উপায় ছিল ডকার। একটি ডকার কন্টেইনার একত্রিত করার শ্রমের তীব্রতা নির্ভরশীলতার সাথে এটিকে আলাদা ডেব প্যাকেজে প্যাক করার ধারণার চেয়ে কম বলে প্রমাণিত হয়েছিল এবং প্রকৃতপক্ষে তাদের সঠিক মনের কেউ এটি গ্রহণ করবে না।

দ্বিতীয় পয়েন্ট যেখানে আমরা ডকার ব্যবহার করার পরিকল্পনা করি তা হল নীল-সবুজ স্থাপনার স্কিম ব্যবহার করে পরিষেবাগুলি স্থাপন করা। তবে এখানে আমি জটিলতার ক্রমশ বৃদ্ধি পেতে চাই: প্রথমে, ডেব প্যাকেজগুলি তৈরি করা হয় এবং তারপরে তাদের থেকে একটি ডকার কন্টেইনার তৈরি করা হয়।

স্ন্যাপ প্যাকেজ

আসুন স্ন্যাপ প্যাকেজগুলিতে ফিরে আসি। তারা প্রথম আনুষ্ঠানিকভাবে উবুন্টু 16.04 এ উপস্থিত হয়েছিল। সাধারণ deb প্যাকেজ এবং rpm প্যাকেজের বিপরীতে, snap সমস্ত নির্ভরতা বহন করে। একদিকে, এটি আপনাকে লাইব্রেরি দ্বন্দ্ব এড়াতে দেয়, অন্যদিকে, ফলস্বরূপ প্যাকেজটি আকারে বড়। উপরন্তু, এটি সিস্টেমের নিরাপত্তাকেও প্রভাবিত করতে পারে: স্ন্যাপ ডেলিভারির ক্ষেত্রে, অন্তর্ভুক্ত লাইব্রেরির সমস্ত পরিবর্তন অবশ্যই প্যাকেজ তৈরিকারী বিকাশকারী দ্বারা পর্যবেক্ষণ করা উচিত। সাধারণভাবে, সবকিছু এত সহজ নয় এবং সর্বজনীন সুখ এগুলি ব্যবহার করে আসে না। কিন্তু, তবুও, এটি একটি সম্পূর্ণ যুক্তিসঙ্গত বিকল্প যদি একই ডকারটি শুধুমাত্র একটি প্যাকেজিং টুল হিসাবে ব্যবহার করা হয় এবং ভার্চুয়ালাইজেশনের জন্য নয়।

ফলস্বরূপ, আমরা এখন যুক্তিসঙ্গত সংমিশ্রণে ডেব প্যাকেজ এবং ডকার কন্টেইনার উভয়ই ব্যবহার করি, যা, সম্ভবত, কিছু ক্ষেত্রে আমরা স্ন্যাপ প্যাকেজগুলির সাথে প্রতিস্থাপন করব।

শুধুমাত্র নিবন্ধিত ব্যবহারকারীরা জরিপে অংশগ্রহণ করতে পারবেন। সাইন ইন করুনকরুন।

আপনি প্রসবের জন্য কি ব্যবহার করেন?

স্ব-লিখিত স্ক্রিপ্ট
FTP-তে ম্যানুয়ালি কপি করুন
deb প্যাকেজ
rpm প্যাকেজ
স্ন্যাপ প্যাকেজ
ডকার-ইমেজ
ভার্চুয়াল মেশিনের ছবি
সম্পূর্ণ HDD ক্লোন করুন
পুতুল
ansible
অন্যান্য

109 ব্যবহারকারী ভোট দিয়েছেন। 32 জন ব্যবহারকারী বিরত ছিলেন।

উত্স: www.habr.com

ডেলিভারি টুলের বিবর্তন, বা ডকার, ডেব, জার এবং আরও অনেক কিছু সম্পর্কে চিন্তাভাবনা