Kubernetes үшін ең танымал пакет менеджері туралы әңгіменің мәні эмодзи арқылы бейнеленуі мүмкін:
- қорап - Helm (бұл соңғы эмодзи шығарылымына ең жақын нәрсе);
- құлып - қауіпсіздік;
- Кішкентай адам - мәселенің шешімі.
Шындығында, бәрі біршама күрделірек болады және әңгіме техникалық мәліметтерге толы Рульді қалай қауіпсіз етуге болады.
- Егер сіз білмесеңіз немесе ұмытып қалсаңыз, Helm дегеніміз не екенін қысқаша айтып беріңіз. Ол қандай мәселелерді шешеді және ол экожүйеде қай жерде орналасқан.
- Helm архитектурасын қарастырайық. Қауіпсіздік туралы және құралды немесе шешімді қалай қауіпсіз ету туралы әңгіме құрамдастың архитектурасын түсінбестен аяқталмайды.
- Helm құрамдастарын талқылайық.
- Ең өзекті мәселе - болашақ - Helm 3-тің жаңа нұсқасы.
Осы мақаладағы барлығы Helm 2-ге қатысты. Бұл нұсқа қазір өндірілуде және сіз пайдаланып жатқан нұсқа болуы мүмкін және ол қауіпсіздік тәуекелдерін қамтитын нұсқа.
Спикер туралы: Александр Хайоров () контентті жақсартуға көмектесетін 10 жыл бойы дамып келеді және комитетке кірді . Қазір ол Chainstack-те әзірлеуші жетекші ретінде жұмыс істейді - бұл әзірлеу менеджері мен соңғы шығарылымдарды жеткізуге жауапты адам арасындағы гибрид. Яғни, ол өнімді жасаудан бастап, оның жұмыс істеуіне дейін барлығы болатын ұрыс даласында орналасқан.
Chainstack – шағын, белсенді дамып келе жатқан стартап, оның міндеті – клиенттерге орталықтандырылмаған қолданбаларды пайдаланудың инфрақұрылымы мен күрделілігін ұмытуға мүмкіндік беру; әзірлеушілер тобы Сингапурда орналасқан. Chainstack-тен криптовалютаны сатуды немесе сатып алуды сұрамаңыз, бірақ кәсіпорынның блокчейн шеңберлері туралы сөйлесуді ұсыныңыз, олар сізге қуана жауап береді.
Хельм
Бұл Kubernetes үшін пакет (диаграмма) менеджері. Қолданбаларды Kubernetes кластеріне жеткізудің ең интуитивті және әмбебап тәсілі.
Біз, әрине, өзіңіздің YAML манифесттеріңізді жасаудан және шағын утилиталарды жазудан гөрі құрылымдық және өнеркәсіптік тәсіл туралы айтып отырмыз.
Helm - қазіргі уақытта қол жетімді және танымал.
Неліктен Helm? Ең алдымен, оны CNCF қолдайтындықтан. Cloud Native - үлкен ұйым және Kubernetes, etcd, Fluentd және т.б. жобалардың бас компаниясы болып табылады.
Тағы бір маңызды факт, Helm - өте танымал жоба. Мен 2019 жылдың қаңтарында Helm-ді қалай қауіпсіз ету керектігі туралы айта бастағанда, жобаның GitHub-та мыңдаған жұлдызы болды. Мамыр айында олардың саны 12 мыңға жетті.
Көптеген адамдар Helm-ге қызығушылық танытады, сондықтан оны әлі пайдаланбасаңыз да, оның қауіпсіздігі туралы білу сізге пайдалы болады. Қауіпсіздік маңызды.
Негізгі Helm командасына Microsoft Azure қолдау көрсетеді және сондықтан басқаларға қарағанда айтарлықтай тұрақты жоба. Шілде айының ортасында Helm 3 Alpha 2 шығарылымы жобада жұмыс істейтін адамдар өте көп екенін және оларда Helm-ді дамытуға және жақсартуға ынта мен күш бар екенін көрсетеді.
Helm Kubernetes қолданбасын басқарудың бірнеше негізгі мәселелерін шешеді.
- Қолданбаның қаптамасы. Тіпті WordPress-тегі «Сәлем, әлем» сияқты қолданба бірнеше қызметтерден тұрады және сіз оларды біріктіргіңіз келеді.
- Осы қолданбаларды басқарумен бірге келетін күрделілікті басқару.
- Қолданба орнатылғаннан немесе орналастырылғаннан кейін аяқталмайтын өмірлік цикл. Ол өмір сүруін жалғастыруда, оны жаңарту қажет және Хельм бұған көмектеседі және бұл үшін дұрыс шаралар мен саясаттарды енгізуге тырысады.
Қаптау ол анық түрде ұйымдастырылған: Linux, Windows немесе MacOS үшін кәдімгі пакет менеджерінің жұмысына толық сәйкес метадеректер бар. Яғни, репозиторий, әртүрлі пакеттерге тәуелділіктер, қолданбаларға арналған мета ақпарат, баптаулар, конфигурация мүмкіндіктері, ақпаратты индекстеу және т.б. Helm мұның бәрін қолданбалар үшін алуға және пайдалануға мүмкіндік береді.
Күрделілікті басқару. Егер сізде бірдей типтегі көптеген қолданбалар болса, онда параметрлеу қажет. Үлгілер осыдан келеді, бірақ үлгілерді жасаудың жеке әдісін ойлап таппау үшін Helm қораптан тыс ұсынатын нәрсені пайдалануға болады.
Қолданбаның өмірлік циклін басқару - менің ойымша, бұл ең қызықты және шешімін таппаған сұрақ. Міне, сол күні мен Хельмге келдім. Біз қолданбаның өмірлік циклін қадағалап отыруымыз керек және CI/CD және қолданба циклдерін осы парадигмаға жылжытқымыз келді.
Helm сізге мүмкіндік береді:
- орналастыруларды басқарады, конфигурациялау және қайта қарау түсінігін енгізеді;
- кері қайтаруды сәтті жүзеге асыру;
- әртүрлі оқиғалар үшін ілмектерді пайдаланыңыз;
- қосымша қолданба тексерулерін қосыңыз және олардың нәтижелеріне жауап беріңіз.
Сонымен қатар Рульде «батареялар» бар - сіздің өміріңізді жеңілдететін плагиндер түрінде қосуға болатын көптеген дәмді заттардың саны. Плагиндерді дербес жазуға болады, олар айтарлықтай оқшауланған және үйлесімді архитектураны қажет етпейді. Егер сіз бірдеңені жүзеге асырғыңыз келсе, мен оны плагин ретінде орындауды ұсынамын, содан кейін оны жоғары ағынға қосуға болады.
Helm үш негізгі тұжырымдамаға негізделген:
- Диаграмма репо — манифестіңіз үшін мүмкін болатын параметрлердің сипаттамасы және массиві.
- конфигурациясы —яғни, қолданылатын мәндер (мәтін, сандық мәндер және т.б.).
- босату екі жоғарғы құрамдастарды жинайды және олар бірге Шығаруға айналады. Шығарылымдарды нұсқалауға болады, осылайша ұйымдастырылған өмірлік циклге қол жеткізуге болады: орнату кезінде шағын және жаңарту, төмендету немесе кері қайтару кезінде үлкен.
Руль архитектурасы
Диаграмма концептуалды түрде Хельмнің жоғары деңгейлі архитектурасын бейнелейді.
Хельм Кубернетеске қатысты нәрсе екенін еске салайын. Сондықтан біз Кубернетес кластерісіз (тіктөртбұрыш) жасай алмаймыз. kube-apiserver құрамдас бөлігі мастерде орналасқан. Helm жоқ бізде Kubeconfig бар. Helm компьютерде, ноутбукта, негізгі фреймде - кез келген нәрседе орнатылған Helm CLI утилитасын, егер сіз оны осылай атасаңыз, бір шағын екілік әкеледі.
Бірақ бұл жеткіліксіз. Helm жүйесінде Tiller деп аталатын сервер компоненті бар. Ол кластердегі Helm мүдделерін білдіреді; бұл кез келген басқа сияқты Kubernetes кластеріндегі қолданба.
Диаграмма репосының келесі құрамдас бөлігі диаграммалары бар репозиторий болып табылады. Ресми репозиторий бар және компанияның немесе жобаның жеке репозиторийі болуы мүмкін.
Өзара әрекеттесу
Helm көмегімен қолданбаны орнатқымыз келгенде архитектуралық құрамдастардың өзара әрекеттесетінін қарастырайық.
- Біз сөйлейміз
Helm install, репозиторийге (Chart Repo) кіріп, Helm диаграммасын алыңыз.
- Helm утилитасы (Helm CLI) қай кластерге хабарласу керектігін анықтау үшін Kubeconfig бағдарламасымен өзара әрекеттеседі.
- Осы ақпаратты алған утилита біздің кластерімізде орналасқан Tiller қолданбасына сілтеме жасайды.
- Tiller Kubernetes-те әрекеттерді орындау, кейбір нысандарды (қызметтер, бөлімдер, репликалар, құпиялар және т.б.) жасау үшін Kube-apiserver шақырады.
Әрі қарай, біз бүкіл Helm архитектурасы ұшырауы мүмкін шабуыл векторын көру үшін диаграмманы күрделендіреміз. Содан кейін біз оны қорғауға тырысамыз.
Шабуыл векторы
Бірінші ықтимал әлсіз нүкте артықшылықты API-пайдаланушы. Схеманың бөлігі ретінде бұл Helm CLI-ге әкімші рұқсатын алған хакер.
Артықшылықсыз API пайдаланушысы жақын жерде болса да қауіп төндіруі мүмкін. Мұндай пайдаланушыда басқа контекст болады, мысалы, оны Kubeconfig параметрлерінде бір кластер аттар кеңістігінде бекітуге болады.
Ең қызықты шабуыл векторы Tiller маңындағы кластер ішінде орналасқан және оған қол жеткізе алатын процесс болуы мүмкін. Бұл кластердің желілік ортасын көретін веб-сервер немесе микросервис болуы мүмкін.
Экзотикалық, бірақ барған сайын танымал шабуыл нұсқасы Chart Repo-ны қамтиды. Жоқсыз автор жасаған диаграммада қауіпті ресурстар болуы мүмкін және сіз оны сеніммен толтырасыз. Немесе ол ресми репозиторийден жүктеп алатын диаграмманы ауыстыра алады және, мысалы, саясаттар түріндегі ресурсты жасап, оған қолжетімділікті арттыра алады.
Осы төрт жақтан жасалған шабуылдарды болдырмауға тырысайық және Helm архитектурасында қай жерде проблемалар бар және қай жерде, мүмкін, жоқ екенін анықтайық.
Диаграмманы үлкейтейік, көбірек элементтерді қосыңыз, бірақ барлық негізгі компоненттерді сақтаңыз.
Helm CLI диаграмма репосымен байланысады, Kubeconfig-пен әрекеттеседі және жұмыс кластерге Tiller компонентіне тасымалданады.
Тіллер екі нысанмен ұсынылған:
- Белгілі бір қызметті ашатын Tiller-deploy svc;
- Бүкіл жүктеме орындалатын, кластерге кіретін қондырғышты орналастыру (диаграммада бір көшірмедегі бір көшірме).
Өзара әрекеттесу үшін әртүрлі протоколдар мен схемалар қолданылады. Қауіпсіздік тұрғысынан бізді ең қызықтырады:
- Helm CLI диаграмма репосына кіру механизмі: қандай протокол, аутентификация бар ма және онымен не істеуге болады.
- Helm CLI kubectl көмегімен Tiller-мен байланысатын протокол. Бұл кластер ішінде орнатылған RPC сервері.
- Tiller өзі кластерде орналасқан және Kube-аписервермен әрекеттесетін микросервистерге қол жетімді.
Осы салалардың барлығын ретімен талқылайық.
RBAC
RBAC қосылмайынша Helm немесе кластердегі кез келген басқа қызмет қауіпсіздігі туралы айтудың қажеті жоқ.
Бұл соңғы ұсыныс емес сияқты, бірақ мен көптеген адамдар RBAC-ны өндірісте әлі де қоспағанына сенімдімін, өйткені бұл көп әбігерге түседі және көп нәрсені конфигурациялау керек. Дегенмен, мен сізді мұны істеуге шақырамын.
— RBAC сайтының заңгері. Онда RBAC орнатуға көмектесетін, оның неліктен жақсы екенін және онымен өндірісте қалай өмір сүру керектігін көрсететін көптеген қызықты материалдар бар.
Мен Tiller және RBAC қалай жұмыс істейтінін түсіндіруге тырысамын. Тиллер белгілі бір қызмет тіркелгісі бойынша кластер ішінде жұмыс істейді. Әдетте, RBAC конфигурацияланбаған болса, бұл суперпайдаланушы болады. Негізгі конфигурацияда Tiller әкімші болады. Сондықтан Tiller сіздің кластеріңізге SSH туннелі болып табылады деп жиі айтылады. Шын мәнінде, бұл дұрыс, сондықтан жоғарыдағы диаграммадағы Әдепкі қызмет тіркелгісі орнына бөлек арнайы қызмет тіркелгісін пайдалануға болады.
Helm бағдарламасын инициализациялағанда және оны серверге бірінші рет орнатқанда, қызмет тіркелгісін пайдаланып орнатуға болады --service-account. Бұл ең аз талап етілетін құқықтар жинағы бар пайдаланушыны пайдалануға мүмкіндік береді. Рас, сізге осындай « гирляндия » жасау керек болады: Рөл және Рөл байланыстыру.
Өкінішке орай, Helm мұны сіз үшін жасамайды. Сізге немесе Kubernetes кластерінің әкімшісіне Helm жүйесінен өту үшін қызмет тіркелгісі үшін рөлдер мен RoleBindings жинағын алдын ала дайындау қажет.
Сұрақ туындайды - Role және ClusterRole арасындағы айырмашылық неде? Айырмашылығы мынада: ClusterRole тек арнайы аттар кеңістігі үшін жұмыс істейтін әдеттегі рөлдер мен RoleBindings сияқты барлық аттар кеңістігі үшін жұмыс істейді. Бүкіл кластер және барлық аттар кеңістігі үшін саясаттарды теңшей аласыз немесе әрбір аттар кеңістігі үшін жекелендірілген.
Айта кетейік, RBAC тағы бір үлкен мәселені шешеді. Көптеген адамдар Helm, өкінішке орай, көп пәтерлі емес (көп жалға беруді қолдамайды) деп шағымданады. Егер бірнеше команда кластерді қолданса және Helm пайдаланса, бұл кластер ішінде саясаттарды орнату және оларға қол жеткізуді шектеу негізінен мүмкін емес, себебі Helm жұмыс істейтін белгілі бір қызмет тіркелгісі бар және ол кластердегі барлық ресурстарды оның астынан жасайды. , бұл кейде өте ыңғайсыз. Бұл дұрыс - екілік файлдың өзі сияқты, процесс сияқты, Helm Tiller көп жалдау түсінігі жоқ.
Дегенмен, Tiller бағдарламасын кластерде бірнеше рет іске қосуға мүмкіндік беретін тамаша әдіс бар. Бұл мәселе жоқ, Tiller кез келген атау кеңістігінде іске қосылуы мүмкін. Осылайша, RBAC, Kubeconfig контекст ретінде пайдалануға және арнайы Helm-ге кіруді шектеуге болады.
Бұл келесідей болады.
Мысалы, әртүрлі топтарға арналған мәтінмәні бар екі Kubeconfig бар (екі аттар кеңістігі): әзірлеу тобына арналған X тобы және әкімші кластері. Әкімші кластерінде Kube жүйесінің аттар кеңістігінде орналасқан кең Tiller бар, сәйкесінше жетілдірілген қызмет тіркелгісі. Және әзірлеу тобына арналған бөлек аттар кеңістігі, олар өз қызметтерін арнайы аттар кеңістігіне орналастыра алады.
Бұл тиімді тәсіл, Тиллер соншалықты қуатқа мұқтаж емес, бұл сіздің бюджетіңізге қатты әсер етеді. Бұл жылдам шешімдердің бірі.
Tiller-ді бөлек конфигурациялауға және Kubeconfig-ті командаға, белгілі бір әзірлеушіге немесе ортаға арналған мәтінмәнмен қамтамасыз етуден тартынбаңыз: Әзірлеу, Сахналау, Өндіріс (бәрі бір кластерде болатыны күмәнді, бірақ мұны істеуге болады).
Әңгімені жалғастыра отырып, RBAC-тан ауысып, ConfigMaps туралы сөйлесейік.
ConfigMaps
Helm деректер қоймасы ретінде ConfigMaps пайдаланады. Біз архитектура туралы айтқан кезде шығарылымдар, конфигурациялар, кері қайтарулар және т.б. туралы ақпаратты сақтайтын ешбір жерде дерекқор болған жоқ. Бұл үшін ConfigMaps пайдаланылады.
ConfigMaps-тің негізгі проблемасы белгілі - олар негізінен қауіпті; құпия деректерді сақтау мүмкін емес. Біз қызмет шеңберінен шықпауы керек барлық нәрселер туралы айтып отырмыз, мысалы, парольдер. Дәл қазір Helm үшін ең табиғи әдіс - ConfigMaps пайдаланудан құпияларға ауысу.
Бұл өте қарапайым түрде жасалады. Tiller параметрін қайта анықтап, сақтаудың құпия болатынын көрсетіңіз. Содан кейін әрбір орналастыру үшін сіз ConfigMap емес, құпияны аласыз.
Құпиялардың өзі оғаш ұғым және өте қауіпсіз емес деп дауласуға болады. Дегенмен, мұны Kubernetes әзірлеушілерінің өздері жасайтынын түсіну керек. 1.10 нұсқасынан бастап, яғни. Біраз уақыттан бері, кем дегенде, жалпы бұлттарда құпияларды сақтау үшін дұрыс жадты қосу мүмкін болды. Команда қазір құпияларға, жеке бөлімдерге немесе басқа нысандарға қолжетімділікті жақсырақ тарату жолдарын әзірлеуде.
Сақтау рульін құпияларға ауыстырған дұрыс, және олар өз кезегінде орталықтан қорғалған.
Әрине қалады деректерді сақтау шегі 1 МБ. Helm мұнда ConfigMaps үшін бөлінген жады ретінде etcd пайдаланады. Онда олар бұл репликация үшін қолайлы деректер бөлігі деп есептеді және т.б. Бұл туралы Reddit-те қызықты пікірталас бар, мен бұл қызықты оқуды демалыс күндері табуға немесе үзінді оқуды ұсынамын. .
Диаграмма репосы
Диаграммалар ең әлеуметтік осал болып табылады және «Ортадағы адам» көзі бола алады, әсіресе егер сіз акция шешімін пайдалансаңыз. Ең алдымен, біз HTTP арқылы ашылатын репозиторийлер туралы айтып отырмыз.
Сіз міндетті түрде Helm Repo-ны HTTPS арқылы ашуыңыз керек - бұл ең жақсы нұсқа және арзан.
Назар аударыңыз диаграммаға қол қою механизмі. Технологиясы қарапайым. Бұл жалпы және жеке кілттері бар кәдімгі PGP құрылғысы GitHub жүйесінде қолданатын нәрсе. Қажетті кілттерге ие бола отырып және бәріне қол қойып, бұл шынымен сіздің диаграммаңыз екеніне көз жеткізіңіз.
Сонымен қатар, Helm клиенті TLS қолдайды (сервер жағындағы HTTP мағынасында емес, өзара TLS). Байланыс жасау үшін сервер мен клиент кілттерін пайдалануға болады. Шынымды айтсам, мен мұндай механизмді қолданбаймын, өйткені мен өзара сертификаттарды ұнатпаймын. Негізі, - Helm 2 үшін Helm Repo орнатудың негізгі құралы - сонымен қатар негізгі аутентификацияны қолдайды. Егер ол ыңғайлырақ және тыныш болса, негізгі аутентификацияны пайдалануға болады.
Сондай-ақ плагин бар , бұл Google Cloud Storage жүйесінде диаграмма реполарын орналастыруға мүмкіндік береді. Бұл өте ыңғайлы, тамаша жұмыс істейді және өте қауіпсіз, өйткені барлық сипатталған механизмдер қайта өңделеді.
Егер сіз HTTPS немесе TLS қоссаңыз, mTLS пайдалансаңыз және тәуекелдерді одан әрі азайту үшін негізгі аутентификацияны қоссаңыз, Helm CLI және Chart Repo көмегімен қауіпсіз байланыс арнасын аласыз.
gRPC API
Келесі қадам өте маңызды - кластерде орналасқан және бір жағынан сервер болып табылатын Tiller-ді қорғау, екінші жағынан, оның өзі басқа компоненттерге кіріп, өзін біреу ретінде көрсетуге тырысады.
Жоғарыда айтқанымдай, Tiller - бұл gRPC ашатын қызмет, Helm клиенті оған gRPC арқылы келеді. Әдепкі бойынша, әрине, TLS өшірілген. Неліктен бұл жасалды - бұл даулы мәселе, менің ойымша, бастапқыда орнатуды жеңілдету.
Өндіріс және тіпті қою үшін мен gRPC жүйесінде TLS қосуды ұсынамын.
Менің ойымша, диаграммаларға арналған mTLS-тен айырмашылығы, бұл жерде орынды және өте қарапайым орындалады - PQI инфрақұрылымын жасаңыз, сертификат жасаңыз, Tiller іске қосыңыз, инициализация кезінде сертификатты тасымалдаңыз. Осыдан кейін сіз өзіңізді жасалған сертификат пен жеке кілтпен көрсете отырып, барлық Helm пәрмендерін орындай аласыз.
Осылайша сіз өзіңізді кластерден тыс Тиллерге барлық сұраулардан қорғайсыз.
Сонымен, біз Tiller-ге қосылу арнасын қамтамасыз еттік, біз RBAC-ты талқыладық және Kubernetes аписерверінің құқықтарын реттедік, ол өзара әрекеттесе алатын доменді азайтты.
Қорғалған руль
Соңғы диаграмманы қарастырайық. Бұл бірдей көрсеткілері бар бірдей архитектура.
Енді барлық қосылымдарды жасыл түспен қауіпсіз түрде салуға болады:
- Chart Repo үшін TLS немесе mTLS және негізгі аутентификацияны қолданамыз;
- Tiller үшін mTLS және ол TLS бар gRPC қызметі ретінде көрсетіледі, біз сертификаттарды қолданамыз;
- кластер Role және RoleBinding бар арнайы қызмет тіркелгісін пайдаланады.
Біз кластерді айтарлықтай қамтамасыз еттік, бірақ біреу ақылды айтты:
«Бір ғана қауіпсіз шешім болуы мүмкін - бетон қорапта орналасқан және сарбаздар күзететін өшірілген компьютер».
Деректерді өңдеудің және жаңа шабуыл векторларын табудың әртүрлі тәсілдері бар. Дегенмен, бұл ұсыныстар қауіпсіздіктің негізгі салалық стандартына қол жеткізетініне сенімдімін.
сыйақы
Бұл бөлік қауіпсіздікке тікелей қатысты емес, сонымен қатар пайдалы болады. Мен сізге аз адамдар білетін қызықты нәрселерді көрсетемін. Мысалы, диаграммаларды қалай іздеу керек - ресми және бейресми.
Репозиторийде Қазір шамамен 300 диаграмма және екі ағын бар: тұрақты және инкубатор. Үлес қосқан кез келген адам инкубатордан қораға жетудің қаншалықты қиын екенін және қорадан ұшудың қаншалықты оңай екенін жақсы біледі. Дегенмен, бұл Prometheus және сізге ұнайтын кез келген басқа диаграммаларды іздеудің ең жақсы құралы емес, бір қарапайым себеппен - бұл пакеттерді ыңғайлы іздеуге болатын портал емес.
Бірақ қызмет бар , бұл диаграммаларды табуды әлдеқайда ыңғайлы етеді. Ең бастысы, көптеген сыртқы репозиторийлер және 800-ге жуық шебер қол жетімді. Сонымен қатар, қандай да бір себептермен диаграммаларыңызды тұрақты күйге жібергіңіз келмесе, репозиторийді қосуға болады.
hub.helm.sh сайтын қолданып көріңіз және оны бірге дамытайық. Бұл қызмет Helm жобасы аясында және егер сіз алдыңғы қатарлы әзірлеуші болсаңыз және жай ғана сыртқы түрін жақсартқыңыз келсе, оның UI-ге үлес қоса аласыз.
Сондай-ақ назарларыңызды аударғым келеді Open Service Broker API интеграциясы. Бұл қиын және түсініксіз болып көрінеді, бірақ ол кез келген адамның алдында тұрған мәселелерді шешеді. Қарапайым мысалмен түсіндірейін.
Kubernetes кластері бар, онда біз классикалық қосымшаны іске қосқымыз келеді - WordPress. Жалпы, толық жұмыс істеу үшін дерекқор қажет. Көптеген әртүрлі шешімдер бар, мысалы, сіз өзіңіздің жеке мемлекеттік қызметіңізді іске қоса аласыз. Бұл өте ыңғайлы емес, бірақ оны көптеген адамдар жасайды.
Басқалары, Chainstack-тегі біз сияқты, серверлері үшін MySQL немесе PostgreSQL сияқты басқарылатын дерекқорларды пайдаланады. Сондықтан біздің дерекқорлар бұлттың бір жерінде орналасқан.
Бірақ мәселе туындайды: бізге қызметімізді дерекқормен қосу, дерекқордың дәмін жасау, тіркелгі деректерін тасымалдау және оны қандай да бір жолмен басқару керек. Мұның барлығын әдетте жүйелік әкімші немесе әзірлеуші қолмен жасайды. Ал қосымшалар аз болған кезде ешқандай проблема болмайды. Олар көп болғанда, комбайн керек. Мұндай комбайн бар - бұл Service Broker. Ол жалпыға қолжетімді бұлттық кластерге арналған арнайы плагинді пайдалануға және API сияқты Broker арқылы провайдерден ресурстарға тапсырыс беруге мүмкіндік береді. Ол үшін жергілікті Kubernetes құралдарын пайдалануға болады.
Бұл өте оңай. Сіз, мысалы, Azure жүйесіндегі басқарылатын MySQL-ті негізгі деңгеймен сұрауға болады (оны конфигурациялауға болады). Azure API көмегімен дерекқор жасалады және пайдалануға дайындалады. Бұған араласудың қажеті жоқ, бұл үшін плагин жауапты. Мысалы, OSBA (Azure плагині) тіркелгі деректерін қызметке қайтарады және оны Helm қызметіне береді. Сіз WordPress-ті бұлттық MySQL көмегімен пайдалана аласыз, басқарылатын дерекқорлармен мүлдем айналыспайсыз және ішіндегі толық қызметтер туралы алаңдамайсыз.
Helm бір жағынан қызметтерді орналастыруға мүмкіндік беретін, ал екінші жағынан бұлттық провайдерлердің ресурстарын тұтынатын желім ретінде әрекет етеді деп айта аламыз.
Сіз өзіңіздің плагиніңізді жазып, осы оқиғаны жергілікті жерде пайдалана аласыз. Содан кейін сізде корпоративтік бұлт провайдеріне арналған өзіңіздің плагиніңіз болады. Мен бұл әдісті қолданып көруді ұсынамын, әсіресе егер сізде үлкен масштаб болса және мүмкіндік үшін әзірлеуді, сахналауды немесе бүкіл инфрақұрылымды жылдам орналастырғыңыз келсе. Бұл сіздің операцияларыңыз немесе DevOps үшін өмірді жеңілдетеді.
Мен айтып өткен тағы бір олжа helm-gcs плагині, ол Helm диаграммаларын сақтау үшін Google-buckets (нысан қоймасы) пайдалануға мүмкіндік береді.
Оны пайдалануды бастау үшін сізге тек төрт пәрмен қажет:
- плагинді орнату;
- оны бастау;
- gcp-де орналасқан шелекке жолды орнатыңыз;
- диаграммаларды стандартты түрде жариялау.
Әдемілігі, авторизация үшін жергілікті gcp әдісі пайдаланылады. Қызмет тіркелгісін, әзірлеуші тіркелгісін қалағаныңызша пайдалана аласыз. Бұл өте ыңғайлы және жұмыс істеу үшін ештеңе қажет емес. Егер сіз мен сияқты опссыз философияны насихаттасаңыз, бұл әсіресе шағын командалар үшін өте ыңғайлы болады.
Баламалар
Helm - қызметті басқарудың жалғыз шешімі емес. Бұл туралы көптеген сұрақтар туындайды, сондықтан үшінші нұсқа тез пайда болды. Әрине, балама нұсқалар бар.
Бұл арнайы шешімдер болуы мүмкін, мысалы, Ksonnet немесе Metaparticle. Сіз классикалық инфрақұрылымды басқару құралдарын (Ansible, Terraform, Chef және т.б.) мен айтқан мақсаттарда пайдалана аласыз.
Ақырында шешім бар , оның танымалдығы артып келеді.
Operator Framework - Helm нұсқасының ең жақсы нұсқасы.
Бұл CNCF және Kubernetes үшін көбірек, бірақ кіруге кедергі әлдеқайда жоғары, сізге көбірек бағдарламалау керек және манифесттерді азырақ сипаттау керек.
Draft, Scaffold сияқты әртүрлі қосымшалар бар. Олар өмірді айтарлықтай жеңілдетеді, мысалы, әзірлеушілерге сынақ ортасын орналастыру үшін Helm жіберу және іске қосу циклін жеңілдетеді. Мен оларды күш берушілер деп атар едім.
Мұнда барлығының қай жерде орналасқанының көрнекі диаграммасы берілген.
X осінде болып жатқан нәрсені жеке бақылау деңгейі, y осінде Кубернетестің туғандық деңгейі. Helm 2-нұсқасы ортасында бір жерге түседі. 3-нұсқада айтарлықтай емес, бірақ бақылау да, жергілікті деңгейде де жақсартылды. Ksonnet деңгейіндегі шешімдер әлі де Helm 2-ден де төмен. Дегенмен, бұл дүниеде тағы не бар екенін білу үшін оларға назар аударған жөн. Әрине, конфигурация менеджері сіздің бақылауыңызда болады, бірақ ол Кубернетеске мүлдем жатпайды.
Operator Framework толығымен Kubernetes-ке тән және оны әлдеқайда талғампаз және мұқият басқаруға мүмкіндік береді (бірақ кіру деңгейі туралы есте сақтаңыз). Керісінше, бұл Helm көмегімен көптеген қосымшаларды орау үшін жаппай жинаушы емес, мамандандырылған қолданбаға және оны басқаруды құруға қолайлы.
Кеңейткіштер басқаруды сәл жақсартады, жұмыс процесін толықтырады немесе CI/CD құбырларындағы бұрыштарды кеседі.
Хельмнің болашағы
Жақсы жаңалық - Helm 3 келе жатыр. Helm 3.0.0-alpha.2 альфа нұсқасы қазірдің өзінде шығарылды, оны көріңіз. Ол айтарлықтай тұрақты, бірақ функционалдылық әлі де шектеулі.
Сізге Helm 3 не үшін қажет? Ең алдымен, бұл туралы әңгіме Тиллердің жоғалуы, құрамдас бөлігі ретінде. Бұл, сіз түсінгеніңіздей, алға жасалған үлкен қадам, өйткені сәулет қауіпсіздігі тұрғысынан бәрі жеңілдетілген.
Helm 2 жасалған кезде, ол Кубернетес 1.8 немесе одан да ертерек болған кезде, көптеген тұжырымдамалар жетілмеген еді. Мысалы, қазір CRD тұжырымдамасы белсенді түрде жүзеге асырылуда және Хельм де солай етеді CRD пайдаланыңызқұрылымдарды сақтауға арналған. Сервер бөлігіне қызмет етпей, тек клиентті пайдалану мүмкін болады. Тиісінше, құрылымдармен және ресурстармен жұмыс істеу үшін жергілікті Kubernetes пәрмендерін пайдаланыңыз. Бұл алға жасалған үлкен қадам.
Пайда болады жергілікті OCI репозиторийлеріне қолдау көрсету (Ашық контейнерлік бастама). Бұл үлкен бастама және Хельм ең алдымен өз диаграммаларын орналастыруға мүдделі. Мысалы, Docker Hub көптеген OCI стандарттарына қолдау көрсетеді. Мен болжап отырған жоқпын, бірақ классикалық Docker репозиторий провайдерлері сізге Helm диаграммаларын орналастыру мүмкіндігін бере бастайды.
Мен үшін даулы оқиға Луа қолдауы, сценарийлерді жазуға арналған шаблондық қозғалтқыш ретінде. Мен Луаның үлкен жанкүйері емеспін, бірақ бұл мүлдем қосымша функция болар еді. Мен мұны 3 рет тексердім - Луаны пайдалану қажет емес. Сондықтан Луаны пайдаланғысы келетіндер, Go ұнататындар біздің үлкен лагерьге қосылып, бұл үшін go-tmpl пайдаланады.
Ақырында, мен анық жетіспейтін нәрсе болды схеманың пайда болуы және деректер түрін тексеру. Енді int немесе жолға қатысты проблемалар болмайды, нөлді қос тырнақшаға орау қажет емес. JSONS схемасы мәндер үшін анық сипаттауға мүмкіндік береді.
Қатты қайта өңделеді оқиғаға негізделген модель. Ол қазірдің өзінде тұжырымдамалық түрде сипатталған. Helm 3 тармағына қараңыз, сонда сіз қанша оқиғалар мен ілгектер және басқа нәрселер қосылғанын көресіз, бұл айтарлықтай жеңілдетеді және екінші жағынан, орналастыру процестері мен оларға реакцияларды бақылауды қосады.
Helm 3 бізге Helm 2 ұнамағандықтан емес, Кубернетес жетілдірілгендіктен қарапайым, қауіпсіз және қызықты болады. Тиісінше, Helm Kubernetes әзірлемелерін пайдалана алады және оған Kubernetes үшін тамаша менеджерлер жасай алады.
Тағы бір жақсы жаңалық - бұл Сізге Александр Хайоров айтады, Естеріңізге сала кетейік, әзірлеу, сынау және пайдалану процестерін біріктіру бойынша конференция Мәскеуде өтеді 30 қыркүйек пен 1 қазан. Сіз мұны 20 тамызға дейін жасай аласыз және шешіммен тәжірибеңіз туралы айтып беріңіз DevOps әдісінің міндеттері.
Конференцияның бақылау нүктелері мен жаңалықтарын мына мекенжайда бақылаңыз и .
Ақпарат көзі: www.habr.com