Firebase-tools: 함수에 대한 JSON 파일 수락:config:set

@jpreynat에 동의합니다. 프로덕션에 배포하기 전에 구성 변수를 설정하는 것을 잊어버리는 날이 config:set 을 config.json으로 사용자 지정 배포 스크립트에 연결하면 추가된 것을 볼 수 있는 좋은 기능입니다.
지금 해결 방법이 있습니까? 아마도 구성에 파이프가 있습니까?

프로젝트 간에 구성을 복제하려는 것 같습니다. firebase functions:config:clone 이(가) 도움이 될까요?

약간의 맥락을 제공하기 위해 파일 기반 구성은 나쁜 관행(즉, 코드와 함께 저장된 비밀로 가득 찬 파일을 유지하고 잠재적으로 소스 리포지토리에 체크인할 수도 있음)을 조장한다고 생각하기 때문에 의도적으로 파일 기반 구성에서 벗어났습니다.

"필수" 구성 변수를 선언하는 방법(역학 미정)에 대해 어떻게 생각하시나요? 현재 프로젝트에서 필수 구성 없이 배포하려고 하면 변경되기 전에 오류가 발생합니다. 그렇게 하면 주요 문제가 해결됩니까? 그렇지 않다면 왜 파일을 갖는 것이 당신에게 특히 유용합니까?

@mbleigh 그게 바로 내가 원하는지 몰랐던 것입니다. 좋은 생각!
아마도 'Mechanics TBD'가 의미하는 바는 같지만: 원격이 아닌 프로젝트 내의 일부 파일에서 키/구성 구조를 정의하여 다른 모든 것과 마찬가지로 git/PR 검토 프로세스를 거치도록 합니다.
@jpreynat 도용 문제에 대해 죄송합니다.

@laurenzlong 조언 감사합니다. 하지만 구성을 복제하려는 것은 아닙니다.
우리의 주요 관심사는 배포 단계에 따라 다른 프로젝트 구성을 업데이트하는 것입니다.
따라서 기본적으로 환경(dev, staging 및 prod)별로 구성 파일이 있고 Firebase 구성을 각각 설정합니다(PR의 경우 마스터 및 태그 푸시).

@mbleigh 정보 감사합니다.
그러나 구성 파일을 사용하는 것보다 다른 방법으로 이러한 모든 환경을 저장하는 방법은 확실하지 않습니다.
현재는 단순하게 읽기 위해 JSON 형식으로 지정되어 있지만 functions:config:set 명령에 직접 전달하기 위해 키/값 쌍으로 형식을 지정하려고 합니다.
이것이 JSON 파일을 전달하는 것보다 더 안전하지 않다는 데 동의합니다.
파일을 사용하는 것 외에 다른 단계에 대해 환경 변수를 저장하는 방법에 대한 권장 사항이 있습니까?

@ahaverty 걱정하지 마세요. 여기서 토론할 수 있어 기쁩니다.

@jpreynat functions:config:set 를 실행하면 현재 프로젝트와 함께 저장됩니다. firebase use 를 사용하여 프로젝트 간에 전환하는 경우 구성이 영구적입니다. 따라서 프로젝트당 set 한 번 실행할 수 있으며 그러면 항상 있을 것입니다. 이것은 "다른 환경에 대한 다른 구성"문제를 해결해야하므로 실제 문제를 이해하지 못하는 것입니까?

@jpreynat 지금은 이 문제를 닫을 예정이지만 Michael과 내가 귀하의 요청을 잘못 이해한 경우 다시 여십시오.

@laurenzlong @mbleigh 이 스레드에 대해 빠르게 답변하지
현재 이 문제에 대한 해결 방법을 찾았지만 다음은 내 요청을 명확히 하기 위한 몇 가지 컨텍스트입니다.

Travis를 사용하여 앱을 배포하고 있습니다(이는 모든 CI 또는 로컬에서 유용할 것입니다). 브랜치와 태그에 따라 다양한 스테이지에 앱을 배포하기 때문에 환경에 따라 다른 JSON 파일을 사용할 수 있으면 좋을 것 같습니다.
예를 들어 이 조건에 따라 firebase config:set -f staging.json 또는 firebase config:set -f prod.json 를 수행할 수 있습니다.
우리의 해결 방법은 firebase 를 노드 모듈로 사용하는 것이지만 여전히 오류가 발생하기 쉬운 JSON 구성을 인라인해야 합니다.

