| [[GitHub| | ||
| {{{#!wiki style="min-height: calc(1.5em + 5px); margin: 0 -10px -5px" {{{#!folding [ 펼치기 · 접기 ] {{{#!wiki style="margin: -5px -1px -11px" | <colbgcolor=#000,#000><colcolor=#fff,#fff> 관련 인물 | 톰 프레스턴 워너 |
| 서비스 | 저장소 · GitHub Pages · GitHub Action · GitHub Packages · GitHub Wiki · GitHub Gist · GitHub Copilot | |
| 클라이언트 | GitHub CLI · GitHub Desktop | |
| 오픈 소스 | Electron · Atom · Tree-sitter | |
| 관련 문서 | 사건 사고 · GitHub Universe · npm | }}}}}}}}} |
1. 개요
GitHub의 폴리글랏 패키지 레지스트리(패키지 저장소) 서비스.2. 역사
2021년 5월 14일 비공개 베타 액세스가 시작되었다.[1]2020년 9월 1일 GHCR 서비스가 공개 베타 기능으로 추가되었다.[2]
2021년 6월 21일부터 GHCR 서비스가 정식 서비스로 편입되고, 기존 docker 레지스트리가 전부 GHCR로 마이그레이션 되었다.[3]
3. 호환 레지스트리
npm.pkg.github.com: npmmaven.pkg.github.com: JVM 기반 언어 - Maven Central과 호환된다.nuget.pkg.github.com: NuGet(.NET 기반 언어)rubygems.pkg.github.com: RubyGems(Ruby)ghcr.io: OCI 호환 컨테이너 레지스트리. GitHub Container Regisry의 약자로, 흔히 GHCR로 줄여서 부른다.docker.pkg.github.com: GHCR 기능으로 지원 중단되었다.
4. 특징
하나의 저장소에 1:1로만 한정되는 것은 아니다. 각 패키지는 저장소와 같이 소유자(개인 유저, 또는 조직)에 종속되며, 개인 사용자의 경우https://github.com/<사용자명>?tab=packages, 조직의 경우 https://github.com/orgs/<조직명>/packages에서 해당 소유자에 귀속된 모든 패키지를 볼 수 있다. 특히 단일 조직 내에서 polyrepo를 구축할 때 매우 유용한데, 각 저장소 하나마다 하나의 패키지를 만들고 이를 조직 내에서 참조할 수 있다. 물론 상술한 대로 1:1 관계가 아니라 하나의 저장소에서 여러 패키지를 배포하는 것도 가능하며, 이 경우 모노레포 파이프라인에 적합하다. 저장소와 완전히 비종속이기 때문에 어느 저장소와도 무관한 패키지를 그냥 배포하는 것도 가능하다.GitHub Action이랑 상성이 좋다. 저장소 하나에서 on push/on release 등 트리거마다 액션 하나 설정해서 빌드하고, GHP로 배포하는 워크플로우를 구축하기 매우 쉽다. 또한 대부분의 경우 GHA 내부의
GITHUB_TOKEN은 해당 저장소에 연결된 패키지에 write:packages 권한을 가진 상태이기 때문에 별도의 secret 설정 필요없이 액션 파일만 가져다 넣어도 잘 동작한다.특히 Docker쪽이 액션 생태계가 매우 잘 되어있는 편인데,
setup-buildx-action, login-action, metadata-action, build-push-action, bake-action 등 docker 쪽 org에 일반적인 경우에 쓰일 액션을 거의 전부 다 제공해준다.metadata-action이 매우 좋은 게 GHA 메타데이터에서 저장소 주소를 읽어내서 알아서 label을 입혀준다. GHCR에선 org.opencontainers.image.source 레이블로 저장소 주소를 넣으면 배포된 패키지를 자동으로 해당 저장소와 연결(link)해주는데, 이런 메타데이터 추출 및 레이블링을 자동화할 수 있기 때문이다.# 또한 tags 옵션만 잘 설정해도 따로 shell 액션 넣어서 파싱하고 output 참조할 필요 없이 그냥 요구한 모든 종류의 태그를 전부 빌드해준다.#다만 모노레포 구성시에 다소의 레이어 구축이 필요할 수는 있다. label도 따로 관리해야 하고 액션 트리거 설정도 조금 난잡해지기에... HCL로
docker-bake.hcl을 잘 짜두었다면 bake-action을 써보는 것도 좋다. 이 경우 metadata bake를 동적으로 생성해줘서 머지만 해주면 쓸 수 있다.5. 단점
사실상 GHCR이랑 npm이 주력 상품이고 나머지 언어는 지원이 전무하다. PyPI 호환, PHP, Kubernetes Helm이나 crates 지원도 몇년째 답이 없다. 사실상 정해진 use case로만 쓰는 것이 편하다(GHCR 등). 범용 private registry가 필요하면 GHP로는 힘들고 결국 사내 레지스트리 환경을 구축해야 한다.npm 쪽으로 작업할 때 네임스페이스가 사실상 강제된다. 사내에서 사용하는 용도면 상관이 없는데 npm mirror package를 띄우려는 용도면 조금 복잡해진다. 이는 npm 프로토콜이 도메인 하나당 하나의 레지스트리로 판단하기 때문인데, GitHub Pages랑 다르게 유저(또는 조직)마다 별도의 레지스트리 서브도메인을 만들지 않고
npm.pkg.github.com 하나에 namespace를 적용하기 때문.6. 기타
[1] You can try GitHub Package Registry today in limited beta. (...) GitHub Package Registry is currently in limited public beta. #[2] today we’re adding new capabilities to improve the experience and performance it provides for developers with GitHub Container Registry. (...) Available today as a public beta #[3] As a part of Container registry becoming generally available, we are consolidating the Docker registry into Container registry. If you have previously published Docker containers to docker.pkg.github.com, you will see them automatically migrated to the Container registry in the coming weeks. #