په یو وخت کې ما پریکړه وکړه چې د ډاکر کانټینرونو او ډیب کڅوړو په بڼه د تحویلۍ په اړه یوه مقاله ولیکئ ، مګر کله چې ما پیل وکړ ، د یو څه دلیل لپاره زه د لومړي شخصي کمپیوټرونو او حتی کیلکولیټرونو لرې وختونو ته لیږدول شوی وم. په عموم کې ، د ډاکر او ډیب وچ پرتله کولو پرځای ، موږ دا فکرونه د تکامل موضوع په اړه ترلاسه کړل ، کوم چې زه ستاسو د غور لپاره وړاندې کوم.
هر محصول، مهمه نده چې دا څه وي، باید په یو ډول د محصول سرورونو ته ورسیږي، باید ترتیب او پیل شي. دا هغه څه دي چې دا مقاله به یې په اړه وي.
زه به په تاریخي شرایطو کې فکر وکړم، "هغه څه چې زه ګورم هغه څه دي چې زه یې سندرې وایم،" هغه څه چې ما ولیدل کله چې ما لومړی د کوډ لیکل پیل کړل او هغه څه چې زه یې اوس ګورم، موږ پخپله دا مهال څه کاروو او ولې. مقاله د بشپړې مطالعې لپاره نه ده، ځینې ټکي په یاد دي، دا زما شخصي نظر دی چې څه وو او اوس څه دي.
نو، په پخوانیو ورځو کې ... د تحویلۍ ترټولو پخوانی میتود چې ما وموندل د ټیپ ریکارډرونو کیسیټ ټیپونه و. ما یو کمپیوټر درلود BK-0010.01 ...
د محاسبینو دوره
نه، پخوانۍ شېبه هم وه، محاسبه هم وه и .
نو کله چې ما درلوده ، بیا د برنامه لیږدولو لاره په یوه بکس کې د کاغذ یوه عادي ټوټه وه چې په هغې باندې یو برنامه لیکل شوې وه ، کوم چې که اړتیا وي ، په لاسي ډول یې پرمخ وړي ، په کیلکولیټر کې لیکل شوي. که تاسو غواړئ لوبه وکړئ (هو، حتی دا انټیلیلوین کیلکولیټر لوبې درلودې) - تاسو ناست شئ او پروګرام کیلکولیټر ته داخل کړئ. په طبیعي توګه، کله چې کیلکولیټر وتړل شو، برنامه په هیر کې ورکه شوه. د محاسبې کوډونو سربیره چې په شخصي توګه په کاغذ لیکل شوي، پروګرامونه په "راډیو" او "د ځوانانو لپاره ټیکنالوژي" په مجلو کې خپاره شوي، او د هغه وخت په کتابونو کې هم خپاره شوي.
راتلونکی تعدیل یو کیلکولیټر و ، دا دمخه د غیر بې ثباته ډیټا ذخیره کولو یو څه بیلګه لري. اوس لوبې یا برنامه باید په لاسي ډول داخل نه شي ، مګر د بټونو سره د ځینې جادویی پاسونو ترسره کولو وروسته ، دا پخپله بار شوی.
په کیلکولیټر کې د لوی پروګرام اندازه 105 مرحلې وه، او په MK-52 کې د دایمي حافظې اندازه 512 قدمه وه.
په هرصورت ، که چیرې د دې محاسبینو مینه وال شتون ولري چې دا مقاله لولي ، د مقالې لیکلو په جریان کې ما د Android لپاره د کیلکولیټر ایمولیټر او د دې لپاره برنامې دواړه وموندل. تېر ته وړاندې شه!
د MK-52 په اړه لنډ تحلیل (د ويکيپېډيا څخه)
MK-52 د سویوز TM-7 فضايي بېړۍ فضا ته الوتنه وکړه. دا په پام کې وه چې د لینډینګ ټراکټوري محاسبه کولو لپاره وکارول شي که چیرې د بورډ کمپیوټر ناکام شي.
د 52 راهیسې، MK-1988 د Electronika-Astro حافظې پراخولو واحد سره د نیویګیشنل کمپیوټینګ کټ د یوې برخې په توګه بحري کښتیو ته چمتو شوي.
لومړی شخصي کمپیوټرونه
راځئ چې بیرته وختونو ته لاړ شو . دا روښانه ده چې هلته ډیر حافظه شتون درلود ، او د کاغذ له یوې ټوټې څخه د کوډ ټایپ کول نور اختیار نه و (که څه هم په لومړي سر کې ما یوازې دا وکړل ، ځکه چې په ساده ډول هیڅ بله وسیله نه وه). د ټیپ ریکارډرونو لپاره آډیو کیسټونه د سافټویر ذخیره کولو او تحویلولو اصلي وسیله ګرځیدلي.
په کیسټ کې ذخیره معمولا د یو یا دوه بائنری فایلونو په شکل کې وه، نور هرڅه دننه وو. اعتبار خورا ټیټ و، زه باید د پروګرام 2-3 کاپي وساتم. د بارولو وختونه هم مایوسه کونکي وو، او لیوالتیا د دې نیمګړتیاوو د لرې کولو لپاره د مختلف فریکونسۍ کوډ کولو سره تجربه وکړه. په هغه وخت کې، زه پخپله د مسلکي سافټویر پراختیا کې ښکیل نه وم (په BASIC کې د ساده پروګرامونو شمیرل نه کول)، نو له بده مرغه، زه به تاسو ته په تفصیل سره ونه وایم چې هر څه څنګه دننه تنظیم شوي. دا حقیقت چې کمپیوټر د ډیری برخې لپاره یوازې RAM درلود د ډیټا ذخیره کولو سکیم سادگي مشخص کړه.
د باور وړ او لوی ذخیره کولو رسنیو رامینځته کول
وروسته، فلاپي ډیسکونه ښکاره شول، د کاپي کولو پروسه ساده شوه، او اعتبار زیات شو.
مګر وضعیت یوازې په ډراماتیک ډول بدلیږي کله چې په کافي اندازه لوی ځایی ذخیره د HDDs په شکل کې څرګند شي.
د تحویلۍ ډول په بنسټیز ډول بدلیږي: د نصب کونکي برنامه ښکاري چې د سیسټم تنظیم کولو پروسه اداره کوي ، او همدارنګه د لرې کولو وروسته پاکول ، ځکه چې برنامې یوازې په حافظه کې نه لوستل کیږي ، مګر دمخه ځایی ذخیره ته کاپي شوي ، له کوم ځای څخه چې تاسو اړتیا لرئ. د اړتیا په صورت کې غیر ضروري شیان پاک کړئ.
په ورته وخت کې، د چمتو شوي سافټویر پیچلتیا مخ په ډیریدو ده.
په تحویل کې د فایلونو شمیر له څو څخه سلګونو او زرګونو ته لوړیږي ، د کتابتون نسخو او نورو خوښیو ترمینځ شخړې پیل کیږي کله چې مختلف برنامې ورته ډیټا کاروي.
په هغه وخت کې، د لینکس شتون لاهم زما لپاره خلاص نه و؛ زه د MS DOS او وروسته، وینډوز نړۍ کې ژوند کوم، او په بورلینډ پاسکل او ډیلفي کې لیکل شوي، ځینې وختونه د C++ په لور ګورم. ډیری خلکو بیا د محصولاتو تحویلولو لپاره InstallShield کارولی. ، کوم چې د سافټویر پلي کولو او تنظیم کولو ټولې ټاکل شوې دندې په بریالیتوب سره حل کړې.
د انټرنیټ دوره
په تدریجي ډول، د سافټویر سیسټمونو پیچلتیا نوره هم پیچلې کیږي؛ د مونولیت او ډیسټاپ غوښتنلیکونو څخه د توزیع شوي سیسټمونو، پتلی پیرودونکو او مایکرو خدماتو ته لیږد شتون لري. اوس تاسو اړتیا لرئ نه یوازې یو برنامه تنظیم کړئ ، بلکه د دوی یوه سیټ ، او دا چې دوی ټول یوځای کار کوي.
مفهوم په بشپړه توګه بدل شو، انټرنیټ راغی، د بادل خدماتو دوره راورسیده. تر دې دمه، یوازې په لومړي پړاو کې، د ویب پاڼې په بڼه، هیڅوک په ځانګړې توګه د خدماتو خوب نه دی لیدلی. مګر دا د غوښتنلیکونو پراختیا او تحویل دواړو کې یو مهم ټکی و.
د خپل ځان لپاره ، ما یادونه وکړه چې پدې شیبه کې د پراختیا کونکو نسلونو کې بدلون راغلی (یا دا یوازې زما په چاپیریال کې و) ، او داسې احساس شتون درلود چې په یوه شیبه کې د تحویلي ټول ښه میتودونه هیر شوي او هرڅه له پیل څخه پیل شوي. پیل: ټول تحویلي د زنګون سکریپټونو سره پیل شوي او په ویاړ سره یې "دوامداره تحویل" بللی. په حقیقت کې، د ګډوډۍ دوره پیل شوې، کله چې زاړه هیر شوي او نه کارول کیږي، او نوی په ساده ډول شتون نلري.
زه هغه وختونه په یاد لرم کله چې زموږ په شرکت کې چې ما هغه وخت کار کاوه (زه یې نوم نه اخلم)، د دې پرځای چې د مڼې له لارې جوړ کړم (ماون لا تر اوسه مشهور نه و یا شتون نه درلود)، خلکو په ساده ډول په IDE کې جارونه راټول کړل او په آرامۍ سره ژمن وو. دا په SVN کې. په دې اساس، ګمارل د SVN څخه د فایل ترلاسه کول او د SSH له لارې مطلوب ماشین ته کاپي کول شامل دي. دا خورا ساده او ناپاک دی.
په ورته وخت کې، په PHP کې د ساده سایټونو تحویل په خورا ابتدايي ډول ترسره شوی و چې په ساده ډول د هدف ماشین ته د FTP له لارې سم شوي فایل کاپي کول. ځینې وختونه دا قضیه نه وه - کوډ د محصول سرور کې په ژوندۍ بڼه ایډیټ شوی و، او دا په ځانګړې توګه ښایسته و که چیرې چیرې بیک اپ شتون ولري.
RPM او DEB کڅوړې
له بلې خوا، د انټرنیټ په پراختیا سره، د UNIX په څیر سیسټمونو ډیر او ډیر شهرت ترلاسه کول پیل کړل، په ځانګړې توګه، دا هغه وخت و چې ما شاوخوا 6 کې RedHat Linux 2000 کشف کړ. په طبیعي ډول، د سافټویر وړاندې کولو لپاره ځینې وسیلې هم وې؛ د ویکیپیډیا په وینا، RPM د اصلي بسته مدیر په توګه لا دمخه په 1995 کې د RedHat لینکس 2.0 نسخه کې څرګند شو. او له هغه وخت راهیسې او تر نن ورځې پورې، سیسټم د RPM کڅوړو په بڼه وړاندې شوی او په بریالیتوب سره شتون لري او وده کوي.
د دبیان کورنۍ توزیع ورته لاره تعقیب کړه او د ډیب کڅوړو په بڼه یې تحویلي پلي کړه، چې تر نن ورځې پورې بدله پاتې ده.
د بسته بندۍ مدیران تاسو ته اجازه درکوي د سافټویر محصولات پخپله تحویل کړئ ، د نصب کولو پروسې په جریان کې یې تنظیم کړئ ، د مختلف کڅوړو ترمینځ انحصار اداره کړئ ، محصولات لرې کړئ او د غیر نصب کولو پروسې په جریان کې غیر ضروري توکي پاک کړئ. هغوی. د ډیری برخې لپاره، دا ټول هغه څه دي چې ورته اړتیا لري، له همدې امله دوی څو لسیزې په حقیقت کې بدل شوي ندي.
کلاوډ کمپیوټري د بسته بندۍ مدیرانو ته نه یوازې د فزیکي میډیا څخه ، بلکه د کلاوډ ذخیره کولو څخه هم نصب کول اضافه کړي ، مګر په بنسټیز ډول لږ بدلون راغلی.
د یادولو وړ ده چې اوس مهال د ډیب څخه د لیرې کیدو او سنیپ کڅوړو ته د بدلیدو په لور ځینې حرکتونه شتون لري ، مګر پدې اړه نور وروسته.
نو، د کلاوډ پراختیا کونکو دا نوی نسل، چې نه DEB او نه RPM پیژني، هم ورو ورو وده وکړه، تجربه یې ترلاسه کړه، محصولات خورا پیچلي شول، او د FTP، باش سکریپټونو او ورته ورته زده کونکو دستکاریو په پرتله د تحویلي ځینې معقول میتودونو ته اړتیا وه.
او دا هغه ځای دی چې ډاکر په عکس کې راځي ، د مجازی کولو یو ډول ترکیب ، د سرچینو محدودیت او تحویلي میتود. دا اوس فیشن او ځوان دی، مګر ایا دا د هرڅه لپاره اړین دی؟ ایا دا درمل دی؟
زما د لیدنو څخه، ډیری وختونه ډاکر د مناسب انتخاب په توګه وړاندیز نه کیږي، مګر یوازې دا چې له یوې خوا، په ټولنه کې د هغې په اړه خبرې کیږي، او هغه څوک چې دا وړاندیز کوي یوازې دا پوهیږي. له بلې خوا، د ډیری برخې لپاره دوی د ښه زاړه بسته بندۍ سیسټمونو په اړه خاموش دي - دوی شتون لري او خپل کار په خاموشۍ او بې پامه ترسره کوي. په داسې حالت کې، واقعیا بل انتخاب نشته - انتخاب څرګند دی - ډاکر.
زه به هڅه وکړم چې خپله تجربه شریک کړم چې څنګه موږ ډاکر پلي کړ او په پایله کې څه پیښ شوي.
پخپله لیکل شوي سکریپټونه
په پیل کې، د باش سکریپټ شتون درلود چې د جار آرشیفونه اړین ماشینونو ته ځای په ځای کړي. دا پروسه د جینکنز لخوا اداره کیده. دا په بریالیتوب سره کار وکړ، ځکه چې د جار آرشیف پخپله یو مجلس دی چې ټولګي، سرچینې او حتی تشکیلات لري. که تاسو هرڅه په اعظمي حد کې واچوئ ، نو بیا یې په سکریپټ کې پراخول خورا ستونزمن شی ندي چې تاسو ورته اړتیا لرئ
مګر سکریپټونه ډیری زیانونه لري:
- سکریپټونه معمولا په بیړه لیکل کیږي او له همدې امله دومره ابتدايي دي چې دوی یوازې یو غوره قضیه لري. دا د دې حقیقت لخوا اسانه شوی چې پراختیا کونکی د ګړندي تحویلۍ سره علاقه لري ، او یو نورمال سکریپټ د مناسب مقدار سرچینو پانګوونې ته اړتیا لري.
- د پخوانۍ نقطې په پایله کې، سکریپټونه د غیر نصب کولو پروسیجرونه نلري
- د نوي کولو پروسه نه ده جوړه شوې
- کله چې یو نوی محصول څرګند شي، تاسو اړتیا لرئ یو نوی سکریپټ ولیکئ
- د انحصار ملاتړ نشته
البته، تاسو کولی شئ یو پیچلي سکریپټ ولیکئ، مګر، لکه څنګه چې ما پورته لیکلي، دا د پراختیا وخت دی، او لږترلږه نه، او لکه څنګه چې موږ پوهیږو، تل کافي وخت شتون نلري.
دا ټول په ښکاره ډول د دې ګمارنې میتود د پلي کولو لړۍ یوازې ساده سیسټمونو ته محدودوي. د دې بدلولو وخت راغلی.
ډاکر
په یو وخت کې ، تازه مینځل شوي مینځونه موږ ته راوتلي ، د نظرونو سره ویریدل او د ډاکر په اړه یې ویره کوله. ښه، بیرغ په لاس کې - راځئ چې دا وکړو! دوه هڅې وې. دواړه ناکام وو - راځئ چې ووایو، د لویو هیلو له امله، مګر د ریښتینې تجربې نشتوالی. ایا دا اړینه وه چې دا په زور سره او د هرې ممکنې لارې پای ته ورسوي؟ دا امکان نلري - ټیم باید اړین کچې ته وده ورکړي مخکې لدې چې مناسب وسیلې وکاروي. سربیره پردې ، کله چې د چمتو شوي ډاکر عکسونه وکاروئ ، موږ ډیری وختونه د دې حقیقت سره مخ شو چې شبکه په سمه توګه کار نه کوي (کوم چې ممکن پخپله د ډاکر د رطوبت له امله وي) یا د نورو خلکو کانټینرونو پراخه کول ستونزمن وو.
موږ له کومو ناخوالو سره مخ شو؟
- د برج حالت کې د شبکې ستونزې
- په کانټینر کې د لاګونو لیدل ناشونې دي (که دوی د کوربه ماشین فایل سیسټم کې په جلا توګه زیرمه شوي ندي)
- ElasticSearch کله ناکله په کانټینر کې په عجیب ډول کنګل کیږي، لامل یې نه دی ټاکل شوی، کانټینر رسمي دی
- دا اړینه ده چې په کانټینر کې شیل وکاروئ - هرڅه خورا لرې شوي ، هیڅ پیژندل شوي وسیلې شتون نلري
- د راټول شوي کانټینرونو لوی اندازه - د ذخیره کولو لپاره ګران
- د کانټینرونو لوی اندازې له امله ، د ډیری نسخو ملاتړ کول ګران دي
- د جوړیدو اوږد وخت، د نورو میتودونو برعکس (سکریپټونه یا ډیب کڅوړې)
له بلې خوا ، ولې د ورته ډیب له لارې د جار آرشیف په توګه د پسرلي خدمت ځای په ځای کول خورا بد دي؟ ایا د سرچینو جلا کول واقعیا اړین دي؟ ایا دا ارزښت لري چې په خورا کم شوي کانټینر کې د خدماتو ډکولو سره د مناسب عملیاتي سیسټم وسیلې له لاسه ورکړئ؟
لکه څنګه چې تمرین ښودلی، په حقیقت کې دا اړینه نه ده، د ډیب کڅوړه په 90٪ قضیو کې کافي ده.
ښه زوړ ډیب کله ناکام کیږي او کله موږ واقعیا ډاکر ته اړتیا لرو؟
زموږ لپاره ، دا په پایتون کې د خدماتو ځای په ځای کول وو. د ماشین زده کړې لپاره ډیری کتابتونونو ته اړتیا ده او د عامل سیسټم معیاري توزیع کې شامل ندي (او څه چې غلط نسخې شتون درلود) ، د تنظیماتو سره هیکونه ، په ورته کوربه سیسټم کې ژوند کولو مختلف خدماتو لپاره مختلف نسخو ته اړتیا د دې لامل شوې چې دا، چې د دې اټومي مخلوط د رسولو یوازینۍ معقوله لاره ډاکر وه. د ډاکر کانټینر راټولولو د کار شدت د دې نظر څخه ټیټ و چې دا ټول د انحصار سره جلا ډیب کڅوړو کې بسته کړي ، او په حقیقت کې هیڅوک به د دوی په سم ذهن کې دا کار ونه کړي.
دوهم ټکی چیرې چې موږ د ډاکر کارولو پلان لرو د نیلي - شنه پلي کولو سکیم په کارولو سره د خدماتو ځای په ځای کول دي. مګر دلته زه غواړم په پیچلتیا کې تدریجي زیاتوالی ترلاسه کړم: لومړی ، د ډیب کڅوړې رامینځته کیږي ، او بیا د دوی څخه د ډاکر کانټینر جوړ شوی.
سنیپ کڅوړې
راځئ چې د سنیپ کڅوړو ته بیرته راشو. دوی لومړی په رسمي ډول په اوبنټو 16.04 کې څرګند شو. د معمول deb کڅوړو او rpm کڅوړو برخلاف ، سنیپ ټول انحصارونه لري. له یوې خوا ، دا تاسو ته اجازه درکوي د کتابتون شخړو څخه مخنیوی وکړئ ، له بلې خوا ، پایله شوې کڅوړه په اندازې کې لوی ده. سربیره پردې ، دا کولی شي د سیسټم امنیت هم اغیزه وکړي: د سنیپ تحویلۍ په حالت کې ، په شامل کتابتونونو کې ټول بدلونونه باید د پراختیا کونکي لخوا وڅارل شي څوک چې کڅوړه رامینځته کوي. په عموم کې، هرڅه دومره ساده ندي او نړیواله خوښي د دوی کارولو څخه نه راځي. مګر، سره له دې، دا یو بشپړ معقول بدیل دی که ورته ډاکر یوازې د بسته بندۍ وسیلې په توګه وکارول شي نه د مجازی کولو لپاره.
د پایلې په توګه ، موږ اوس دواړه ډیب کڅوړې او ډاکر کانټینرونه په مناسب ترکیب کې کاروو ، کوم چې شاید په ځینو مواردو کې موږ د سنیپ کڅوړو سره ځای په ځای کړو.
یوازې راجستر شوي کاروونکي کولی شي په سروې کې برخه واخلي. مهرباني وکړئ
تاسو د تحویل لپاره څه کاروئ؟
-
پخپله لیکل شوي سکریپټونه
-
په لاسي ډول FTP ته کاپي کړئ
-
deb کڅوړې
-
rpm کڅوړې
-
کڅوړې سنیپ
-
ډاکر - انځورونه
-
د مجازی ماشین انځورونه
-
ټول HDD کلون کړئ
-
کڅوړه
-
ځواب ویونکی
-
نور
109 کاروونکو رایه ورکړه. 32 کاروونکي منع شوي.
سرچینه: www.habr.com