안녕하세요 @jpreynat 귀하의 답변에 여전히 약간 혼란 스럽습니다. 구성을 한 번 설정하면 firebase functions:config :unset을 실행하여 구성 값을 명시적으로 설정 해제하지 않는 한 배포 전반에 걸쳐 항상 그대로 유지됩니다. 따라서 CI 프로세스의 일부로 이것을 가질 필요가 없습니다.

누군가 이것을 다시 열 수 있습니까? %) @jpreynat @mbleigh 정말 빠진 것 중 하나입니다. Atm 나는 거의 15개의 구성 변수를 가지고 있으며 functions:config:set 가 어떤 식으로든 JSON을 받아들일 수 있다면 매우 편리할 것입니다.

"필수" 구성 변수 선언에 대한 @mbleigh 제안에 대한 우리의 큰 투표 -- 현재 프로젝트에서 필수 구성 없이 배포하려고 하면 아무것도 변경되기 전에 오류가 발생합니다.
우리에게도 골칫거리가 되지만, 그것은 우리의 모든 문제를 해결하고 버전 관리/검토 프로세스에 잘 맞을 것입니다 👍

https://medium.com/@AllanHasegawa/setting -config-for-firebase-cloud-functions-with-json-136f455e7c69

@yaronyosef firebase functions:config :set 명령에 JSON을 직접 제공할 수 있습니다. 플랫폼에 적합한 방식으로 형식을 지정하면 됩니다. Linux의 경우 다음이 작동해야 합니다.

firebase functions:config:set foo='{"bar":"something","faz":"other"}'

공유해 주셔서 감사합니다! @laurenzlong
파일에서 가져오고 싶었기 때문에 다음과 같은 명령을 사용했습니다.

firebase functions:config:set service_account="$(cat service-account.json)"

Firebase Admin SDK의 사용자 관리 API를 사용하고 싶었기 때문에 서비스 계정 json 파일을 Firebase Cloud Functions로 가져왔습니다.

멋진 사용 사례! 공유해 주셔서 감사합니다!

또한 Git을 통해 비밀이 아닌 구성을 추적하는 것을 선호합니다. 여기서 커밋된 JSON 런타임 구성 파일(여러 환경용)은 권한이 있고 CI 환경은 특정 환경에 해당하는 파일에서 functions:config:set 를 적용합니다. 각 환경은 별도의 Firebase 프로젝트에 해당합니다.

git에 구성을 유지하는 경우 기능 런타임으로 구성을 읽는 것은 간단합니다. configs/<project_id>.json 에 넣은 다음:

let config = {};
try {
  config = require(`./configs/${process.env.GCLOUD_PROJECT}.json`);
} catch (e) {
  console.log('No config found for project', process.env.GCLOUD_PROJECT);
}

Firebase에서 사용하는 런타임 구성은 (특히 비밀의 경우) 구성이 해결하는 것보다 더 많은 문제를 일으키는 패턴으로 밝혀졌기 때문에 구성이 git에 체크인되는 것을 방지하도록 특별히 설계되었습니다.

사실이지만 더 이상 이 목적으로 Config API를 사용하지 않습니다. 민감한 값을 저장하기 위해 Config API(Firebase 문서에 따르면 적절한 사용 사례인 것으로 보임)를 계속 진행하고 동일한 방식으로 소스 제어 값과 추적되지 않은 값을 모두 로드하는 것이 유리할 수 있습니다(예: config() 제공 firebase-functions ).

당분간은 .runtimeconfig 에 functions:config:set 전체를 공급하기 위해 다음 한 줄짜리를 사용하고 있습니다.

firebase functions:config:set $(jq -r 'to_entries[] | [.key, (.value | tojson)] | join("=")' < .runtimeconfig/${FIREBASE_ENV}.json)

여기서 FIREBASE_ENV 는 배포에 사용된 환경의 이름입니다(예: dev ). 이것을 더 줄일 수 있으면 좋을 것입니다. 예를 들어

firebase functions:config:set -f .runtimeconfig/${FIREBASE_ENV}.json

