OpenTF 저장소가 이제 공개되었습니다

 (github.com/opentffoundation)
1P by GN⁺ | ★ favorite | 댓글 1개
  • OpenTofu는 인프라를 안전하고 효율적으로 구축·변경·버전 관리하기 위한 OSS 도구임
  • 기존의 인기 있는 서비스 제공자와 사내 맞춤형 솔루션을 모두 관리할 수 있음
  • 인프라를 고수준 설정 문법으로 опис하는 Infrastructure as Code 방식을 사용하며, 데이터센터 청사진을 코드처럼 버전 관리하고 공유·재사용할 수 있음
  • apply 호출 전에 실행 계획을 생성하는 planning 단계를 제공해 OpenTofu가 인프라에 수행할 작업을 미리 확인할 수 있음
  • 모든 리소스의 Resource Graph를 만들고 의존성이 없는 리소스의 생성·수정을 병렬화해 인프라 의존성에 대한 가시성을 제공함
  • 복잡한 변경 집합을 최소한의 사람 개입으로 적용할 수 있으며, 실행 계획과 리소스 그래프를 통해 무엇을 어떤 순서로 바꿀지 확인 가능함
  • main의 최신 변경을 테스트하기 위한 Nightly Builds가 제공되며, 실험적 빌드이고 프로덕션 사용 목적이 아님
  • 보안 취약점 또는 잠재 취약점은 Security Policy를 따라 보고하는 방식임
  • 특정 원산지 국가의 레지스트리 접근을 차단하며, 세부 사항은 Registry Inclusion Policy에 따름
  • 라이선스는 Mozilla Public License v2.0임

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 요청이 많았던 대로 드디어 저장소를 공개했고, 앞으로는 공개적으로 개발을 이어갈 예정임
    시간이 좀 걸렸지만 자세한 내용은 발표문에서 볼 수 있음: https://opentf.org/fork
    지금까지의 지원에 감사하고, 저장소에서 토론에 참여하거나 기여해주길 바람
    HN에서도 꽤 논의됐던 기여 방식은 DCO로 정했음: https://developercertificate.org
    질문이 있으면 답할 수 있음. Spacelift에서 일하고 있으며, 위원회 주도로 넘어가기 전까지 OpenTF Project의 임시 Technical Lead를 맡고 있음

  • 이 전체 과정이 꽤 멋지다고 봄. HashiCorp는 라이선스가 “프로젝트” 자체가 아니라 프로젝트 버전에 붙는다는 걸 잘 알고 있었고, 이를 기업용 제품 수익 극대화에 활용했음
    커뮤니티도 한 번 특정 버전에 라이선스를 붙이면 되돌릴 수 없다는 걸 알고 있었고, 그 라이선스가 적용된 지점부터 포크해 버전별로 자체 “새” 프로젝트를 만들면 계속 오픈소스로 유지할 수 있다는 것도 알고 있었음
    앞으로 어떻게 전개될지 흥미롭고, 향후 소프트웨어 라이선스의 사례 연구가 될 듯함. OpenTF가 장기적으로 어떻게 될지 기대됨

    • 커뮤니티 영향과 대응 면에서는 Hudson과 Jenkins의 분리에 가장 가까워 보임. 라이선스 쪽은 다르지만: https://en.wikipedia.org/wiki/Hudson_(software)
      이런 일에는 Oracle이 거의 항상 엮이는 느낌인데, Terraform에서는 의외로 아니었음 :D
    • “프로젝트 버전에 붙은 라이선스”와 “프로젝트 자체에 붙은 라이선스”를 구분할 이유는 없음. HashiCorp는 앞으로의 라이선스를 바꿀 권리가 있었고, 누구든 이전 버전을 계속 쓰거나 포크할 권리도 있었음. 실제로 여기서 그렇게 된 것임
    • 역사적으로는 Hudson/Jenkins 코드베이스를 살펴보는 것도 흥미로울 수 있음

  • “이름과 관련해 법률 전문가 몇 명과 상담 중이며, ‘TF’ 사용 때문에 OpenTF도 최종 이름이 아닐 가능성이 있다”고 함
    이름에 TF가 들어가는 것만으로 문제가 될 수 있다는 게 흥미로움
    출처: https://github.com/opentffoundation/opentf/issues/273#issuecomment-1706947318

  • 두 가지를 요청하고 싶음. 첫째, 모듈과 공급자 모두를 위한 독립 실행형 레지스트리 패키지를 제공해주면 좋겠음. 아는 건 Artifactory뿐인데, Nexus를 쓰는 환경에서 또 큰 저장소 소프트웨어를 돌리고 싶지는 않음
    둘째도 관련된 내용인데, 공급자 모듈을 더 쉽게 포크할 수 있게 해주면 좋겠음. 지금처럼 로컬에서 빌드해 동료들에게 바이너리를 수동 복사해 배포하거나, 특히 업스트림이 CLA 서명을 요구할 때 PR이 받아들여지길 기다리는 방식은 별로임

    • 첫 번째 요청을 좀 더 설명해줄 수 있을까? 개인용 공급자/모듈 레지스트리를 돌릴 수 있는 자체 포함 바이너리를 원하는 거라면, 그런 오픈소스 프로젝트가 몇 개 있고, DockerHub나 GitHub Container Registry 같은 OCI 레지스트리를 통해 공급자를 배포하는 방식의 개념 증명도 해봤음
      이 사용 사례에는 OCI 레지스트리가 꽤 잘 맞음: https://twitter.com/opentforg/status/1696913055576387599
      이 개념 증명은 곧 공개 RFC로 이어질 예정임
      두 번째 요청과 관련해서는, 생각하는 이상적인 작업 흐름이 있는지 궁금함
      Spacelift에서 일하고 있으며, 위원회 주도로 넘어가기 전까지 OpenTF Project의 임시 Technical Lead를 맡고 있음

  • “terrafork”로 갔어야 했음

  • 보기 좋음. 테스트를 해볼 수 있게 https://github.com/opentffoundation/roadmap/issues/8을 기다리는 중임
    소스에서 빌드할 수는 있지만, 가능하면 릴리스 빌드를 쓰고 싶음

  • 대충 훑어봤는데 문서가 훌륭해 보임. Terraform 내부 구조를 좀 다뤄본 입장에서, 이 코드베이스를 작업하려는 개발자에게는 꽤 큰 개선처럼 보임
    시작하기 좋은 전체 개요를 제공해줌. 잘했음

    • 어떤 문서를 말하는지 정확히 모르겠지만, 대부분의 문서는 원본 저장소에서 상표 관련 부분을 제외하면 크게 바뀌지 않았음
      문서가 좋아졌다면 공은 Terraform Core 개발자들에게 돌아가야 함
      Spacelift에서 일하고 있으며, 위원회 주도로 넘어가기 전까지 OpenTF Project의 임시 Technical Lead를 맡고 있음

  • 완전히 곁가지지만, 로고가 어두운 배경에서 짙은 파란색이라 꽤 어색해 보임
    흰색 외곽선도 충분히 굵지 않아서 어두운 배경과 겹치면 픽셀이 두드러져 보임

    • 확실히 사소한 디자인 논쟁이긴 한데, TensorFlow 로고처럼 보이기도 해서 잠깐 Google에서 프로젝트를 독립시키는 그룹인 줄 알았음

  • 이 코드베이스가 마지막으로 “계속 써도 괜찮은” Terraform 라이선스 커밋과 비교해 어떻게 다른지 차이점을 가진 사람이 있을까?
    새 라이선스 논란과 변경 때문에 실제로 무엇을 바꿔야 했는지 잘 이해가 안 됨

  • GitHub 페이지의 로고는 어두운 배경에서 개선이 필요해 보임. 특히 어두운 글자에 밝은 외곽선이 생기는데, 알파 번짐처럼 보이고 계단 현상이 남음

답변달기