Менин атым Дмитрий Сугробов, мен Лерой Мерлинде иштеп чыгуучумун. Бул макалада мен сизге Helm эмне үчүн керек экенин, ал Kubernetes менен иштөөнү кантип жөнөкөйлөтөт, үчүнчү версияда эмнелер өзгөргөнүн жана аны өндүрүштөгү тиркемелерди токтоосуз жаңыртуу үчүн кантип колдонсо болорун айтып берем.
Бул конференцияда сүйлөгөн сөзүнүн кыскача баяндамасы by — эгер окугуңуз келбесе, видеону көрүңүз.
Эмне үчүн биз өндүрүштө Kubernetes колдонобуз
Лерой Мерлин Россияда жана Европада DIY чекене рыногунда лидер болуп саналат. Биздин компаниянын жүздөн ашык иштеп чыгуучулары, 33 000 ички кызматкерлери жана гипермаркеттерге жана веб-сайтка келген көптөгөн адамдар бар. Алардын баарын бактылуу кылуу үчүн биз тармактык стандарттык ыкмаларды колдонууну чечтик. Микросервис архитектурасын колдонуу менен жаңы тиркемелерди иштеп чыгуу; айлана-чөйрөнү изоляциялоо жана туура жеткирүү үчүн контейнерлерди колдонуу; жана оркестр үчүн Kubernetes колдонуңуз. Оркестрлерди колдонуу баасы тездик менен арзандап баратат: рынокто технологияны жакшы билген инженерлердин саны өсүүдө жана провайдерлер Kubernetes кызматын сунуштап жатышат.
Кубернетес жасаган нерселердин бардыгын, албетте, башка жолдор менен жасоого болот, мисалы, кээ бир Дженкиндерди жабуу жана скрипттер менен докер түзүү, бирок даяр жана ишенимдүү чечим бар болсо, эмне үчүн жашоону татаалдаштырат? Ошондуктан биз Кубернетеске келдик жана аны бир жылдан бери өндүрүштө колдонуп жатабыз. Учурда бизде жыйырма төрт Кубернетес кластерлери бар, алардын эң эскиси бир жылдан ашты, эки жүзгө жакын бактары бар.
Kubernetesтеги чоң YAML файлдарынын каргышы
Kubernetes'те микросервисти ишке киргизүү үчүн, биз кеминде беш YAML файлын түзөбүз: Жайгаштыруу, Кызмат, Кирүү, Конфигкарта, Сырлар үчүн жана аларды кластерге жөнөтөбүз. Кийинки тиркеме үчүн биз ошол эле жамбы пакетин жазабыз, үчүнчүсү менен башкасын жазабыз жана башкалар. Документтердин санын чөйрөлөрдүн санына көбөйткөн болсок, анда биз жүздөгөн файлдарды алабыз жана бул азырынча динамикалык чөйрөлөрдү эске албайт.
Адам Риз, Helmдин негизги тейлөөчүсү, " түшүнүгүн киргизген.", мындай көрүнөт:
- Copy YAML - YAML файлын көчүрүү.
- YAML чаптоо - аны чаптоо.
- Fix Indents - чегинүүлөрдү оңдоо.
- Кайталоо - кайра кайталоо.
Опция иштейт, бирок YAML файлдарын көп жолу көчүрүп алышыңыз керек. Бул циклди өзгөртүү үчүн, Helm ойлоп табылган.
Helm деген эмне
Биринчиден, Helm - пакет менеджери, бул сизге керектүү программаларды табууга жана орнотууга жардам берет. Орнотуу үчүн, мисалы, MongoDB, расмий веб-сайтка барып, экилик файлдарды жүктөп алуунун кереги жок, жөн гана буйрукту иштетиңиз helm install stable/mongodb.
Экинчиден, Helm - шаблон кыймылдаткычы, файлдарды параметрлештирүүгө жардам берет. Келгиле, Kubernetesтеги YAML файлдары менен болгон кырдаалга кайрылып көрөлү. Ошол эле YAML файлын жазуу оңой, ага бир нече толтургучтарды кошуу, анын ичинде Helm маанилерди алмаштырат. Башкача айтканда, чоң складдардын ордуна, керектүү баалуулуктар керектүү учурда алмаштырыла турган шаблондор топтому болот.
Үчүнчүдөн, Helm - жайылтуу мастери. Анын жардамы менен сиз тиркемелерди орнотуп, артка кайтарып жана жаңырта аласыз. Келгиле, муну кантип жасоо керектигин карап көрөлү.
Өз тиркемелериңизди жайылтуу үчүн Helm кантип колдонсо болот
Келгиле, Helm кардарын компьютериңизге расмий түрдө ээрчип орнотуп алалы . Андан кийин, YAML файлдарынын топтомун түзөбүз. Конкреттүү маанилерди көрсөтүүнүн ордуна, биз Helm келечекте маалымат менен толтуруучу толтургучтарды калтырабыз. Мындай файлдардын жыйындысы Helm диаграммасы деп аталат. Аны Helm консолунун кардарына үч жол менен жөнөтсө болот:
- шаблондору бар папканы көрсөтүү;
- архивди .tarга топтоп, аны көздөй көрсөтүңүз;
- шаблонду алыскы репозиторийге коюп, Helm кардарындагы репозиторийге шилтеме кошуңуз.
Ошондой эле баалуулуктары бар файл керек - values.yaml. Ал жерден алынган маалыматтар шаблонго киргизилет. Аны да жараталы.
Helmдин экинчи версиясында кошумча сервердик тиркеме бар - Tiller. Ал Kubernetesтин сыртында илинип турат жана Helm кардарынын суроо-талаптарын күтөт жана чакырганда, шаблонго керектүү маанилерди алмаштырып, аны Kubernetesке жөнөтөт.
Helm 3 жөнөкөйраак: шаблондорду серверде иштетүүнүн ордуна, маалымат азыр толугу менен Helm кардар тарабында иштетилет жана түздөн-түз Kubernetes API'ге жөнөтүлөт. Бул жөнөкөйлөтүү кластердин коопсуздугун жакшыртат жана жайылтуу схемасын жеңилдетет.
Мунун баары кантип иштейт
Буйрукту иштетиңиз helm install. Колдонмонун релизинин атын көрсөтүп, баалуулуктарга жол берели.yaml. Аягында биз диаграмма жайгашкан репозиторийди жана диаграмманын атын көрсөтөбүз. Мисалда булар тиешелүүлүгүнө жараша "лмру" жана "бестчарт".
helm install --name bestapp --values values.yaml lmru/bestchart
Буйрук бир гана жолу аткарылышы мүмкүн, анын ордуна кайра аткарылганда install колдонуу керек upgrade. Жөнөкөйлүк үчүн, эки буйруктун ордуна, сиз буйрукту иштете аласыз upgrade кошумча ачкыч менен --install. Биринчи жолу аткарылганда, Helm релизди орнотуу үчүн буйрук жөнөтөт жана келечекте аны жаңылайт.
helm upgrade --install bestapp --values values.yaml lmru/bestchart
Helm менен тиркеменин жаңы версияларын жайылтуудагы тузактар
Окуянын ушул жеринде мен аудитория менен «Ким миллионер болгусу келет» оюнун ойноп жатам жана биз Helmди колдонмонун версиясын жаңыртуу үчүн кантип алуу керектигин ойлоп жатабыз. .
Мен Helm кантип иштээрин үйрөнүп жатканымда, иштеп жаткан тиркемелердин версияларын жаңыртууга аракет кылып жатканда кызыктай жүрүм-туруму мени таң калтырды. Мен колдонмо кодун жаңырттым, Docker реестрине жаңы сүрөт жүктөдүм, жайылтуу буйругун жөнөттүм - жана эч нерсе болгон жок. Төмөндө тиркемелерди жаңыртуу үчүн толук эмес ийгиликтүү жолдор бар. Алардын ар бирин тереңирээк изилдеп, сиз аспаптын ички түзүлүшүн жана бул ачык эмес жүрүм-турумдун себептерин түшүнө баштайсыз.
Метод 1. Акыркы ишке киргизилгенден бери маалыматты өзгөртпөңүз
Анда айтылгандай Хелм, "Кубернетес диаграммалары чоң жана татаал болушу мүмкүн, ошондуктан Хелм эч нерсеге ашыкча тийбөөгө аракет кылат." Ошондуктан, эгер сиз докер реестриндеги колдонмонун сүрөтүнүн акыркы версиясын жаңыртып, буйрукту иштетсеңиз helm upgrade, анда эч нерсе болбойт. Helm эч нерсе өзгөргөн жок деп ойлойт жана колдонмону жаңыртуу үчүн Kubernetesке буйрук жөнөтүүнүн кереги жок.
Бул жерде жана ылдыйда акыркы теги мисал катары гана көрсөтүлгөн. Бул тегди көрсөткөнүңүздө, Kubernetes сүрөттү docker реестринен imagePullPolicy параметрине карабастан жүктөйт. Акыркы өндүрүштү колдонуу жагымсыз жана терс таасирлерди жаратат.
Метод 2. Сүрөттөгү LABELди жаңыртыңыз
Ошол эле жазылгандай , "Helm тиркемени акыркы чыгарылыштан бери өзгөргөн болсо гана жаңылайт." Мунун логикалык варианты докердин сүрөтүндөгү LABELди жаңыртып жаткандай сезилет. Бирок, Helm колдонмонун сүрөттөрүн карабайт жана аларга эч кандай өзгөртүүлөр жөнүндө эч кандай түшүнүгү жок. Демек, сүрөттөгү энбелгилерди жаңыртып жатканда, Helm алар жөнүндө билбейт жана колдонмону жаңыртуу буйругу Kubernetesке жөнөтүлбөйт.
Метод 3: Ачкычты колдонуңуз --force
Келгиле, колдонмолорго кайрылып, керектүү ачкычты издейли. Ачкыч эң мааниге ээ --force. Аты белгилүү болгонуна карабастан, жүрүм-турум күтүлгөндөн башкача. Тиркемени жаңыртууга мажбурлоонун ордуна, анын чыныгы максаты - АТКАРЫЛГАН статустагы чыгарууну калыбына келтирүү. Бул ачкычты колдонбосоңуз, буйруктарды ырааттуу түрдө аткарышыңыз керек helm delete && helm install --replace. Анын ордуна ачкычты колдонуу сунушталат --force, бул буйруктардын ырааттуу аткарылышын автоматташтырат. Бул тууралуу көбүрөөк маалымат . Helmге колдонмонун версиясын жаңыртуу үчүн айтуу үчүн, тилекке каршы, бул ачкыч иштебейт.
Метод 4. Энбелгилерди түздөн-түз Kubernetesте өзгөртүңүз
Буйрукту колдонуу менен энбелги түздөн-түз кластерде жаңыртылат kubectl edit - жаман идея. Бул аракет иштеп жаткан колдонмо менен алгач жайылтууга жөнөтүлгөн маалыматтын дал келбестигине алып келет. Бул учурда жайгаштыруу учурунда Helm жүрүм-туруму анын версиясынан айырмаланат: Helm 2 эч нерсе кылбайт, ал эми Helm 3 колдонмонун жаңы версиясын орнотот. Эмне үчүн экенин түшүнүү үчүн, Helm кантип иштээрин түшүнүү керек.
Helm кантип иштейт?
Колдонмонун акыркы чыгарылгандан бери өзгөргөнүн аныктоо үчүн, Helm колдоно алат:
- Kubernetesте иштеп жаткан колдонмо;
- жаңы баалуулуктар.yaml жана учурдагы диаграмма;
- Helm ички релиз маалымат.
Кызыгуу үчүн: Helm релиздер жөнүндө ички маалыматты кайда сактайт?Буйрукту аткаруу менен helm history, биз Helm аркылуу орнотулган версиялар жөнүндө бардык маалыматты алабыз.
Ошондой эле жөнөтүлгөн шаблондор жана баалуулуктар жөнүндө толук маалымат бар. Биз аны сурай алабыз:
Helmдин экинчи версиясында бул маалымат Tiller иштеп жаткан ат мейкиндигинде (демейки боюнча kube-система), ConfigMapда "OWNER=TILLER" энбелгиси менен белгиленген:
Helm үчүнчү версиясы пайда болгондо, маалымат сырларга жана тиркеме иштеп жаткан ошол эле аттар мейкиндигине өттү. Мунун аркасында бир эле релиз аталышы менен ар кандай аттар мейкиндигинде бир эле учурда бир нече тиркемелерди иштетүү мүмкүн болду. Экинчи версияда аттар мейкиндиктери обочолонуп, бирок бири-бирине таасир этиши мүмкүн болгондо катуу баш оору болгон.
Экинчи Helm, жаңыртуу керекпи же жокпу, түшүнүүгө аракет кылып жатканда, эки гана маалымат булагын колдонот: азыр ага эмне берилип жатат жана ConfigMap ичинде жайгашкан релиздер жөнүндө ички маалымат.
Үчүнчү Helm үч тараптуу бириктирүү стратегиясын колдонот: бул маалыматка кошумча, ал азыр Kubernetesте иштеп жаткан тиркемени да эске алат.
Ушул себептен улам, Helmдин эски версиясы эч нерсе кылбайт, анткени ал кластердеги тиркеме маалыматын эске албайт, бирок Helm 3 өзгөртүүлөрдү кабыл алып, жаңы тиркемени жайылтууга жөнөтөт.
Метод 5. --recreate-pods алмаштыргычты колдонуңуз
Ачкыч менен --recreate-pods ачкыч менен алгач пландаган нерсеңизге жете аласыз --force. Контейнерлер кайра иштетилет жана imagePullPolicy: Ар дайым акыркы теги боюнча саясат (бул тууралуу кененирээк жогорудагы шилтемеде), Kubernetes сүрөттүн жаңы версиясын жүктөп алып, ишке киргизет. Бул эң жакшы жол менен жасалбайт: жайылтуунун StrategyType түрүн эске албастан, ал күтүлбөгөн жерден бардык эски тиркемелерди өчүрүп, жаңыларын ишке киргизип баштайт. Кайра иштетүү учурунда система иштебейт, колдонуучулар жабыркайт.
Кубернетестин өзүндө да ушундай көйгөй көптөн бери болгон. Эми ачылганына 4 жыл болду , көйгөй чечилди жана Kubernetesтин 1.15 версиясынан баштап, поддондорду кайра иштетүү мүмкүнчүлүгү пайда болот.
Helm жөн гана бардык колдонмолорду өчүрүп, жакын жердеги жаңы контейнерлерди ишке киргизет. Колдонмонун иштебей калышына жол бербөө үчүн, сиз муну өндүрүштө кыла албайсыз. Бул өнүгүү муктаждыктары үчүн гана керек жана этап чөйрөсүндө гана аткарылышы мүмкүн.
Helm аркылуу колдонмонун версиясын кантип жаңыртса болот?
Биз Helmге жөнөтүлгөн баалуулуктарды өзгөртөбүз. Эреже катары, бул сүрөт тегинин ордуна алмаштырылган баалуулуктар. Көбүнчө жемишсиз чөйрөлөр үчүн колдонулган акыркы учурда, өзгөрүлүүчү маалымат аннотация болуп саналат, ал Kubernetesтин өзү үчүн пайдасыз, ал эми Helm үчүн бул тиркемени жаңыртуу зарылчылыгы үчүн сигнал болуп калат. Аннотациянын маанисин толтуруу параметрлери:
- Random value стандарттык функцияны колдонуу -
{{ randAlphaNum 6 }}.
Эскертүү бар: мындай өзгөрмөлүү диаграмманы колдонуу менен ар бир жайылтуудан кийин аннотациянын мааниси уникалдуу болуп калат жана Helm өзгөртүүлөр бар деп эсептейт. Көрсө, биз анын версиясын өзгөртпөсөк дагы, биз ар дайым тиркемени кайра иштетебиз. Бул өтө маанилүү эмес, анткени токтоп калуу болбойт, бирок дагы эле жагымсыз. - Учурдагы чаптоо датасы жана убактысы -
{{ .Release.Date }}.
Вариант туруктуу уникалдуу өзгөрмөлүү кокустук мааниге окшош. - Туурараак жол - бул колдонуу текшерүү суммалары. Бул сүрөттүн SHAсы же гиттеги акыркы милдеттенменин SHAсы -
{{ .Values.sha }}.
Аларды санап, чалып жаткан тараптагы Helm кардарына жөнөтүү керек, мисалы, Дженкинсте. Эгерде өтүнмө өзгөргөн болсо, анда текшерүү суммасы өзгөрөт. Ошондуктан, Helm керек болгондо гана тиркемени жаңылайт.
Келгиле, аракетибизди жыйынтыктайлы
- Helm эң аз инвазивдик жол менен өзгөртүүлөрдү киргизет, ошондуктан Докер реестриндеги колдонмонун сүрөтүнүн деңгээлиндеги кандайдыр бир өзгөртүү жаңыланууга алып келбейт: буйрук аткарылгандан кийин эч нерсе болбойт.
- ачкыч
--forceкөйгөйлүү релиздерди калыбына келтирүү үчүн колдонулат жана аргасыз жаңыртууларга байланыштуу эмес. - ачкыч
--recreate-podsтиркемелерди күч менен жаңылайт, бирок аны вандалдык түрдө жасайт: ал капыстан бардык контейнерлерди өчүрөт. Колдонуучулар мындан жапа чегишет; сиз муну өндүрүштө кылбаңыз. - Буйрук аркылуу түздөн-түз Kubernetes кластерине өзгөртүүлөрдү киргизиңиз
kubectl editкылбаңыз: биз ырааттуулукту бузуп алабыз жана жүрүм-турум Helm версиясына жараша айырмаланат. - Helm жаңы версиясынын чыгышы менен көптөгөн нюанстар пайда болду. Helm репозиторийиндеги маселелер түшүнүктүү тилде сүрөттөлөт, алар сизге майда-чүйдөлөрдү түшүнүүгө жардам берет.
- Диаграммага түзөтүүчү аннотацияны кошуу аны ийкемдүү кылат. Бул сизге тиркемени туура, токтоосуз чыгарууга мүмкүндүк берет.
Жашоонун бардык тармагында иштеген “дүйнө тынчтыгы” деген ой: колдонуудан кийин эмес, колдонуудан мурун нускаманы окуп чыгыңыз. Толук маалымат менен гана ишенимдүү системаларды куруу жана колдонуучуларды бактылуу кылуу мүмкүн болот.
Башка тиешелүү шилтемелер:
Бул отчет биринчи жолу берилген Mail.ru Cloud Solutions тарабынан. Кара башка спектаклдер жана Telegramдагы иш-чара кулактандырууларына жазылуу .
Source: www.habr.com