그러나 궁극적으로 Config API가 모든 변경 사항에 대한 사용하기 쉬운 감사 추적을 활성화한 경우에도 필요하지 않을 수 있습니다(이미 그런 경우에는 수정해 주세요. 이에 대해 살펴보고 싶습니다).

그래서 이것은 어떻게 오고 있습니까? 😄

@mbleigh 제안 이 여전히 구현되는 것을 보고 싶습니다 ! 개발자가 아닌 대상에서 구성을 설정하는 것을 잊어버리는 문제가 지속적으로 발생합니다.

스레드 범프 주셔서 감사합니다. 아직 보고할 내용이 없지만 계획 회의에서 이를 다시 언급하여 이에 대한 진전을 시작할 수 있는지 확인하겠습니다.

JSON 스키마 파일로 구성의 유효성을 검사하여 예상한 모든 값이 있는지 확인합니다. 이 유효성 검사는 내 CI 파이프라인의 일부이며 실패할 경우 배포를 방지합니다. 저처럼 TypeScript를 사용하여 함수를 작성하는 경우 유형에서 JSON 스키마를 생성할 수 있습니다.

config 함수가 문자열만 허용한다는 제한과 함께 훌륭하게 작동하므로 스키마는 config 값이 숫자인지 확인할 수 없습니다. 부울의 경우 "true" 및 "false" 있는 열거형을 유일한 유효한 값으로 사용할 수 있기 때문에 괜찮습니다.

내 CircleCI 구성 과 이 블로그 게시물 을 참조하세요.

@hgwood 공유

이 "문제"에 대한 내 솔루션과 토론에 대한 내 생각을 남기고 싶었습니다.

1. 나는 비밀/민감한 값이 저장소에 저장되어서는 안된다는 것을 이해합니다. 내 솔루션은 비밀이 아닌 값에만 적용됩니다. 비밀 값은 수동으로 설정되지만 구성 값을 필요에 따라 표시하는 방법은 이러한 비밀 값에 대해 훌륭할 것입니다.
2. 나는 이것이 일부 사람들이 생각하는 것보다 더 중요하다고 생각합니다. 다른 배치 환경 프로젝트에 대해 개별 구성 값을 수동으로 설정해야 하며 동시에 쉽게 보고/비교할 수 없다는 것이 PITA입니다. 파일에 구성을 정의하면 프로세스가 훨씬 덜 번거롭습니다.
3. 웹 콘솔에 기능 구성 편집기를 추가하면 이 점이 많이 개선될 것이라고 생각하지만 여러 프로젝트에 대한 구성을 동시에 볼 수 있는 방법이 있으면 다른 배포 환경에 대한 구성을 쉽게 비교할 수 있는 방법이 있으면 정말 좋을 것입니다.
4. 저는 Firebase가 단일 프로젝트 내에서 환경을 정의할 수 있어야 하므로 배포 환경으로 사용할 여러 프로젝트가 필요하지 않다고 영원히 말했습니다. 이것이 존재한다면 단일 프로젝트 내에서 여러 환경에 대한 구성을 동시에 보는 것이 매우 쉬울 것입니다.
5. 내 솔루션에는 문제가 있을 수 있습니다. 내 코드를 그대로 믿지는 않지만 일반적인 개념은 마음에 듭니다.

내 솔루션

저는 cascading yaml 구성 파일을 사용하는데, 이는 배포 환경에 관계없이 모든 구성에 적용되는 기본값과 값에 유용합니다.

./config/default.yml

app:
  name: My App
featureFlags:
  someFeature:
    enabled: false

./config/dev.yml (다른 배포 환경에 대한 유사한 구성 파일)

imports:
  - {resource: default.yml}
app:
  environmentName: Development
services:
  someOtherService:
    baseUrl: https://dev.someotherservice.com/api
featureFlags:
  someFeature:
    enabled: true

그런 다음 확인된 구성을 로드하고 공백으로 구분된 key=val 쌍 목록을 반환하는 작은 노드 스크립트를 작성했습니다.

yaml_to_keyval.ts

import * as configYaml from "config-yaml"
import * as flat from "flat"


const yamlFile = process.argv[2]
const config = configYaml(yamlFile)
const flatConfig = flat(config)

