Thank you for reading this post, don't forget to subscribe! 

На кар­тин­ке выше пред­став­ле­но целе­вое реше­ние. Внут­ри кла­сте­ра будет раз­вер­нут фрон­тенд ( kanban-ui ) и backend ( kanban-app ). Для сохра­не­ния дан­ных будет исполь­зо­вать­ся база дан­ных postgres

Кро­ме того, я доба­вил при­ло­же­ние адми­ни­стра­то­ра , кото­рое явля­ет­ся кли­ен­том с гра­фи­че­ским интер­фей­сом для вхо­да в базу данных.

На при­ве­ден­ном выше рисун­ке пока­за­ны не толь­ко при­ло­же­ния, кото­рые будут раз­вер­ну­ты в кла­сте­ре Kubernetes , но и объ­ек­ты, необ­хо­ди­мые для их запус­ка, такие как Deployments или Services . При клас­си­че­ском под­хо­де kubectl мы были вынуж­де­ны созда­вать фай­лы опре­де­ле­ний для каж­до­го из них. Даже если в боль­шин­стве слу­ча­ев, напри­мер, в слу­чае ClusterIP , эти объ­ек­ты не силь­но раз­ли­ча­ют­ся меж­ду приложениями.

Опре­де­лен­но, этот под­ход не мас­шта­би­ру­ет­ся в мире мик­ро­сер­ви­сов, где обыч­но необ­хо­ди­мо раз­вер­нуть десят­ки или даже сот­ни при­ло­же­ний. И если бы для каж­до­го из них нам потре­бо­ва­лось бы создать пару фай­лов YAML, это быст­ро пре­вра­ти­лось бы в кош­мар. Но эту про­бле­му мож­но решить с помо­щью движ­ка шаб­ло­нов Kubernetes - Helm . Мы можем опре­де­лить общую диа­грам­му (шаб­лон) Helm и повтор­но исполь­зо­вать ее в несколь­ких при­ло­же­ни­ях, толь­ко доба­вив опре­де­лен­ные зна­че­ния в шаблон.

Про­бле­ма решена?

В неко­то­рой сте­пе­ни да, но в исполь­зо­ва­нии Helm есть один недо­ста­ток . Что­бы уста­но­вить или обно­вить любую диа­грам­му в кла­сте­ре, вам необ­хо­ди­мо выпол­нить опре­де­лен­ную импе­ра­тив­ную коман­ду. Дру­ги­ми сло­ва­ми, что­бы изме­нить состо­я­ние кла­сте­ра, вам нуж­но запу­стить коман­ду, спе­ци­фич­ную для дан­но­го развертывания.

В мире Java мы исполь­зу­ем Maven, а для JavaScript - npm . Оба этих инстру­мен­та поз­во­ля­ют запус­кать одну и ту же коман­ду в несколь­ких про­ек­тах для выпол­не­ния одно­го и того же дей­ствия, напри­мер, запус­ка тестов - mvn test. Helm в насто­я­щее вре­мя не под­дер­жи­ва­ет эту функ­цию, мы не можем уста­но­вить, обно­вить или отка­тить все при­ло­же­ния из все­го кла­сте­ра с помо­щью одной команды.

Но есть файл helmfile , кото­рый может помочь .

Helmfile поз­во­ля­ет объ­явить опре­де­ле­ние все­го кла­сте­ра Kubernetes в одном фай­ле YAML, он объ­еди­ня­ет несколь­ко выпус­ков Helm (уста­нов­ка диа­грамм Helm ) и поз­во­ля­ет настра­и­вать спе­ци­фи­ка­цию каж­до­го выпус­ка в зави­си­мо­сти от типа сре­ды (раз­ра­бот­ка, тести­ро­ва­ние, про­из­вод­ство) на кото­ром вы, воз­мож­но, захо­ти­те раз­вер­нуть свои приложения.

