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