▲

GN⁺: dotenv 에서 dotenvx 로 - 차세대 Config 관리자

 (dotenvx.com)
18P by neo 5달전 | favorite | 댓글 2개
  • 2013년 7월에 dotenv 첫 번째 커밋후 11년 동안 전 세계적으로 가장 많이 의존하는 패키지 중 하나로 성장
  • TypeScript, ESLint와 같은 필수 소프트웨어와 유사한 위치에 도달

dotenv의 문제점

  • .env 파일 유출 위험
  • 멀티 환경을 관리하기 어려움
  • 플랫폼 간 일관성 부족

문제 해결책: dotenvx

  • 모든 플랫폼에서 동일하게 작동
  • 멀티 환경 지원
  • 환경 변수 파일 암호화

어디서나 실행 가능

  • 모든 언어, 프레임워크, 플랫폼에서 동일하게 작동
  • dotenvx run -- your-cmd로 런타임에 환경 변수 주입 가능
  • .env 파싱 엔진, 변수 확장, 명령어 대체 등이 동일하게 작동
  • npm, brew, curl, docker, windows 등 다양한 방식으로 설치 가능 
    $ echo "HELLO=World" > .env  
$ echo "console.log('Hello ' + process.env.HELLO)" > index.js  
$ node index.js  # dotenvx 없이  
Hello undefined  
$ dotenvx run -- node index.js  # dotenvx 사용  
Hello World

다중 환경 지원

  • .env.production 파일 생성 후 -f 옵션으로 로드
  • 여러 -f 플래그를 사용하여 다중 환경 구성 가능 
    $ echo "HELLO=production" > .env.production  
$ dotenvx run -f .env.production -- node index.js  
[dotenvx][info] loading env (1) from .env.production  
Hello production

암호화

  • dotenvx encrypt 명령어로 .env 파일에 암호화 추가
  • 공개 키 암호화 방식 사용
  • .env 파일이 유출되어도 DOTENV_PRIVATE_KEY 없이는 해독 불가능
  • 오픈 소스 프로젝트에서 이전 비밀을 해독하지 않고도 새로운 설정 추가 가능 
    $ dotenvx encrypt  
✔ encrypted (.env)

1.0.0 버전 릴리스

  • dotenvx 1.0.0 버전 릴리스 발표
  • 차세대 설정 관리 도구로 많은 개발자들이 활용할 수 있을 것

GN⁺의 의견

  • dotenvx는 보안과 편의성을 동시에 제공함
  • 여러 환경을 쉽게 관리할 수 있어 개발자에게 유용함
  • 암호화 기능은 보안에 민감한 프로젝트에 특히 유용함
  • dotenvx의 기능은 다양한 언어와 플랫폼에서 일관성을 제공하여 개발 효율성을 높임
▲
neo 5달전  [-]
Hacker News 의견

  • 환경 변수로 비밀 정보를 전달하지 않는 것이 좋음. 환경 변수는 쉽게 유출될 수 있음. 대신, 프로세스 내부에서 vault나 파일 시스템에서 비밀 정보를 읽는 것이 좋음.

  • .env 파일을 사용하는 이유는 간단하고 명확하기 때문임. 더 안전하고 강력한 설정 방식을 사용하려면 문서를 읽어야 함.

  • 작업에서 Mise를 사용하기 시작했음. 아직 많이 사용해보진 않았지만 유망해 보임. 로컬 테스트 DB 초기화, 린팅 스크립트 실행 등 작업을 처리하며, 환경 변수와 가상 환경도 관리함.

  • 비밀 정보 유출이 큰 문제이므로, dotenvx를 사용할 때 비밀 정보를 암호화하는 것이 현명함. 암호화되지 않은 비밀 정보를 지원하지 않는 도구가 더 안전함.

  • Sops와 비슷하지만 기본적으로 암호화된 기능이 없음. Sops는 AWS와 기존 키 관리 솔루션과 쉽게 통합되며, 5년 동안 두 개의 직장에서 사용해본 결과 매우 좋았음.

  • 비밀 정보를 암호화하고 커밋하는 것이 편리하지만, 암호화 키에 접근하면 모든 비밀 정보가 노출될 수 있음. 클라우드 환경의 비밀 관리자에 설정하고 다시 만지지 않는 것이 더 안전함.

  • 환경 변수는 과도하게 공유되고 파일은 로컬 권한에 의존함. 프로세스 간 비밀 정보를 전송하는 새로운 방법이 필요함. 예를 들어, Unix 소켓을 통해 한 번만 읽을 수 있는 방식으로 비밀 정보를 전달하는 것.

  • .env 파일을 vault에 올바르게 넣는 방법에 대한 문서가 필요함. vault가 비밀번호로 보호된다면, 애플리케이션이 vault 비밀번호를 읽을 수 있도록 명확한 텍스트로 작성해야 하는 문제가 있음.

  • 모든 환경 변수를 단일 파일에서 TOML 형식으로 관리하고 싶음. 이렇게 하면 업데이트, 비교, 공유가 쉬워짐. 하지만 환경 이름 일관성을 유지하는 것이 어려움. 이는 종종 빠른 결정이나 필요에 의해 발생하며, 수정하기 두려워함.

답변달기
▲
yangeok 5달전  [-]

프로그램 안에서 제품모드, 개발모드 안나누고, 실행 스크립트에서 바로 선언이 가능하군용

답변달기