OK
и это оооч странно
Size: a a a
2020 January 05
OK
потому что получается переменной KUBECONFIG нету
A
но в этом случае - деплой отрабатывает в нужном кластере
В том в котором запущен раннер?
OK
В том в котором запущен раннер?
да
OK
короче по другому вопрос задам, можно ли чтоб както environment name не влиял на варсы KUBE
OK
GG
tl;dr
GG
сорри - задача какая?
OK
в итоге, переменный KUBE_* вообще не юзаются, если не юзаю environment:name - оно просто в нужный кластер деплоит и все
OK
сорри - задача какая?
когда использую в дефинишене enviironment:name - экспозятся переменные типа KUBE_NAMESPACE, KUBE_SERVICE_ACCOUNT кривые. в формате типа In the format <project_name>-<project_id>-<environment>
а таких не НС, не СА не существует в кубе
а таких не НС, не СА не существует в кубе
OK
юзаю кубовый раннер
GG
Всем салют ! парни, как рашить траблу с кубовым эксзекутором
в общем, если я запускаю джобу БЕЗ environment:name переменной - то у меня все нормально отрабтаывает на раннере и корректно деплоится в кластер. при этом никаких переменных типа KUBE_* я не вижу в энве
если же я использую эту переменную, то у меня сразу экспозятся варсы типа KUBE_NAMESPACE в виде ( In the format <project_name>-<project_id>-<environment> ) и автоматом ломает мой билд потому что $KUBECONFIG передается неверный а именно сервис аккаунт, например
то есть проставляется некорректный (несуществующий) неймспейс - и идет ругань типа
User "system:serviceaccount:backend-96-develop:backend-96-develop-service-account" cannot get resource "deployments" in API group "extensions" in the namespace "somens"
в общем, если я запускаю джобу БЕЗ environment:name переменной - то у меня все нормально отрабтаывает на раннере и корректно деплоится в кластер. при этом никаких переменных типа KUBE_* я не вижу в энве
если же я использую эту переменную, то у меня сразу экспозятся варсы типа KUBE_NAMESPACE в виде ( In the format <project_name>-<project_id>-<environment> ) и автоматом ломает мой билд потому что $KUBECONFIG передается неверный а именно сервис аккаунт, например
$ kubectl config view
apiVersion: v1
clusters:
- cluster:
certificate-authority-data: DATA+OMITTED
server: https://example.org:6443
name: gitlab-deploy
contexts:
- context:
cluster: gitlab-deploy
namespace: backend-96-develop
user: gitlab-deploy
name: gitlab-deploy
current-context: gitlab-deploy
kind: Config
preferences: {}
users:
- name: gitlab-deploy
user:
token: [MASKED]
то есть проставляется некорректный (несуществующий) неймспейс - и идет ругань типа
User "system:serviceaccount:backend-96-develop:backend-96-develop-service-account" cannot get resource "deployments" in API group "extensions" in the namespace "somens"
как будто тебе рбак надо поправить
GG
накинуть на сервисную четку возможность создавать неймспейсы
GG
скорее всего эта шляпа не заточена на юзание в непривилегированном виде
OK
сервисная учетка тоже не существует, с которой он вообще пытается авторизоваться
он экспозит опять по какому то своему принципу и перезаписывает
вот конфиг получившийся куба
но у меня конечно же нет такой СА, и тем более НС
он экспозит опять по какому то своему принципу и перезаписывает
KUBE_SERVICE_ACCOUNT=backend-96-develop-service-account
вот конфиг получившийся куба
$ kubectl config view
apiVersion: v1
clusters:
- cluster:
certificate-authority-data: DATA+OMITTED
server: https://example.org:6443
name: gitlab-deploy
contexts:
- context:
cluster: gitlab-deploy
namespace: backend-96-develop
user: gitlab-deploy
name: gitlab-deploy
current-context: gitlab-deploy
kind: Config
preferences: {}
users:
- name: gitlab-deploy
user:
token: [MASKED]
но у меня конечно же нет такой СА, и тем более НС
OK
<project_name>-<project_id>-<environment>
в моем случае это backend-96-develop
в моем случае это backend-96-develop
OK
и в общем, если environment задан - начинают юзаться кастомные значения
без него - деплой ровный
без него - деплой ровный
b
и в общем, если environment задан - начинают юзаться кастомные значения
без него - деплой ровный
без него - деплой ровный
Встречный вопрос: а в чем необходимость задавать энвайрномент?)