
Комментарии 6
Разрешите вопрос - а почему не мигрировали с env в сторону vault/doppler/etc? (может я был не внимателен и не заметил ответа в теле поста...)
Хороший вопрос. Если коротко — glenv не конкурент Vault/Doppler, он работает на другом уровне.
GitLab CI/CD переменные — это уже встроенный менеджер секретов внутри GitLab: masked, protected, environment scope, audit log. Если вы и так на
GitLab — зачем поднимать и оплачивать дополнительную инфраструктуру?
glenv решает ровно одну вещь: неудобный интерфейс управления этими переменными. Перенести 80 переменных из .env файла в GitLab через веб-UI —
мучение. glenv делает это одной командой с diff-preview.
На мой взгляд Vault/Doppler имеют смысл когда:
Нужен мультиплатформенный доступ к секретам (не только GitLab, но и K8s, AWS, etc.)
Нужна динамическая ротация, fine-grained ACL, аудит на уровне отдельного секрета
Команда работает с несколькими инструментами за пределами GitLab-экосистемы
Если же стек — это GitLab + GitLab CI, то встроенные переменные отлично справляются, а glenv просто убирает боль их обслуживания.
Та я к тому, что так и нак нужен секрет для доступа к api - в вашем случае от gitlab, с случае с vault/doppler - он него. Вот только последние как раз спроектированы для работы с секретами, а gitlab env он даже называется именно env, и не очень хорош для работы с чувствительными данными, как будто в вашем случае он несколько не по прямому назначению используется что-ли (хотя и сам так и делал, и делаю в мелких проектах, но постоянно грызет совесть за это).
Так же не покидает ощущение что ваш комментарий сгенерирован ии - длинные дефисы, нет разговорных оборотов, слишком "вылизанный" текст. Я прав, или мне это показалось?
Да, GitLab Variables это не Vault. Но masked + protected + audit log для большинства задач хватает. Vault нужен когда динамическая ротация, lease, интеграция с k8s и тд. Для "закинуть переменные и иногда обновлять" - оверкилл.
По поводу ИИ - да, помогал структурировать, каюсь. Но суть от этого не меняется) Но если для вас это принципиально, буду писать с ошибками и сумбурно )
Эм, простите, но зачем 80 переменных в env-файле тащить в гитлаб полностью? У меня как правило (там, где деплой на один сервер) всего две переменных - токен docker registry и весь енв самого проекта в одной переменной типа file. CI читает эту переменную, source'ит из неё всё в окружение, работает прекрасно и довольно удобно.
Да все просто, я параноик и не люблю секреты держать в файлах. Сначала юзал SOPS - задолбался с ключами и доступами, особенно когда секретов стало больше десятка.
А тут GitLab из коробки дает protected/masked на каждую переменную отдельно. Плюс практичные штуки: надо глянуть какой сейчас DATABASE_URL на проде - открыл UI и видишь. CI упал - поправил один ключ за 5 секунд, не редактируя весь блоб. glenv просто мост между локальным .env и GitLab, без лишней инфраструктуры.
glenv: синхронизируем .env файлы с GitLab CI/CD переменными без боли