Всем добрый день. Подскажите плз такой момент, вчера смотрел видео

по сравнению werf от helm которое не так давно Илья из Фланта объяснял, я не совсем понимаю такой момент когда при помощи werf мы собираем и пушим и запускаем в кубере деплоймент, переменные которые например объявлены в .env откуда из берет Докер при запуске, эти переменные в чарте шаблонов нужно объявлять или werf их то же увидит и передаст при запуске?

Ты верфу можешь подложить большое количество файлов WERF_VALUES_SOLUTION: solutions/${IXORA_CICD_SOLUTION}/${IXORA_CICD_SOLUTION}.yml WERF_VALUES_STEND: solutions/${IXORA_CICD_SOLUTION}/stend-${IXORA_CICD_STEND_NAME}.yml Он из них сделает большой валюй, который использует потом для helm

да этот вариант для разных стендов подойдет - это я понимаю, немного в другом вопрос увидит ли werf переменные которые в .env откуда их просто при запуске через docker если обычный мы запускаем или так же надо в deployment.yaml который положим в чарт класть?

Эммм... ты разные сущности сравниваешь. Есть общий блок переменных - некий глобальный values.yaml, который ты набиваешь своими переменными, которые тебе нужны для двух целей. 1. Развернуться - сформировать деплоймент, сервис и т.д. 2. Те переменные которые нужны приложению, их надо смаппить в helm templates Типа того spec: replicas: {{ $stendMs.replicaCount | default $defaultValues.microservises.replicaCount }} selector: matchLabels: microservice: {{ $ms.name }} solution: {{ $solution.name }} template: metadata: labels: microservice: {{ $ms.name }} solution: {{ $solution.name }} spec: containers: - name: {{ $ms.name }} image: {{ index $root.Values.werf.image $ms.name }} ports: - containerPort: {{ $stendMs.containerPort | default defaultValues.microservises.containerPort}} env: {{- if $stend.env }} {{- range $env := $stend.env}} - name: {{ $env.name }} value: {{ $env.value | quote }} {{- end }} {{- end }} {{- if $ms.env }} {{- range $env := $ms.env}} - name: {{ $env.name }} value: {{ $env.value | quote }} {{- end }} {{- end }} {{- if $stendMs.affinity }} affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: kubernetes.io/hostname operator: {{ $stendMs.affinity.operator | quote }} values: - {{ $stendMs.affinity.host | quote }} {{- end }}

да я понимаю, просто повторюсь было бы удобно на мой пока взгляд. Спасибо огромное, Константин.

Это совсем разные сущности - представь два компьютера - один управляет, другой управляется. Представь, что бы было, если бы переменные с одного на другой автоматом переносились бы... ерунда получилась бы.

я понимаю что разные сущности, но сравнение не корректное на мой взгляд, смотрите. .env делаем сборку и запуск обычным докером (например разраб у себя на ПК) у нас есть внутри переменные которые мы задали в .env, werf инструмент который смотрит как чарты helm и так же является элементом ci/cd который сможет запустить используя helm chart наш тестовый деплоймент, но ведь он уже делает как я понимаю сборку и запуск в k8s того или иного элемента в кубер и чтобы не объявлять переменные в двух местах как в чарте так и в .env на мой взгляд было бы удорбно если бы он и туда смотрел, так как этот файл все равно в репе чаще всего лежит, но повторюсь это мой взгляд я не особо в этом разбираюсь у каждого своя архитектура. Как по мне часто разрабы забывают указать что есть новая переменная давайте ее включим обязательно в манифесты кубера, а так есть эта переменная в .env werf ее то же увидел и взял, через f12 если будут ошибки, увидим, сделали обычный grep -R увидели что у нас такое значение там то, сделали переназначение на другое если требуется. В любом случае спс, я поняль что не использует, буду дальше ознакомливаться.

Ты воспринимаешь кубернетес как элемент процесса мне кажется, а ты рассмотри под, как отдельный сервер. А десяток подов - как десяток разных серверов. Уверен ли ты, что разумно не иметь механизма управления переменными согласно - какому серверу они нужны... а просто не думая, единым полем выливать все явки и пароли на каждый сервер всегда. Не думаю. Ту просто механизм управления - нужны поду переменные именно такие, ну так и передай. К тому же я привел тебе выше пример, когда циклом в под забубенивается все что есть в определенном разделе, ну вот тебе решение если нужно так.

Вы про какой-то файл .env? Думали добавить их поддержку, но пока не добрались. Сейчас, как и в Helm, чтобы передать в шаблоны что-то из окружения, надо делать это через --set'ы, например: werf converge --set "mychart.myval=${MYVAL}"

Спасибо Илья как минимум за видео ликбез и продукт. Буду ждать и читать обновления.