Луч­ше все­го пока­зать, как это рабо­та­ет, на при­ме­ре. Перед этим нам нуж­но настро­ить рабо­чую сре­ду. Если вы хоти­те сле­до­вать моим шагам, вам необ­хо­ди­мо уста­но­вить и настроить:

• Докер,
• локаль­но уста­нов­лен­ный кла­стер Kubernetes - minikube ,
• Инстру­мент команд­ной стро­ки Kubernetes - kubectl,
• Шлем (v3) ,
• helmfile .

• Ubuntu
• Windows
• MacOS

172.17.0.2 adminer.k8s.com
172.17.0.2 kanban.k8s.com

$ minikube ip

172.17.0.2


Все пап­ки - app, ingress, postgres- поме­стить в новом назы­ва­ет­ся chartsи все YAML фай­лов поме­стить в новой пап­ке под назва­ни­ем values. Затем добавь­те новый helmfile.yamlфайл в кор­не­вой ката­лог, что­бы полу­чив­ша­я­ся струк­ту­ра выгля­де­ла сле­ду­ю­щим образом:

что озна­ча­ет каж­дая из этих папок:

• ./charts- вот все три диа­грам­мы Helms, кото­рые явля­ют­ся шаб­ло­на­ми для каж­до­го выпус­ка - app(для адми­ни­стра­то­ра , kanban -ui , kanban-app ) postgresи ingress,
• helmfile.yaml- здесь будет кон­фи­гу­ра­ция для фай­ла управ­ле­ния , в насто­я­щее вре­мя пустого,
• ./values - пап­ка со зна­че­ни­я­ми, спе­ци­фич­ны­ми для каж­до­го при­ло­же­ния, кото­рое будет развернуто.

Если мы исполь­зу­ем helmfile, послед­ний шаг не пона­до­бит­ся, пото­му что он опре­де­лит и загру­зит все необ­хо­ди­мые зави­си­мо­сти внут­ри каж­дой диа­грам­мы. Итак, мы мог­ли бы оста­вить ingressдиа­грам­му такой, какая она есть, но на этот раз я хотел бы исполь­зо­вать дру­гой под­ход. Я хотел бы рас­смат­ри­вать nginx-ingress chart как отдель­ный выпуск Helm , поми­мо кон­фи­гу­ра­ции Ingress Controller для маршрутизации.

Поэто­му уда­ли­те из ./charts/ingress/Chart.yamlфай­ла сле­ду­ю­щие строки :

После этих изме­не­ний диа­грам­ма ingress Helm отве­ча­ет толь­ко за опре­де­ле­ние Ingress Controller. Тре­бу­ет­ся обслу­жи­ва­ние бэкен­да Ingress будет вве­де­но с выпус­ком Helm.

Теперь, нако­нец, мы можем перей­ти к аран­жи­ров­ке фай­ла helmfile.yaml.

Сна­ча­ла нам нуж­но ука­зать, из каких репо­зи­то­ри­ев Helm мы хотим загру­жать диа­грам­мы. Посколь­ку мы будем загру­жать толь­ко один - ста­биль­ный / nginx-ingress - гра­фик из одно­го репо, мы поме­сти­ли одну запись:

• name - это назва­ние рели­за, мы можем назы­вать как угодно,
• chart- сооб­ща­ет helmfile, где нахо­дит­ся базо­вая кар­та Helm ,
• values- посколь­ку мы исполь­зу­ем шаб­лон диа­грам­мы Helm , мы хоте­ли бы доба­вить в него неко­то­рые зна­че­ния, поэто­му вот спи­сок фай­лов YAML, кото­рые их содержат.

 

В versionполе мы ука­зы­ва­ем, какую вер­сию диа­грам­мы использовать.

И, нако­нец, опре­де­ле­ние рели­за Ingress Controller Helm :

общий вид следующий:

А теперь самое инте­рес­ное, все­го с дву­мя коман­да­ми мы можем раз­вер­нуть все приложения.

Во-пер­вых, нам нуж­но доба­вить репо­зи­то­рий в наш экзем­пляр Helm (вам нуж­но будет сде­лать это толь­ко один раз):