const key_val_list = Object.keys(flatConfig).map(function(key){
    return `${key}=${flatConfig[key]}`
})

console.log(key_val_list.join(' '))

CI 배포 중에 이 bash 셸 스크립트를 사용하여 key=val 쌍을 얻고 functions:config :set 으로 설정합니다.

# env is set to the desired deployment environment (eg "dev"), which is passed as an argument to the CI script command
config_in="$(readlink -f ./config/$env.yml)"
key_vals="$(ts-node ./scripts/node/yaml_to_keyval.ts $config_in)"
firebase functions:config:set $key_vals

@kanemotos cat 솔루션이 마음에 드는데 인증서 파일을 업로드하려고 할 때 Precondition check failed 오류가 발생하지 않았습니까?

이러한 이유로 결국 Deployment Manager를 사용하게 되었습니다.

DM용 "config Yaml"을 통해 모든 구성을 설정합니다. 그런 다음 DM은 적절한 런타임 구성 및 변수를 생성하고 firebase deploy 는 firebase config:set 를 전혀 사용하지 않고도 배포 시 해당 값을 검색하고 설정합니다. 이를 통해 다른 리소스(예: 버킷 및 해당 액세스 제어)를 설정하고 템플릿에 외부적으로 제공하지 않고도 RC에서 값을 설정할 수 있습니다. 또한 이를 통해 camelCase 구성 및 변수 이름을 사용할 수 있습니다.

외부적으로 값을 설정하는 유일한 경우는 DM이 값을 안전하게 암호화할 수 없기 때문에 런타임 구성을 통해 (암호화된) 서비스 계정 키를 전달해야 할 때입니다. 그러나 전자는 KMS에서 stdout을 허용하므로 firebase config:set 아니라 gcloud beta runtime-config configs variables set (DM 배포 후 및 firebase deploy 이전)를 사용합니다.

나는 단지 추가하고 싶었습니다. 이것을 읽으면 일부 사람들은 약간의 혼란으로 이끄는 중요한 요점을 놓친 것 같습니다. 이것이 문서에서도 지워진다면 정말 유용할 것입니다.

기본적으로 functions.config() 는 _deployments_ 사이에 유지되지만 다른 Firebase 프로젝트 간에 별도로 설정할 수도 있습니다!

즉, dev, staging 및 prod 환경의 경우 여러 동일한 Firebase 프로젝트를 설정해야 합니다(다중 사이트 호스팅을 사용하거나 동일한 프로젝트에 배포하는 대신... 👎 ). 각각은 고유한 환경 변수를 지속적으로 보유합니다. .

별칭을 설정하거나 firebase use 하여 프로젝트 간에 전환하면 동일한 저장소 를 여러 개의 개별 Firebase 프로젝트에 배포할 수 있습니다. 별도의 Firebase 프로젝트로 개발 환경, 스테이징 및 프로덕션을 설정하는 방법입니다.

그런 다음 다음과 같이 각각에 대해 별도의 환경 구성을 설정할 수 있습니다.
firebase -P dev config:set - 개발 환경에 대한 변수 설정
firebase -P prod config:set - 프로덕션 환경에 대한 변수 설정...

그런 다음 다음과 같이 동일한 리포지토리를 두 ​​번 배포할 수 있습니다.
firebase deploy -P dev
firebase deploy -P prod
둘 다 각각의 Firebase 프로젝트에 배포하고 배포 간에 유지되는 별도의 환경 구성을 포함합니다.

네, 저희도 그렇게 합니다. dev/test/prod에 대한 별도의 프로젝트.

개발 중인 플랫폼(Windows, MacOS, Linux)과 관련하여 작동하는 바닐라 JS 솔루션을 공유하기만 하면 됩니다.

dev/test/prod에 대해 별도의 프로젝트를 사용합니다.

/.firebaserc

{
  "projects": {
    "dev": "my-project-name-dev",
    "test": "my-project-name-test",
    "prod": "my-project-name-prod"
  }
}

구성 파일

/functions/config 폴더의 JSON 파일:

/functions/config/config.dev.json 
/functions/config/config.test.json 
/functions/config/config.prod.json 
/functions/config/config.SAMPLE.json <-- only file tracked in git

