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