Кандайдыр бир убакта мен Docker контейнерлери жана деб пакеттери түрүндө жеткирүү жөнүндө макала жазууну чечтим, бирок мен баштаганда, эмнегедир мен биринчи персоналдык компьютерлердин жана ал тургай калькуляторлордун алыскы мезгилине кайтып келдим. Жалпысынан алганда, докер менен дебди кургак салыштыруунун ордуна, биз сиздердин карооңуздарга сунуш кылган эволюция темасы боюнча ушул ойлорду алдык.
Кандай гана продукт болбосун, кандайдыр бир жол менен продукт серверлерине кириши керек, конфигурацияланып, ишке киргизилиши керек. Бул макала эмне жөнүндө болмокчу.
Мен тарыхый контекстте ойлонуп көрөм: "Мен көргөн нерсе - мен ырдайм", биринчи жолу код жазып баштаганда эмнени көрдүм жана азыр эмнени байкап жатам, учурда биз эмнени колдонуп жатабыз жана эмне үчүн. Макала толук кандуу изилдөө болуп көрүнбөйт, кээ бир пункттар көз жаздымда калыптыр, бул менин болгон жана азыр эмне деген жеке көз карашым.
Ошентип, эски күндөрдө... жеткирүүнүн эң алгачкы ыкмасы магнитофондордон алынган кассеталар болчу. Менде BK-0010.01 компьютери бар болчу...
Калькуляторлордун доору
Жок, андан да мурдараак учур болгон, калькулятор да болгон и .
Ошентип, мен болгондо , анда программаны өткөрүп берүүнүн жолу программа жазылган кутучадагы кадимки кагаз эле, керек болсо аны кол менен иштетүү үчүн калькуляторго жазылган. Эгер сиз ойногуңуз келсе (ооба, атүгүл бул антидилювиялык эсептегичте оюндар бар болчу) - сиз отуруп, программаны калькуляторго киргизесиз. Албетте, эсептегич өчүрүлгөндө, программа унутулуп калган. Кагазга жекече жазылган калькулятордун коддорунан тышкары, программалар «Радио» жана «Технология для молодежь» журналдарында басылып, ошол кездеги китептерде да басылып чыккан.
Кийинки өзгөртүү калькулятор болгон , ал буга чейин туруксуз маалыматтарды сактоонун кандайдыр бир окшоштугуна ээ. Эми оюнду же программаны кол менен киргизүүнүн кереги жок болчу, бирок баскычтар менен сыйкырдуу өтүүлөрдү аткаргандан кийин, ал өзү жүктөлдү.
Калкулятордогу эң чоң программанын көлөмү 105 кадамды, ал эми МК-52деги туруктуу эс тутумдун көлөмү 512 кадамды түзгөн.
Айтмакчы, эгерде бул калькуляторлордун күйөрмандары ушул макаланы окуп жаткан болсо, макаланы жазуу процессинде мен Android үчүн калькулятор эмуляторун да, ал үчүн программаларды да таптым. Өткөнгө карай!
МК-52 жөнүндө кыскача баяндама (Википедиядан)
МК-52 «Союз ТМ-7» кораблинде космос мейкиндигине учту. Ал борттогу компьютер иштебей калган учурда конуу траекториясын эсептөө үчүн колдонулушу керек болчу.
52-жылдан бери, Elektronika-Astro эс тутумун кеңейтүү блогу менен MK-1988 навигациялык эсептөө комплектинин бир бөлүгү катары Аскер-деңиз флотунун кемелерине берилет.
Биринчи персоналдык компьютерлер
Келгиле, заманга кайрылалы . Ал жерде көбүрөөк эс тутум бар экени түшүнүктүү жана кагаздан кодду терүү мындан ары мүмкүнчүлүк болбой калды (бирок адегенде мен муну жөн эле кылгам, анткени башка каражат жок болчу). Магнитофондор учун аудио кассеталар программалык камсыздоону сактоонун жана жеткирүүнүн негизги каражатына айланууда.
Кассетада сактоо адатта бир же эки бинардык файлдар түрүндө болгон, калганынын баары ичинде камтылган. Ишенимдүүлүк өтө төмөн болчу, программанын 2-3 нускасын сактап калууга туура келди. Жүктөө убакыттары да капалантты жана энтузиасттар бул кемчиликтерди жоюу үчүн ар кандай жыштык коддоолору менен эксперимент жасашты. Ал убакта мен өзүм профессионалдык программалык камсыздоону иштеп чыгуу менен алектене элек болчумун (BASIC тилиндеги жөнөкөй программаларды эсепке албаганда), андыктан, тилекке каршы, баары ичинде кандайча уюштурулганын майда-чүйдөсүнө чейин айтып бербейм. Компьютерде бир гана оперативдүү эс бар экендигинин өзү маалыматтарды сактоо схемасынын жөнөкөйлүгүн аныктады.
Ишенимдүү жана чоң сактагычтын пайда болушу
Кийинчерээк дискеталар пайда болуп, көчүрүү процесси жөнөкөйлөштүрүлүп, ишенимдүүлүгү жогорулаган.
Бирок HDD форматында жетиштүү көлөмдүү жергиликтүү сактагычтар пайда болгондо гана кырдаал кескин өзгөрөт.
Жеткирүү түрү түп-тамырынан бери өзгөрүүдө: системаны конфигурациялоо процессин башкарган орнотуучу программалар пайда болот, ошондой эле алып салгандан кийин тазалоо, анткени программалар жөн эле эстутумда окулбастан, локалдык сактагычка көчүрүлгөн, андан керек болсо, керексиз нерселерди тазалай билүү.
Ошол эле учурда, берилген программалык камсыздоонун татаалдыгы өсүп жатат.
Жеткирүүдөгү файлдардын саны бир нечеден жүздөгөн жана миңдегенге чейин көбөйөт, китепкана версияларынын ортосундагы чыр-чатактар жана башка кубанычтар ар башка программалар бир эле маалыматты колдонгондо башталат.
Ал убакта мен үчүн Linuxтун бар экендиги али ачыла элек болчу; мен MS DOS, кийинчерээк Windows дүйнөсүндө жашап, Borland Pascal жана Delphi тилдеринде жазчумун, кээде C++ тилкесин карай берчүмүн. Көптөр ошол кездеги өнүмдөрдү жеткирүү үчүн InstallShield колдонушкан. , бул программалык камсыздоону жайылтуу жана конфигурациялоо боюнча бардык берилген тапшырмаларды ийгиликтүү чечти.
интернет доору
Бара-бара программалык камсыздоо системаларынын татаалдыгы ого бетер татаалдашып баратат, монолиттик жана рабочий тиркемелерден бөлүштүрүлгөн системаларга, жука кардарларга жана микросервистерге өтүү бар. Эми сиз бир эле программаны эмес, алардын жыйындысын конфигурациялашыңыз керек жана алардын баары чогуу иштеши үчүн.
Концепция толугу менен өзгөрдү, Интернет келди, булут кызматтарынын доору келди. Азырынча, баштапкы этапта гана, веб-сайттар түрүндө, эч ким кызматтарды өзгөчө кыялданган эмес. бирок бул тиркемелерди иштеп чыгууда жана жеткирүүдө да бурулуш болду.
Мен өзүм үчүн, ошол учурда иштеп чыгуучулардын муундары өзгөргөнүн белгиледим (же бул менин чөйрөмдө гана болгон) жана бардык эски жеткирүү ыкмалары бир заматта унутулуп, баары эң башынан башталган деген сезим пайда болду. башталышы: бардык жеткирүү тизе сценарийлери аткарыла баштады жана сыймыктануу менен "Үзгүлтүксүз жеткирүү" деп атады. Чындыгында, эскиси унутулуп, колдонулбай, жаңысы жөн эле жок болгон башаламандык мезгили башталды.
Ошол кезде мен иштеген биздин компанияда (атын атабай эле коёюн) кумурска аркылуу куруунун ордуна (maven али популярдуу эмес же такыр жок болчу) адамдар жөн гана IDEде банкаларды чогултуп, тынч иш кылган учурлар эсимде. ал SVNде. Демек, жайылтуу файлды SVNден алуудан жана аны SSH аркылуу каалаган машинага көчүрүүдөн турган. Бул ушунчалык жөнөкөй жана олдоксон.
Ошол эле учурда, PHPде жөнөкөй сайттарды жеткирүү жөн гана FTP аркылуу туураланган файлды максаттуу машинага көчүрүү менен абдан примитивдүү жол менен жасалган. Кээде андай болгон эмес - код продукт серверинде түз ободо редакцияланган жана кандайдыр бир жерде камдык көчүрмөлөр бар болсо, өзгөчө кооз болчу.
RPM жана DEB пакеттери
Башка жагынан алганда, Интернеттин өнүгүшү менен, UNIX сыяктуу системалар барган сайын популярдуу боло баштады, атап айтканда, мен RedHat Linux 6, болжол менен 2000-жылы ачылган. Албетте, программалык камсыздоону жеткирүү үчүн белгилүү бир каражаттар болгон; Wikipedia боюнча, RPM негизги пакет менеджери катары 1995-жылы RedHat Linux 2.0 версиясында пайда болгон. Ошондон бери жана ушул күнгө чейин, система RPM пакеттери түрүндө жеткирилип, ийгиликтүү иштеп жана өнүгүп келе жатат.
Дебиан үй-бүлөсүнүн бөлүштүрүүлөрү ушул сыяктуу жолду басып өтүштү жана бүгүнкү күнгө чейин өзгөрүүсүз калган deb пакеттер түрүндө жеткирүүнү ишке ашырышты.
Пакет менеджерлери программалык продукттарды өздөрү жеткирүүгө, орнотуу процессинде аларды конфигурациялоого, ар кандай пакеттердин ортосундагы көз карандылыкты башкарууга, өнүмдөрдү алып салууга жана орнотуу процессинде керексиз нерселерди тазалоого мүмкүндүк берет. Ошол. көпчүлүк учурда, ушундан улам алар дээрлик өзгөрүүсүз бир нече ондогон жылдар бою сакталган.
Булуттагы эсептөөлөр пакет менеджерлерине физикалык медиадан гана эмес, булут репозиторийлеринен да орнотууну кошту, бирок түп-тамырынан бери өзгөргөн жок.
Белгилей кетчү нерсе, учурда дебаттан алыстап, snap пакеттерине өтүү боюнча бир нече кадамдар бар, бирок бул жөнүндө кийинчерээк.
Ошентип, DEBди да, RPMди да билбеген булутту иштеп чыгуучулардын бул жаңы мууну да акырындык менен өсүп, тажрыйбага ээ болуп, өнүмдөр татаалдашып, FTP, bash скрипттерине жана ушул сыяктуу студенттик кол өнөрчүлүккө караганда бир нече акылга сыярлык жеткирүү ыкмалары керек болчу.
Жана бул жерде Docker сүрөткө келет, виртуалдаштыруунун, ресурстун делимитациясынын жана жеткирүү ыкмасынын аралашмасы. Бул азыр модалуу жана жаш, бирок ал бардыгына керекпи? Бул панацеябы?
Менин байкоолорум боюнча, Докерди көп учурда акылга сыярлык тандоо катары эмес, жөн гана, бир жагынан коомчулукта айтылып жаткандыктан, аны сунуштагандар гана билишет. Башка жагынан алганда, алар көпчүлүк учурда жакшы эски таңгак системалары жөнүндө унчукпайт - алар бар жана өз ишин тынч жана байкалбастан аткарышат. Мындай кырдаалда, чынында, башка тандоо жок - тандоо ачык - Docker.
Мен Dockerди кантип ишке ашырганыбыз жана натыйжада эмне болгону тууралуу тажрыйбам менен бөлүшүүгө аракет кылам.
Өз алдынча жазылган сценарийлер
Башында, талап кылынган машиналарга jar архивдерин жайгаштырган bash скрипттери бар болчу. Бул процессти Дженкинс башкарган. Бул ийгиликтүү иштеди, анткени jar архивинин өзү класстарды, ресурстарды жана ал тургай конфигурацияны камтыган жыйын. Эгер сиз бардыгын максималдуу түрдө киргизсеңиз, анда аны скриптке кеңейтүү сизге керек болгон эң кыйын нерсе эмес
Бирок скрипттердин бир нече кемчиликтери бар:
- скрипттер, адатта, шашылыш жазылат жана ошондуктан, алар бир гана эң жакшы сценарийди камтыйт. Бул иштеп чыгуучу тез жеткирүүгө кызыкдар экендиги менен шартталган жана кадимки скрипт татыктуу көлөмдөгү ресурстарды инвестициялоону талап кылат.
- мурунку пункттун натыйжасында, скрипттерде орнотуудан чыгаруу процедуралары жок
- белгиленген жаңылоо процедурасы жок
- Жаңы продукт пайда болгондо, жаңы сценарий жазуу керек
- көз карандылыкты колдоо жок
Албетте, сиз татаал сценарийди жаза аласыз, бирок, мен жогоруда жазгандай, бул өнүгүү убактысы, эң аз эмес, жана биз билгендей, ар дайым убакыт жетишсиз.
Мунун баары, албетте, бул жайылтуу ыкмасын колдонуу диапазонун эң жөнөкөй системалар менен чектейт. Муну өзгөртүүгө убакыт келди.
ютуб
Кайсы бир убакта бизге жаңыдан жасалган орточулар келе башташты, алар идеялар менен кайнап, докер жөнүндө жар салышат. Мейли, колунда желек - жасайлы! Эки аракет болду. Экөө тең ийгиликсиз болду – айталы, чоң амбициялардан, бирок реалдуу тажрыйбанын жоктугунан. Аны мажбурлап, кандайдыр бир жол менен бүтүрүү керек беле? Бул күмөн - команда тиешелүү куралдарды колдонуудан мурун талап кылынган деңгээлге чыгышы керек. Кошумчалай кетсек, даяр Docker сүрөттөрүн колдонууда биз тармактын туура иштебей калганына (бул Докердин өзүнүн нымдуулугунан улам болушу мүмкүн) же башка адамдардын контейнерлерин кеңейтүү кыйын болгон фактыларына көп жолукканбыз.
Кандай ыңгайсыздыктарга туш болдук?
- Көпүрө режиминде тармак көйгөйлөрү
- Журналдарды контейнерде көрүү ыңгайсыз (эгерде алар хост машинасынын файл тутумунда өзүнчө сакталбаса)
- ElasticSearch кээде контейнердин ичинде кызыктай катып калат, себеби аныктала элек, контейнер расмий
- Контейнердин ичиндеги кабыкты колдонуу керек - баары абдан тытылган, кадимки шаймандар жок
- Чогулган контейнерлердин чоң көлөмү - сактоо үчүн кымбат
- Контейнерлердин чоң көлөмүнөн улам бир нече версияны колдоо кыйын
- Башка методдордон (скрипттерден же деб топтомдордон) айырмаланып, куруу убактысы узунураак
Башка жагынан алганда, эмне үчүн жаз кызматын ошол эле деб аркылуу jar архиви түрүндө жайылтуу жаман? Ресурстарды изоляциялоо чындап эле зарылбы? Кызматты абдан кыскартылган контейнерге толтуруу менен иштөө тутумунун ыңгайлуу куралдарын жоготуунун кереги барбы?
Практика көрсөткөндөй, чындыгында бул зарыл эмес, деби пакети 90% учурларда жетиштүү.
Жакшы эски деб качан иштебей калат жана бизге качан докер керек?
Биз үчүн бул питондо кызматтарды жайылтуу болчу. Машиналарды үйрөнүү үчүн зарыл болгон жана операциялык системанын стандарттуу бөлүштүрүлүшүнө кирбеген көптөгөн китепканалар (жана туура эмес версиялар болгон), орнотуулар менен бузуктар, бир хост тутумунда жашаган ар кандай кызматтар үчүн ар кандай версияларга болгон муктаждык алып келди. Бул өзөктүк аралашманы жеткирүүнүн бирден-бир акылга сыярлык жолу докер болгон. Докердик контейнерди чогултуунун эмгек сыйымдуулугу анын бардыгын көз карандылыгы бар өзүнчө деб пакеттерге таңгактоо идеясына караганда төмөн болуп чыкты жана чындыгында акыл-эси бар эч ким муну жасабайт.
Докерди колдонууну пландап жаткан экинчи жагдай - бул көк-жашыл жайылтуу схемасын колдонуу менен кызматтарды жайылтуу. Бирок бул жерде мен акырындык менен татаалдыкты арттыргым келет: адегенде deb пакеттери курулат, андан кийин алардан докер контейнери курулат.
Снап пакеттери
Келгиле, пакеттерге кайтып келели. Алар биринчи жолу Ubuntu 16.04 расмий түрдө пайда болгон. Кадимки deb пакеттеринен жана rpm пакеттеринен айырмаланып, snap бардык көз карандылыктарды камтыйт. Бул, бир жагынан, китепкана чыр-чатактарын болтурбоого мүмкүндүк берет, экинчи жагынан, натыйжада топтомдун көлөмү чоңураак. Мындан тышкары, бул системанын коопсуздугуна да таасирин тийгизиши мүмкүн: тез жеткирүү учурунда, камтылган китепканаларга бардык өзгөртүүлөр пакетти түзгөн иштеп чыгуучу тарабынан көзөмөлдөнүшү керек. Жалпысынан алганда, баары ушунчалык жөнөкөй эмес жана универсалдуу бакыт аларды колдонуудан келбейт. Бирок, ошентсе да, бир эле Docker виртуалдаштыруу үчүн эмес, таңгактоо куралы катары гана колдонулса, бул толугу менен акылга сыярлык альтернатива.
Натыйжада, биз азыр deb пакеттерин да, докер контейнерлерин да акылга сыярлык айкалыштырууда колдонобуз, балким, кээ бир учурларда биз снап пакеттерге алмаштырабыз.
Сурамжылоого катталган колдонуучулар гана катыша алышат. , өтүнөмүн.
Сиз жеткирүү үчүн эмне колдоносуз?
-
Өз алдынча жазылган сценарийлер
-
FTPге кол менен көчүрүү
-
deb пакеттери
-
rpm пакеттери
-
пакеттерди чаптоо
-
Докер сүрөттөрү
-
Виртуалдык машина сүрөттөрү
-
Бүт HDDди клондоңуз
-
куурчак
-
түшүнүктүү
-
башка
109 колдонуучу добуш берди. 32 колдонуучу добуш берүүдөн баш тартты.
Source: www.habr.com