Example content:
{
    "google": {
        "key": "my-api-key",
        "storage_bucket": "firebase-storage-bucket"
    },
    "another_vendor": {
        "my_prop": "my value"
    },
    ...
}

/functions/set-config.js

const fs = require('fs');
const env = process.argv[2];

const configPath = `./config/config.${env}.json`;

if (!(configPath && fs.existsSync(configPath))) {
    return;
}

const collectConfigLines = (o, propPath, configLines) => {
    propPath = propPath || '';
    configLines = configLines || [];
    for (const key of Object.keys(o)) {
        const newPropPath = propPath + key;
        if (typeof o[key] === 'object') {
            collectConfigLines(o[key], newPropPath + '.', configLines);
        } else if (o[key] != null && o[key] !== '') {
            configLines.push(`${newPropPath}=${JSON.stringify(o[key])}`);
        }
    }
}

const config = require(configPath);
const configLines = [];
collectConfigLines(config, '', configLines);

const cp = require('child_process');
cp.execSync(`firebase -P ${env} functions:config:set ${configLines.join(' ')}`);

/함수/패키지.json

...
"scripts": {
    "config:set:dev": "node set-config dev",
    "config:set:test": "node set-config test",
    "config:set:prod": "node set-config prod",
    ...
},
...

누군가 여전히 찾고 있다면 이 매체 기사 https://medium.com/indielayer/deploying-environment-variables-with-firebase-cloud-functions-680779413484에 사용된 방법이

개인적으로 누락된 것은 배포 를 수행

또한 일부 기능이 개발 중인 상태에서 나중에 기존 변수를 변경하려는 경우 지금 마지막으로 릴리스된 태그를 체크아웃하고 빌드하고 배포하고 기능 분기로 다시 체크아웃하고 계속하십시오. 이것은 실제로 이것을 사용할 수 없게 만듭니다.

기본적으로 우리는 클라우드 기능에 대한 원격 구성을 원할 것입니다.

@bezysoftware 환경 구성 대신 환경 변수를 사용해야 한다고 생각합니다. Firebase 레이어를 건너뛰고 Google 클라우드 플랫폼에서 수행할 수 있습니다. https://cloud.google.com/functions/docs/env- var

공유해 주셔서 감사합니다! @laurenzlong
파일에서 가져오고 싶었기 때문에 다음과 같은 명령을 사용했습니다.

firebase functions:config:set service_account="$(cat service-account.json)"

Firebase Admin SDK의 사용자 관리 API를 사용하고 싶었기 때문에 서비스 계정 json 파일을 Firebase Cloud Functions로 가져왔습니다.

작동하지 않았다

@Md-Abdul-Halim-Rafi

firebase functions:config :set service_account="$(cat service-account.json)"

나를 위해 일했고 firebase functions:config:get 와 함께 config var를 볼 수 있습니다.
프로젝트 폴더에 없었고 config 변수를 설정할 Firebase 프로젝트를 선택하지 않았기 때문에 처음에는 작동하지 않았습니다. Firebase 프로젝트를 선택하려면 firebase use --add 를 사용하면 CLI에서 Firebase 콘솔의 프로젝트 목록( firebase login CLI에 로그인했다고 가정)

@dnhyde

firebase functions:config :set service_account="$(cat service-account.json)"

json 파일에서 문자열(예: 부울 또는 숫자)을 제외한 다른 값 유형을 사용하는 동안에는 작동하지 않는 것 같습니다.

{
   "test": {
        "hmm": true
    }
}

실패:

Error: HTTP Error: 400, Invalid value at 'variable.text' (TYPE_STRING), true

내가 할 수 있어야 하는 것이 합리적으로 보입니다.

firebase functions:config:get > config.json

그리고 나중에:

firebase functions:config:set < config.json

이 두 명령을 보완적으로 사용하는 것이 합리적입니다.

파일에 구성이 있으면 버전을 제어하고 시간이 지남에 따라 어떻게 변경되었는지 확인할 수 있습니다.

지금 당장 이것을 달성해야 하는 유일한 방법( env=$(cat config.json) )도 { env: ... } 래핑할 수 없기 때문에 config.json 이 실제 값이 되도록 하는 능력을 깨뜨리는 결과를 초래한다는 것은 불행한 일입니다.

