Kubernetes-д байршуулах эхний алхам бол таны програмыг контейнерт байрлуулах явдал юм. Энэ цувралд бид хэрхэн жижиг, найдвартай контейнер дүрсийг бүтээх талаар авч үзэх болно.
Docker-ийн ачаар контейнерийн зургийг бүтээх нь хэзээ ч амар байгаагүй. Үндсэн зургийг зааж, өөрчлөлтөө нэмж, контейнер үүсгэ.
Хэдийгээр энэ техник нь эхлэхэд маш сайн боловч анхдагч үндсэн зургуудыг ашиглах нь том хэмжээтэй зурагтай ажиллахад аюултай.
Нэмж дурдахад, Docker дээрх ихэнх зургууд Debian эсвэл Ubuntu-г үндсэн зураг болгон ашигладаг бөгөөд энэ нь маш сайн нийцтэй, хялбар тохируулах боломжийг олгодог (Docker файл нь зөвхөн хоёр мөр код авдаг) үндсэн зургууд нь таны контейнерт хэдэн зуун мегабайт нэмэлт ачааллыг нэмж өгдөг. Жишээлбэл, Go "hello-world" програмд зориулсан энгийн node.js файл нь ойролцоогоор 700 мегабайт байхад таны бодит хэрэглүүр хэдхэн мегабайт хэмжээтэй байна.
Тиймээс энэ бүх нэмэлт ачаалал нь дижитал орон зайг дэмий үрж, аюулгүй байдлын сул тал, алдаануудыг нуух сайхан газар юм. Тиймээс контейнер зургийн хэмжээг багасгах хоёр аргыг авч үзье.
Эхнийх нь жижиг суурь зургуудыг ашиглах, хоёр дахь нь Барилгачин загварыг ашиглах явдал юм. Жижиг суурь зургуудыг ашиглах нь савныхаа хэмжээг багасгах хамгийн хялбар арга юм. Таны ашиглаж буй хэл эсвэл стек нь анхдагч зургаас хамаагүй бага хэмжээтэй анхны програмын зургийг өгдөг байх магадлалтай. Манай node.js контейнерийг харцгаая.
Docker-д анхдагчаар зангилаа:8 үндсэн зургийн хэмжээ 670 МБ, зангилаа: 8-уулын зургийн хэмжээ ердөө 65 МБ буюу 10 дахин бага байна. Альпийн нурууны жижиг зургийг ашигласнаар та савныхаа хэмжээг эрс багасгах болно. Alpine нь жижиг хэмжээтэй, хөнгөн жинтэй Линукс түгээлт бөгөөд Docker хэрэглэгчдийн дунд маш их алдартай, учир нь энэ нь чингэлэгийг жижиг байлгахын зэрэгцээ олон програмд нийцдэг. Стандарт Docker "зангилаа" дүрсээс ялгаатай нь "node:alpine" нь маш олон үйлчилгээний файлууд болон програмуудыг устгаж, зөвхөн таны програмыг ажиллуулахад хангалттай файлуудыг үлдээдэг.
Жижиг суурь зураг руу шилжихийн тулд Dockerfile-г шинэчилж, шинэ үндсэн зурагтай ажиллаж эхлэхэд л хангалттай.
Одоо хуучин onbuild зургаас ялгаатай нь та кодыг саванд хуулж, ямар нэгэн хамаарлыг суулгах хэрэгтэй. Шинэ Dockerfile-д контейнер нь node:alpine зургаар эхэлж, кодын лавлах үүсгэн, NPM багц менежер ашиглан хамаарлыг суулгаж, эцэст нь server.js-г ажиллуулдаг.
Энэхүү шинэчлэлтийн үр дүнд савны хэмжээ 10 дахин бага байна. Хэрэв таны програмчлалын хэл эсвэл стек зураг багасгах үндсэн функцгүй бол Alpine Linux ашиглана уу. Энэ нь мөн савны агуулгыг бүрэн удирдах боломжийг олгоно. Жижиг суурь зургуудыг ашиглах нь жижиг савыг хурдан бүтээх гайхалтай арга юм. Гэхдээ Builder Pattern-ийг ашиглан илүү их хэмжээгээр бууруулах боломжтой.
Тайлбарласан хэлэнд эх кодыг эхлээд орчуулагч руу дамжуулж, дараа нь шууд гүйцэтгэнэ. Эмхэтгэсэн хэлнүүдэд эх кодыг эхлээд хөрвүүлсэн код болгон хувиргадаг. Гэсэн хэдий ч эмхэтгэл нь ихэвчлэн кодыг ажиллуулахад шаардлагагүй хэрэгслүүдийг ашигладаг. Энэ нь та эдгээр хэрэгслийг эцсийн савнаас бүрэн устгаж болно гэсэн үг юм. Үүний тулд та Builder Pattern ашиглаж болно.
Кодыг эхний саванд үүсгээд эмхэтгэнэ. Дараа нь эмхэтгэсэн кодыг хөрвүүлэхэд шаардлагатай хөрвүүлэгч, багаж хэрэгсэлгүйгээр эцсийн саванд савлана. Энэ процессоор Go програм ажиллуулъя. Эхлээд бид бүтээгдсэн зургаас Alpine Linux руу шилжих болно.
Шинэ Dockerfile-д контейнер нь golang:alpine зургаар эхэлдэг. Дараа нь кодын лавлах үүсгэн, түүнийг эх код руу хуулж, уг эх кодыг бүтээж, програмыг ажиллуулдаг. Энэ контейнер нь бүтээгдсэн контейнерээс хамаагүй бага боловч хөрвүүлэгч болон бусад Go хэрэгслүүдийг агуулсан хэвээр байна. Тиймээс эмхэтгэсэн программыг задлаад өөрийн саванд хийцгээе.
Та энэ Docker файлд хачирхалтай зүйлийг анзаарч магадгүй: энэ нь хоёр FROM мөрийг агуулж байна. Эхний 4 мөрийн хэсэг нь өмнөх Dockerfile-тэй яг адилхан харагдаж байгаа бөгөөд зөвхөн энэ үе шатыг нэрлэхдээ AS түлхүүр үгийг ашигладаг. Дараагийн хэсэг нь шинэ зургийг эхлүүлэхийн тулд шинэ FROM мөртэй бөгөөд голын зурагны оронд бид Raw alpine-ийг үндсэн зураг болгон ашиглах болно.
Raw Alpine Linux-д ямар ч SSL сертификат суулгаагүй бөгөөд энэ нь HTTPS-ээр дамжуулан ихэнх API дуудлагууд амжилтгүй болоход хүргэдэг тул зарим үндсэн CA сертификатуудыг суулгацгаая.
Одоо хөгжилтэй хэсэг ирлээ: эмхэтгэсэн кодыг эхний контейнерээс хоёр дахь руу хуулахын тулд та хоёр дахь хэсгийн 5-р мөрөнд байрлах COPY командыг ашиглаж болно. Энэ нь зөвхөн нэг програмын файлыг хуулах бөгөөд Go хэрэгсэлд нөлөөлөхгүй. Шинэ олон үе шаттай Docker файл нь 12 мегабайт байсан анхны контейнерийн дүрстэй харьцуулахад ердөө 700 мегабайт хэмжээтэй контейнер дүрсийг агуулна, энэ нь маш том ялгаа юм!
Тиймээс жижиг суурь зургууд болон Барилгачин хэв маягийг ашиглах нь маш их ажил хийхгүйгээр хамаагүй жижиг савыг бүтээх гайхалтай арга юм.
Хэрэглээний стекээс хамааран зураг болон савны хэмжээг багасгах нэмэлт аргууд байж болох ч жижиг савнууд үнэхээр хэмжигдэхүйц ашиг тустай юу? Жижиг савнууд нь маш үр дүнтэй байдаг хоёр талбарыг харцгаая - гүйцэтгэл ба аюулгүй байдал.
Гүйцэтгэлийн өсөлтийг үнэлэхийн тулд контейнер үүсгэх, бүртгэлд оруулах (түлхэх), дараа нь тэндээс татаж авах (татах) үйл явцын үргэлжлэх хугацааг анхаарч үзээрэй. Жижиг сав нь том савнаас илт давуу талтай болохыг харж болно.
Докер давхаргуудыг кэш хийх тул дараагийн бүтээцүүд маш хурдан байх болно. Гэсэн хэдий ч, контейнер барих, туршихад ашигладаг олон CI системүүд давхаргыг кэшлэдэггүй тул цагийг ихээхэн хэмнэдэг. Таны харж байгаагаар том сав барих хугацаа нь машиныхаа хүчнээс хамааран 34-54 секунд, харин савыг ашиглах үед Builder Pattern ашиглан 23-28 секунд хүртэл буурдаг. Энэ төрлийн үйл ажиллагааны хувьд бүтээмжийн өсөлт 40-50% байна. Тиймээс та өөрийн кодыг хэдэн удаа бүтээж, туршиж үзэхээ бодоорой.
Контейнер баригдсаны дараа та түүний зургийг (контейнерийн дүрсийг түлхэх) контейнерийн бүртгэлд оруулах хэрэгтэй бөгөөд ингэснээр та үүнийг Kubernetes кластерт ашиглах боломжтой болно. Би Google Container Registry ашиглахыг зөвлөж байна.
Google Container Registry (GCR)-ийн тусламжтайгаар та зөвхөн түүхий эд хадгалах болон сүлжээний төлбөрийг төлөх бөгөөд савны менежментийн нэмэлт хураамж байхгүй. Энэ нь хувийн, аюулгүй бөгөөд маш хурдан юм. GCR нь татах ажиллагааг хурдасгахын тулд олон заль мэх ашигладаг. Таны харж байгаагаар go:onbuild ашиглан Docker Container Image контейнер оруулахад компьютерийн гүйцэтгэлээс хамааран 15-48 секунд зарцуулагдах ба жижиг савтай ижил үйлдэл нь 14-16 секунд, бүтээмж багатай машинуудын хувьд болно. үйл ажиллагааны хурдны давуу тал нь 3 дахин нэмэгддэг. Томоохон машинуудын хувьд GCR нь зургийн нэгдсэн мэдээллийн санд зориулж дэлхийн кэш ашигладаг тул та тэдгээрийг огт ачаалах шаардлагагүй гэсэн үг юм. Бага хүчин чадалтай компьютерт CPU нь гацаа болдог тул жижиг сав ашиглах давуу тал нь энд хамаагүй их юм.
Хэрэв та GCR ашиглаж байгаа бол Google Container Builder (GCB)-г өөрийн бүтээх системийн нэг хэсэг болгон ашиглахыг зөвлөж байна.
Таны харж байгаагаар түүний хэрэглээ нь бүтээмжтэй машинаас ч илүү Build+Push үйлдлийн үргэлжлэх хугацааг багасгахад илүү сайн үр дүнд хүрэх боломжийг олгодог - энэ тохиолдолд контейнер барьж, хост руу илгээх үйл явц бараг 2 дахин хурдасдаг. . Нэмж дурдахад та өдөр бүр 120 үнэгүй барих минут авдаг бөгөөд энэ нь ихэнх тохиолдолд таны чингэлэг барих хэрэгцээг хангадаг.
Дараа нь хамгийн чухал гүйцэтгэлийн хэмжүүр ирдэг - татах, татах, татах хурд. Хэрэв та түлхэх ажиллагаанд зарцуулсан цагийг төдийлөн тоодоггүй бол татах үйл явцын үргэлжлэх хугацаа нь системийн ерөнхий гүйцэтгэлд ноцтой нөлөөлдөг. Танд гурван зангилаа байгаа бөгөөд тэдгээрийн нэг нь амжилтгүй болсон гэж бодъё. Хэрэв та Google Kubernetes Engine гэх мэт удирдлагын системийг ашиглаж байгаа бол энэ нь автоматаар үхсэн зангилааг шинээр солих болно. Гэсэн хэдий ч, энэ шинэ зангилаа бүрэн хоосон байх бөгөөд ажиллаж эхлэхийн тулд та бүх саваа чирэх хэрэгтэй болно. Хэрэв татах ажиллагаа хангалттай удаан үргэлжилбэл таны кластер бүх хугацаанд бага гүйцэтгэлтэй ажиллах болно.
Ийм зүйл тохиолдож болох олон тохиолдол байдаг: кластерт шинэ зангилаа нэмэх, зангилаануудыг шинэчлэх, эсвэл байршуулах шинэ контейнер руу шилжих. Тиймээс татах олборлох хугацааг багасгах нь гол хүчин зүйл болдог. Жижиг сав томоос хамаагүй хурдан татагддаг гэдгийг үгүйсгэх аргагүй. Хэрэв та Kubernetes кластерт олон контейнер ажиллуулж байгаа бол цаг хэмнэнэ.
Энэ харьцуулалтыг харна уу: жижиг чингэлэг дээрх татах ажиллагаа нь go:onbuild ашиглан хийсэн ижил үйлдлээс машины хүчнээс хамааран 4-9 дахин бага хугацаа зарцуулдаг. Хуваалцсан, жижиг савны суурь зургуудыг ашиглах нь шинэ Kubernetes зангилааг байршуулж, онлайн болох цаг хугацаа, хурдыг ихээхэн хурдасгадаг.
Аюулгүй байдлын асуудлыг авч үзье. Жижиг савнууд нь довтолгооны гадаргуу багатай тул том савнаас хамаагүй аюулгүй гэж үздэг. Үнэхээр тийм үү? Google Container Registry-ийн хамгийн ашигтай шинж чанаруудын нэг бол таны контейнерийг эмзэг байдлыг автоматаар сканнердах чадвар юм. Хэдэн сарын өмнө би угсармал болон олон үе шаттай савыг хоёуланг нь бүтээсэн тул энд ямар нэгэн эмзэг байдал байгаа эсэхийг харцгаая.
Үр дүн нь гайхалтай: жижиг саванд ердөө 3 дунд зэргийн эмзэг байдал, том саванд 16 чухал, бусад 376 эмзэг байдал илэрсэн. Хэрэв бид том савны агуулгыг харвал аюулгүй байдлын ихэнх асуудал нь манай програмтай ямар ч холбоогүй, харин бидний ашигладаггүй програмуудтай холбоотой болохыг харж болно. Тиймээс хүмүүс том довтолгооны гадаргуугийн талаар ярихдаа үүнийг л хэлэх гэсэн юм.
Энэ нь таны системд бодит гүйцэтгэл, аюулгүй байдлын үр өгөөжийг өгдөг учраас жижиг савнууд хий.
Зарим зар 🙂
Бидэнтэй хамт байсанд баярлалаа. Манай нийтлэл танд таалагдаж байна уу? Илүү сонирхолтой контент үзэхийг хүсч байна уу? Захиалга өгөх эсвэл найзууддаа санал болгох замаар биднийг дэмжээрэй, , Бидний танд зориулж бүтээсэн анхны түвшний серверүүдийн өвөрмөц аналоги: (RAID1 болон RAID10, 24 хүртэлх цөм, 40 ГБ хүртэл DDR4-тэй байх боломжтой).
Амстердам дахь Equinix Tier IV дата төвд Dell R730xd 2 дахин хямд байна уу? Зөвхөн энд Нидерландад! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 99 доллараас! тухай уншина уу
Эх сурвалж: www.habr.com