Қалай болғанда да, мен Docker контейнерлері мен деб пакеттері түрінде жеткізу туралы мақала жазуды шештім, бірақ мен бастаған кезде, қандай да бір себептермен мен алғашқы дербес компьютерлер мен тіпті калькуляторлардың алыс дәуірлеріне оралдым. Жалпы, докер мен дебтің құрғақ салыстыруларының орнына, мен сіздердің назарларыңызға ұсынатын эволюция тақырыбына қатысты осы ойларды алдық.
Кез келген өнім, ол қандай болса да, өнім серверлеріне қандай да бір жолмен жетуі керек, конфигурациялануы және іске қосылуы керек. Бұл мақала осы туралы болмақ.
Мен тарихи контексте ойланатын боламын: «Мен көргенім - бұл туралы ән айтатыным», кодты жазуды алғаш бастаған кезде не көргенімді және қазір нені байқаймын, біз қазір нені қолданып жатырмыз және не үшін. Мақала толыққанды зерттеу болып көрінбейді, кейбір тармақтар жіберілген, бұл менің болған және қазір не туралы жеке көзқарасым.
Сонымен, баяғыда... жеткізудің ең ерте жолы – магнитофондардың кассеталық таспалары. Менде BK-0010.01 компьютері болды...
Калькуляторлар дәуірі
Жоқ, одан да ертерек бір сәт болды, калькулятор да болды и .
Сондықтан менде болған кезде , содан кейін бағдарламаны тасымалдау тәсілі бағдарлама жазылған жәшіктегі кәдімгі қағаз парағы болды, қажет болған жағдайда оны қолмен іске қосу үшін калькуляторға жазылды. Егер сіз ойнағыңыз келсе (иә, тіпті бұл антидилювиялық калькуляторда ойындар болған) - сіз отырасыз және калькуляторға бағдарламаны енгізесіз. Әрине, калькулятор өшірілгенде, бағдарлама ұмытып кетті. Қағазға жеке жазылған калькулятор кодтарынан басқа, бағдарламалар «Радио» және «Жастар технологиясы» журналдарында жарияланып, сол кездегі кітаптарда да жарияланды.
Келесі модификация калькулятор болды , онда өзгермейтін деректерді сақтаудың кейбір ұқсастықтары бар. Енді ойынды немесе бағдарламаны қолмен енгізудің қажеті жоқ еді, бірақ түймелермен сиқырлы өтулерді орындағаннан кейін ол өздігінен жүктелді.
Калькулятордағы ең үлкен бағдарламаның көлемі 105 қадамды, ал МК-52-дегі тұрақты жадының өлшемі 512 қадамды құрады.
Айтпақшы, егер осы мақаланы оқып жатқан осы калькуляторлардың жанкүйерлері болса, мақаланы жазу барысында мен Android үшін калькулятор эмуляторын да, оған арналған бағдарламаларды да таптым. Өткенге алға!
МК-52 туралы қысқаша шолу (Википедиядан)
МК-52 ғарышқа «Союз ТМ-7» кемесімен ұшты. Ол борттық компьютер істен шыққан жағдайда қону траекториясын есептеу үшін пайдаланылуы керек еді.
52 жылдан бастап Электроника-Астро жады кеңейту блогы бар МК-1988 навигациялық есептеулер жинағының бөлігі ретінде Әскери-теңіз флотының кемелеріне жеткізілді.
Алғашқы дербес компьютерлер
Заманға оралайық . Ол жерде жадтың көбірек болғаны анық және қағаз парағынан кодты теру бұдан былай опция емес болды (бірақ басында мен мұны істедім, өйткені басқа құрал болмаған). Магнитофондарға арналған аудио кассеталар бағдарламалық қамтамасыз етуді сақтау мен жеткізудің негізгі құралына айналуда.
Кассетадағы сақтау әдетте бір немесе екі екілік файл түрінде болды, қалғанының бәрі оның ішінде болды. Сенімділік өте төмен болды, бағдарламаның 2-3 данасын сақтауға тура келді. Жүктеу уақыттары да көңілсіз болды және энтузиастар осы кемшіліктерді жою үшін әртүрлі жиілікті кодтаумен тәжірибе жасады. Ол кезде мен өзім кәсіби бағдарламалық жасақтаманы әзірлеумен әлі айналыспадым (BASIC-тегі қарапайым бағдарламаларды есептемегенде), сондықтан, өкінішке орай, мен барлығының ішінде қалай реттелгенін егжей-тегжейлі айтпаймын. Компьютерде тек оперативті жады болуының өзі деректерді сақтау схемасының қарапайымдылығын анықтады.
Сенімді және үлкен сақтау құралдарының пайда болуы
Кейінірек иілгіш дискілер пайда болды, көшіру процесі жеңілдетілді, сенімділік артты.
Бірақ қатты дискілер түрінде жеткілікті үлкен жергілікті қоймалар пайда болған кезде ғана жағдай күрт өзгереді.
Жеткізу түрі түбегейлі өзгереді: жүйені конфигурациялау процесін басқаратын, сондай-ақ жоюдан кейін тазалауды басқаратын орнатушы бағдарламалар пайда болады, өйткені бағдарламалар жадқа оқылып қана қоймай, жергілікті жадқа көшірілген, олардан сізге қажет. қажет болған жағдайда қажетсіз нәрселерді тазалай алу.
Сонымен бірге жеткізілетін бағдарламалық құралдың күрделілігі артып келеді.
Жеткізудегі файлдардың саны бірнешеден жүздеген және мыңдағанға дейін артады, кітапхана нұсқалары мен басқа қуаныштар арасындағы қайшылықтар әртүрлі бағдарламалар бірдей деректерді пайдаланған кезде басталады.
Ол кезде 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 пакеттері түрінде жеткізілді және сәтті жұмыс істеп, дамып келеді.
Debian отбасының дистрибуциялары осыған ұқсас жолмен жүрді және бүгінгі күнге дейін өзгеріссіз қалдырылған deb пакеттер түрінде жеткізуді жүзеге асырды.
Пакет менеджерлері бағдарламалық құрал өнімдерін өздері жеткізуге, орнату процесі кезінде оларды конфигурациялауға, әртүрлі бумалар арасындағы тәуелділіктерді басқаруға, өнімдерді жоюға және жою процесі кезінде қажет емес элементтерді тазалауға мүмкіндік береді. Анау. көп жағдайда, осының бәрі қажет, сондықтан олар бірнеше ондаған жылдар бойы іс жүзінде өзгеріссіз өмір сүрді.
Бұлтты есептеулер пакет менеджерлеріне физикалық медиадан ғана емес, сонымен қатар бұлттық репозиторийлерден орнатуды қосты, бірақ түбегейлі аз өзгерді.
Айта кету керек, қазіргі уақытта deb-тен бас тарту және жедел пакеттерге ауысу бағытында кейбір қадамдар бар, бірақ бұл туралы кейінірек.
Сонымен, DEB-ті де, RPM-ді де білмейтін бұлтты әзірлеушілердің бұл жаңа ұрпағы да баяу өсті, тәжірибе жинады, өнімдер күрделене түсті және FTP, bash сценарийлері және осыған ұқсас студенттік қолөнерге қарағанда біршама ақылға қонымды жеткізу әдістері қажет болды.
Міне, Docker суретке виртуализацияның, ресурстарды шектеудің және жеткізу әдісінің қоспасының бір түрін енгізеді. Бұл қазір сәнді және жас, бірақ ол бәріне қажет пе? Бұл панацея ма?
Менің байқауларым бойынша, Докер жиі ақылға қонымды таңдау ретінде емес, жай ғана, бір жағынан, бұл туралы қоғамда айтылып жүргендіктен ұсынылады, ал оны ұсынатындар оны біледі. Екінші жағынан, олар көп жағдайда ескі орауыш жүйелері туралы үндемейді - олар бар және өз жұмысын тыныш және байқалмай орындайды. Мұндай жағдайда шын мәнінде басқа таңдау жоқ - таңдау анық - Docker.
Мен Docker-ті қалай енгізгеніміз және нәтижесінде не болғаны туралы тәжірибеммен бөлісуге тырысамын.
Өздігінен жазылған сценарийлер
Бастапқыда jar мұрағатын қажетті машиналарға орналастыратын bash сценарийлері болды. Бұл процесті Дженкинс басқарды. Бұл сәтті жұмыс істеді, өйткені jar мұрағаты қазірдің өзінде сыныптарды, ресурстарды және тіпті конфигурацияны қамтитын жинақ болып табылады. Егер сіз бәрін оған максималды түрде салсаңыз, оны сценарийге кеңейту сізге қажет ең қиын нәрсе емес
Бірақ сценарийлердің бірнеше кемшіліктері бар:
- сценарийлер әдетте асығыс жазылады, сондықтан оларда ең жақсы жағдайдың бір ғана сценарийі болатыны соншалық. Бұл әзірлеушінің жылдам жеткізуге мүдделі екендігі және қалыпты сценарий жеткілікті ресурстарды инвестициялауды талап етеді.
- алдыңғы тармақтың салдары ретінде сценарийлерде жою процедуралары жоқ
- белгіленген жаңарту процедурасы жоқ
- Жаңа өнім пайда болған кезде жаңа сценарий жазу керек
- тәуелділікті қолдау жоқ
Әрине, сіз күрделі сценарий жаза аласыз, бірақ мен жоғарыда жазғанымдай, бұл даму уақыты, кем дегенде емес, және біз білетіндей, әрқашан уақыт жеткіліксіз.
Мұның бәрі бұл орналастыру әдісінің қолдану ауқымын ең қарапайым жүйелермен ғана шектейтіні анық. Мұны өзгертудің уақыты келді.
Докер
Бір кездері бізге жаңадан шығарылған орталар келе бастады, олар идеяларға толы және докер туралы мақтана бастады. Ал, қолымызда жалау – жасайық! Екі әрекет болды. Екеуі де сәтсіз болды - айталық, үлкен амбициялардан, бірақ нақты тәжірибенің жоқтығынан. Оны күштеп, кез келген әдіспен аяқтау керек пе еді? Бұл екіталай - команда тиісті құралдарды қолданар алдында қажетті деңгейге дейін дамуы керек. Сонымен қатар, дайын Docker кескіндерін пайдаланған кезде, біз жиі желінің дұрыс жұмыс істемеуі (бұл Docker-тің өзінің ылғалдылығына байланысты болуы мүмкін) немесе басқа адамдардың контейнерлерін кеңейту қиынға соғатын фактілерге жиі тап болдық.
Қандай қолайсыздықтарға тап болдық?
- Көпір режиміндегі желі ақаулары
- Контейнердегі журналдарды қарау ыңғайсыз (егер олар хост машинасының файлдық жүйесінде бөлек сақталмаса)
- ElasticSearch кейде контейнер ішінде біртүрлі қатып қалады, себебі анықталмаған, контейнер ресми
- Контейнердің ішінде қабықты пайдалану керек - бәрі өте тазартылған, таныс құралдар жоқ.
- Жиналған контейнерлердің үлкен өлшемі - сақтау қымбат
- Контейнерлердің үлкен көлеміне байланысты бірнеше нұсқаны қолдау қиын
- Басқа әдістерге қарағанда ұзағырақ құрастыру уақыты (скрипттер немесе deb пакеттері)
Екінші жағынан, бірдей deb арқылы jar мұрағаты түрінде Spring қызметін орналастыру неге нашар? Ресурстарды оқшаулау шынымен қажет пе? Қызметті айтарлықтай азайтылған контейнерге толтыру арқылы ыңғайлы операциялық жүйе құралдарын жоғалту керек пе?
Тәжірибе көрсеткендей, іс жүзінде бұл қажет емес, deb пакеті 90% жағдайда жеткілікті.
Жақсы ескі деб қашан сәтсіздікке ұшырайды және бізге докер қашан қажет?
Біз үшін бұл питонда қызметтерді қолдану болды. Машиналық оқыту үшін қажет және операциялық жүйенің стандартты дистрибутивіне кірмейтін көптеген кітапханалар (және дұрыс емес нұсқалар болды), баптаулары бар бұзулар, бір хост жүйесінде тұратын әртүрлі қызметтер үшін әртүрлі нұсқалардың қажеттілігі әкелді. Бұл ядролық қоспаны жеткізудің жалғыз ақылға қонымды жолы докер болды. Докерлік контейнерді жинаудағы еңбек сыйымдылығы оның барлығын тәуелділіктері бар жеке дебют пакеттеріне орау идеясынан төмен болды және іс жүзінде олардың ақыл-ойы бар ешкім мұны істемейді.
Docker қолданбасын пайдалануды жоспарлайтын екінші нүкте - көк-жасыл орналастыру схемасы арқылы қызметтерді орналастыру. Бірақ бұл жерде мен күрделіліктің біртіндеп өсуін алғым келеді: алдымен deb пакеттері құрастырылады, содан кейін олардан докер контейнері құрастырылады.
Қаптама пакеттері
Снап пакеттеріне оралайық. Олар алғаш рет Ubuntu 16.04-те ресми түрде пайда болды. Кәдімгі deb бумалары мен rpm пакеттерінен айырмашылығы, snap барлық тәуелділіктерді қамтиды. Бір жағынан, бұл кітапханалық қақтығыстарды болдырмауға мүмкіндік береді, екінші жағынан, нәтижесінде алынған бума көлемі бойынша үлкенірек. Бұған қоса, бұл жүйенің қауіпсіздігіне де әсер етуі мүмкін: жылдам жеткізілім жағдайында енгізілген кітапханаларға енгізілген барлық өзгерістерді пакетті жасайтын әзірлеуші бақылауы керек. Жалпы, бәрі соншалықты қарапайым емес және әмбебап бақыт оларды пайдаланудан туындамайды. Бірақ, соған қарамастан, егер бірдей Docker виртуализация үшін емес, тек орау құралы ретінде пайдаланылса, бұл толығымен ақылға қонымды балама.
Нәтижесінде, біз қазір deb бумаларын да, докерлік контейнерлерді де ақылға қонымды комбинацияда қолданамыз, мүмкін, кейбір жағдайларда біз жедел пакеттермен ауыстырамыз.
Сауалнамаға тек тіркелген пайдаланушылар қатыса алады. , өтінемін.
Жеткізу үшін не қолданасыз?
-
Өздігінен жазылған сценарийлер
-
FTP-ге қолмен көшіріңіз
-
deb пакеттері
-
айн/мин пакеттері
-
қаптамалар
-
Докер кескіндері
-
Виртуалды машина кескіндері
-
Толық қатты дискіні клондаңыз
-
қуыршақ
-
мүмкін емес
-
Басқа
109 пайдаланушы дауыс берді. 32 пайдаланушы қалыс қалды.
Ақпарат көзі: www.habr.com