참고 사항: 여기에서 기능 풀 요청을 시작해야 합니다. https://github.com/firebase/firebase-tools/blob/b17611a4ff0d36e157ed06a24f6c81d4e146d9e2/src/functionsConfig.js#L142

개발 중인 플랫폼(Windows, MacOS, Linux)과 관련하여 작동하는 바닐라 JS 솔루션을 공유하기만 하면 됩니다.

dev/test/prod에 대해 별도의 프로젝트를 사용합니다.

/.firebaserc

{
  "projects": {
    "dev": "my-project-name-dev",
    "test": "my-project-name-test",
    "prod": "my-project-name-prod"
  }
}

구성 파일

/functions/config 폴더의 JSON 파일:

/functions/config/config.dev.json 
/functions/config/config.test.json 
/functions/config/config.prod.json 
/functions/config/config.SAMPLE.json <-- only file tracked in git

Example content:
{
    "google": {
        "key": "my-api-key",
        "storage_bucket": "firebase-storage-bucket"
    },
    "another_vendor": {
        "my_prop": "my value"
    },
    ...
}

/functions/set-config.js

const fs = require('fs');
const env = process.argv[2];

const configPath = `./config/config.${env}.json`;

if (!(configPath && fs.existsSync(configPath))) {
    return;
}

const collectConfigLines = (o, propPath, configLines) => {
    propPath = propPath || '';
    configLines = configLines || [];
    for (const key of Object.keys(o)) {
        const newPropPath = propPath + key;
        if (typeof o[key] === 'object') {
            collectConfigLines(o[key], newPropPath + '.', configLines);
        } else if (o[key] != null && o[key] !== '') {
            configLines.push(`${newPropPath}=${JSON.stringify(o[key])}`);
        }
    }
}

const config = require(configPath);
const configLines = [];
collectConfigLines(config, '', configLines);

const cp = require('child_process');
cp.execSync(`firebase -P ${env} functions:config:set ${configLines.join(' ')}`);

/함수/패키지.json

...
"scripts": {
    "config:set:dev": "node set-config dev",
    "config:set:test": "node set-config test",
    "config:set:prod": "node set-config prod",
    ...
},
...

개발 중인 플랫폼(Windows, MacOS, Linux)과 관련하여 작동하는 바닐라 JS 솔루션을 공유하기만 하면 됩니다.

dev/test/prod에 대해 별도의 프로젝트를 사용합니다.

/.firebaserc

{
  "projects": {
    "dev": "my-project-name-dev",
    "test": "my-project-name-test",
    "prod": "my-project-name-prod"
  }
}

구성 파일

/functions/config 폴더의 JSON 파일:

/functions/config/config.dev.json 
/functions/config/config.test.json 
/functions/config/config.prod.json 
/functions/config/config.SAMPLE.json <-- only file tracked in git

Example content:
{
    "google": {
        "key": "my-api-key",
        "storage_bucket": "firebase-storage-bucket"
    },
    "another_vendor": {
        "my_prop": "my value"
    },
    ...
}

/functions/set-config.js

const fs = require('fs');
const env = process.argv[2];

const configPath = `./config/config.${env}.json`;

if (!(configPath && fs.existsSync(configPath))) {
    return;
}

const collectConfigLines = (o, propPath, configLines) => {
    propPath = propPath || '';
    configLines = configLines || [];
    for (const key of Object.keys(o)) {
        const newPropPath = propPath + key;
        if (typeof o[key] === 'object') {
            collectConfigLines(o[key], newPropPath + '.', configLines);
        } else if (o[key] != null && o[key] !== '') {
            configLines.push(`${newPropPath}=${JSON.stringify(o[key])}`);
        }
    }
}

const config = require(configPath);
const configLines = [];
collectConfigLines(config, '', configLines);

const cp = require('child_process');
cp.execSync(`firebase -P ${env} functions:config:set ${configLines.join(' ')}`);

/함수/패키지.json

...
"scripts": {
    "config:set:dev": "node set-config dev",
    "config:set:test": "node set-config test",
    "config:set:prod": "node set-config prod",
    ...
},
...

죄송하지만 " config:set :dev" 스크립트는 언제 실행합니까? 이해가 안되네요... 감사합니다!