flowchart TD
    id1([$ docker]) --> id2([GitLab Dependency Proxy])
    id2 --> id3([DockerHub])

sequenceDiagram
    Client->>+GitLab: Login? / request token
    GitLab->>+Client: JWT
    Client->>+GitLab: request a manifest for an image
    GitLab->>+ExternalRegistry: request JWT
    ExternalRegistry->>+GitLab : JWT
    GitLab->>+ExternalRegistry : request manifest
    ExternalRegistry->>+GitLab : return manifest
    GitLab->>+GitLab : store manifest
    GitLab->>+Client : return manifest
    loop request image layers
        Client->>+GitLab: request a blob from the manifest
        GitLab->>+ExternalRegistry: request JWT
        ExternalRegistry->>+GitLab : JWT
        GitLab->>+ExternalRegistry : request blob
        ExternalRegistry->>+GitLab : return blob
        GitLab->>+GitLab : store blob
        GitLab->>+Client : return blob
    end

sequenceDiagram
  autonumber
  participant C as Docker CLI
  participant R as GitLab (Dependency Proxy)
Note right of C: User tries docker login gitlab.com and enters username/password
C->>R: GET /v2/
Note left of R: Check for Authorization header, return 401 if none, return 200 if token exists and is valid
R->>C: 401 Unauthorized with header "WWW-Authenticate": "Bearer realm="http://gitlab.com/jwt/auth\",service=\"registry.docker.io\""
Note right of C: Request Oauth token using HTTP Basic Auth
C->>R: GET /jwt/auth
Note left of R: Token is returned
R->>C: 200 OK (with Bearer token included)
Note right of C: original request is tested again
C->>R: GET /v2/ (this time with Authorization: Bearer [token] header)
Note right of C: Login Succeeded
R->>C: 200 OK

graph TD
    A[Receive manifest request] --> | We have the manifest cached.| B{Docker manifest HEAD request}
    A --> | We do not have manifest cached.| C{Docker manifest GET request}
    B --> | Digest matches the one in the DB | D[Fetch manifest from cache]
    B --> | HEAD request error, network failure, cannot reach DockerHub | D[Fetch manifest from cache]
    B --> | Digest does not match the one in DB | C
    C --> E[Save manifest to cache, save digest to database]
    D --> F
    E --> F[Return manifest]

sequenceDiagram
    Client->>Workhorse: GET /v2/*group_id/dependency_proxy/containers/*image/manifests/*tag
    Workhorse->>Rails: GET /v2/*group_id/dependency_proxy/containers/*image/manifests/*tag
    Rails->>Rails: Check DB. Is manifest persisted in cache?
alt In Cache
    Rails->>Workhorse: Respond with send-url injector
    Workhorse->>Client: Send the file to the client
else Not In Cache
    Rails->>Rails: Generate auth token and download URL for the manifest in upstream registry
    Rails->>Workhorse: Respond with send-dependency injector
    Workhorse->>External Registry: Request the manifest
    External Registry->>Workhorse: Download the manifest
    Workhorse->>Rails: GET /v2/*group_id/dependency_proxy/containers/*image/manifest/*tag/authorize
    Rails->>Workhorse: Respond with upload instructions
    Workhorse->>Client: Send the manifest file to the client with original headers
    Workhorse->>Object Storage: Save the manifest file with some of its header values
    Workhorse->>Rails: Finalize the upload
end</code></pre></details></div>

정리 정책#
Dependency Proxy의 정리 정책은 TTL(Time-To-Live) 정책으로 동작합니다. 사용자는 읽지 않은 파일이 캐시에 남아
있을 수 있는 일수를 설정할 수 있습니다. blob을 그 blob이 속한 이미지와 연결할 방법이 없기 때문에(이를 위해서는
컨테이너 레지스트리 팀이 구축한 메타데이터 데이터베이스를 만들어야 합니다), "이 blob이 90일 동안 pull되지
않으면 삭제한다"와 같은 규칙을 설정할 수 있습니다. 즉, 계속해서 pull되는 파일은 캐시에서 제거되지 않지만,
예를 들어 alpine:latest가 바뀌어 기반 blob 중 하나가 더 이상 사용되지 않으면 pull이
중단되므로 결국 정리됩니다. 특정 dependency_proxy_blob 또는 dependency_proxy_manifest가
마지막으로 pull된 시점을 추적하는 데는 read_at 속성을
사용합니다.
이 정책은 cron 워커 DependencyProxy::CleanupDependencyProxyWorker로
동작하며, 이 워커는 제한된 용량 워커 두 개를 시작합니다. 하나는 blob을 삭제하고,
다른 하나는 매니페스트를 삭제합니다. 용량은 애플리케이션 설정에서 지정합니다.
히스토리 참조 링크#

비공개 그룹을 위한 Dependency proxy - 초기 인증 구현
매니페스트 캐싱 - 초기 매니페스트 캐싱 구현
blob을 위한 Workhorse - 초기 Workhorse 구현
매니페스트를 위한 Workhorse - 매니페스트 캐시 로직을 Workhorse로 이동
배포 토큰 지원 - 인가 전면 업데이트
SSO 지원 - 정책 확인 방식 변경