profile
viewpoint
Roman Vynar roman-vynar @Quiq Lviv, Ukraine https://quiq.com

roman-vynar/edison_exporter 3

Prometheus exporter for sensor metrics from Intel Edison

Quiq/oauth2_proxy 1

A reverse proxy that provides authentication with Google, Github or other provider

Quiq/registrator 1

Service registry bridge for Docker with pluggable adapters

Quiq/alertmanager 0

Prometheus Alertmanager

Quiq/bokchoy 0

Simple job queues for Go backed by Redis

Quiq/cloudwatch_exporter 0

A CloudWatch exporter for Prometheus coded in Go, with multi-region support

Quiq/consul-alerts 0

A simple daemon to send notifications based on Consul health checks

Quiq/docker_auth 0

Authentication server for Docker Registry 2

Quiq/grafana 0

Gorgeous metric viz, dashboards & editors for Graphite, InfluxDB & Prometheus

Quiq/haproxy_exporter 0

Simple server that scrapes HAProxy stats and exports them via HTTP for Prometheus consumption

pull request commentQuiq/docker-registry-ui

Support deleting manifest.list.v2

My apologies, I did not realize that subsequent commit would show up in the pull, I have reverted the commit to that branch.

Jenkinsfile is used by jenkins to automate image building. That specific Jenkinsfile is used by my Jenkins environment to build the arm and arm64 images I need to run docker-registry-ui on those platforms.

stevbev

comment created time in a month

PR opened Quiq/docker-registry-ui

Support deleting manifest.list.v2

Try obtaining manifest.list.v2 digest before manifest.v2 to support removal of manifest lists.

+5 -1

0 comment

1 changed file

pr created time in a month

issue commentQuiq/docker-registry-ui

Deleting a manifest list only deletes the first manifest

I studied the code a bit further and performed testing, the multiple Accept header does not seem a feasible solution. The gorequest module does not seem to support duplicate headers.

Instead there seems to be a trivial solution that exists in DeleteTag(). DeleteTag() calls callRegistry() using manifest.v2 only. I have added 4 lines that first try manifest.list.v2 and if the Content-Type is not for manifest.list.v2 then a second call is made using manifest.v2. This approach allows the manifests and manifest lists to be deleted manually as well as the automatically by the Purge task. I will prepare a pull request for this.

stevbev

comment created time in a month

issue commentQuiq/docker-registry-ui

Deleting a manifest list only deletes the first manifest

I think I have found a solution. For v2 registry, passing two Accept headers in the request message returns the expected digest in Docker-Content-Digest response header if the tag is a manifest-list or manifest.

Example: Accept: application/vnd.docker.distribution.manifest.v2+json Accept: application/vnd.docker.distribution.manifest.list.v2+json

I had a look at the registry-ui code and see the Accept header is using inline .Set() on the HTTP call in registry/client.go. I am not familiar enough with golang to convert from inline .Set() to setting the HTTP headers from an array. I think if the callRegistry() function could be updated to change manifestFormat from string to []string (or similar type), then it should be possible to send multiple Accept headers to get the desired behavior to delete manifest lists.

stevbev

comment created time in a month

issue commentQuiq/docker-registry-ui

Deleting a manifest list only deletes the first manifest

I think I have a lead. When clicking on a manifest list in Registry-UI, docker registry logs state msg="rewriting manifest list sha256:d0df...1fdf in schema1 format to support old client". This indicates Registry-UI is not adding HTTP header "Accept: application/vnd.docker.distribution.manifest.list.v2+json".

When this header is added to the API call the manifest list digest is returned in HTTP header "Docker-Content-Digest", and the digest of manifests is found in the body. Perhaps adding the Accept header will provide a standard method to obtain the digest for manifest lists and manifests for the Delete function.

stevbev

comment created time in a month

fork zwb-github/edison_exporter

Prometheus exporter for sensor metrics from Intel Edison

fork in a month

startedroman-vynar/edison_exporter

started time in a month

issue commentQuiq/docker-registry-ui

Deleting a manifest list only deletes the first manifest

Thank you for the reminder about #29, I did review that issue before submitting mine. #29 seems to be an issue with a manifest having multiple tags and cannot be deleted by sending the digest ID.

The issue I encounter is different from #29 in that all manifests have a single tag per digest, but the digest of the first manifest in the manifest list is what is sent in the DELETE call instead of the digest of the manifest list.

I reviewed the code but could not determine exactly how to resolve. I believe the issue is that there are several docker API calls using the Accept header, and the specific API call I think docker-registry-ui is using for the process following the Delete button only returns the contents of the manifest list but does not include the digest for the manifest list itself. I will keep poking around and brush up on Golang to see if I can help figure it out.

stevbev

comment created time in 2 months

issue openedQuiq/docker-registry-ui

Deleting a manifest list only deletes the first manifest

I use manifest lists to cover multi-architecture images (v4.0.1 manifest list contains v4.0.1-amd64, v4.0.1-arm, v4.0.1-arm64 manifests). The UI properly displays the manifest list when clicked on and shows the expected details for the 3 amd64/arm/arm64 manifests.

Using the Delete button for the manifest list results in the first manifest getting deleted (in my case the v4.0.1-amd64 manifest) instead of the manifest list getting removed. Additionally the automatic delete function removes the individual manifests as expected but leaves the manifest lists. The manifest lists successfully delete when passing the SHA256 hash to the docker registry REST endpoint. I think that docker-registry-ui is using the wrong digest for manifest lists.

I believe the attached log file quiq-docker-registry-ui_delete.txt helps demonstrate the issue.

  • The manifest list for app_name:4.0.1 has digest "cace61c076b1f4f186f323eab626300bee5493f8d80b4e2b7ace8d303b675095"
  • Manifest #1 has digest of "eaf66f4047adcb7f40ef92f66371538fdc9923ca3bfc78ddfeb937333b3adc19"
  1. Line 5: docker-registry-ui GET docker-registry for the manifest list in response to the first Delete button click event for app_name:4.0.1
  2. Line 8: docker-registry-ui DELETE docker-registry for the digest found in Manifest #1 used for app_name:4.0.1-amd64 instead of the digest for the manifest list
  3. Line 9: docker-registry completes the DELETE command using the digest for app_name:4.0.1-amd64
  4. Line 15: docker-registry-ui GET docker-registry for the manifest list in response to the first Delete button click event for app_name:4.0.1
  5. Line 17: docker-registry fails on the DELETE command using the digest for app_name:4.0.1-amd64 as expected

created time in 2 months

issue openedQuiq/docker-registry-ui

Working kubernetes manifest

Posting this for those that will be looking for something like this. I have a working kubernetes manifest that works with cert-manger and traefik.

Please note to update container/image and config.yml as appropriate. Hope this helps.

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: docker-registry-ui
  namespace: docker-registry
spec:
  replicas: 1
  selector:
    matchLabels:
      name: docker-registry-ui
  template:
    metadata:
      labels:
        name: docker-registry-ui
    spec:
      containers:
        - name: docker-registry-ui
          image: docker-registry.local/cluster/docker-registry-ui
          args:
            - -config-file=/var/docker-registry-ui/config.yml
          resources: {}
          env:
            - name: TZ
              value: America/Los_Angeles
          ports:
            - containerPort: 8000
              protocol: TCP
              name: http
          volumeMounts:
            - mountPath: /opt/data
              name: data
            - mountPath: /var/docker-registry-ui
              name: config
      volumes:
        - name: config
          configMap:
            name: docker-registry-ui-config
        - name: data
          persistentVolumeClaim:
            claimName: docker-registry-ui-data
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: docker-registry-ui-config
  namespace: docker-registry
data:
  config.yml: |-
    # Listen interface.
    listen_addr: 0.0.0.0:8000
    # Base path of Docker Registry UI.
    base_path: /ui

    # Registry URL with schema and port.
    registry_url: https://docker-registry.local
    # Verify TLS certificate when using https.
    verify_tls: true

    # Docker registry credentials.
    # They need to have a full access to the registry.
    # If token authentication service is enabled, it will be auto-discovered and those credentials
    # will be used to obtain access tokens.
    # When the registry_password_file entry is used, the password can be passed as a docker secret
    # and read from file. This overides the registry_password entry.
    # registry_username: user
    # registry_password: pass
    # registry_password_file: /run/secrets/registry_password_file

    # Event listener token.
    # The same one should be configured on Docker registry as Authorization Bearer token.
    event_listener_token: token
    # Retention of records to keep.
    event_retention_days: 7

    # Event listener storage.
    event_database_driver: sqlite3
    event_database_location: data/registry_events.db
    # event_database_driver: mysql
    # event_database_location: user:password@tcp(localhost:3306)/docker_events

    # You can disable event deletion on some hosts when you are running docker-registry on master-master or
    # cluster setup to avoid deadlocks or replication break.
    event_deletion_enabled: True

    # Cache refresh interval in minutes.
    # How long to cache repository list and tag counts.
    cache_refresh_interval: 10

    # If users can delete tags. If set to False, then only admins listed below.
    anyone_can_delete: false
    # Users allowed to delete tags.
    # This should be sent via X-WEBAUTH-USER header from your proxy.
    admins: []

    # Debug mode. Affects only templates.
    debug: true

    # How many days to keep tags but also keep the minimal count provided no matter how old.
    purge_tags_keep_days: 90
    purge_tags_keep_count: 2
    # Enable built-in cron to schedule purging tags in server mode.
    # Empty string disables this feature.
    # Example: '25 54 17 * * *' will run it at 17:54:25 daily.
    # Note, the cron schedule format includes seconds! See https://godoc.org/github.com/robfig/cron
    purge_tags_schedule: ''
---
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: docker-registry-ui-data
  namespace: docker-registry
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi
---
apiVersion: v1
kind: Service
metadata:
  name: docker-registry-ui
  namespace: docker-registry
spec:
  ports:
    - name: http
      port: 80
      targetPort: http
  selector:
    name: docker-registry-ui
  type: ClusterIP
---
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: docker-registry-ui
  namespace: docker-registry
  annotations:
    cert-manager.io/cluster-issuer: letsencrypt-cluster
    traefik.ingress.kubernetes.io/frontend-entry-points: https
spec:
  tls:
    - hosts:
        - docker-registry.local
      secretName: docker-registry.local-cert
  rules:
    - host: docker-registry.local
      http:
        paths:
          - path: /ui
            backend:
              serviceName: docker-registry-ui
              servicePort: http

created time in 3 months

issue openedQuiq/docker-registry-ui

Support showing image details for OCI images in the registry

I'm using the current docker-registry-ui image and Docker registry 2.7.

By default podman builds OCI images. I'm unable to view image details for these images using docker-registry-ui.

To query the manifest from an OCI image in the registry you need to add an Accept header:

curl -k -H "application/vnd.oci.image.manifest.v1+json" https://fir.local:3005/v2/arm32v7
/builder/manifests/latest
{"errors":[{"code":"MANIFEST_UNKNOWN","message":"OCI manifest found, but accept header does not support OCI manifests"}]}
fir ~  > curl -k -H "Accept:application/vnd.oci.image.manifest.v1+json" https://fir.local:3005/v2/
arm32v7/builder/manifests/latest
{"schemaVersion":2,"config":{"mediaType":"application/vnd.oci.image.config.v1+json","digest":"sha256:2c81c9601fbaed4945e96b93c9d22417f869bba3be1758dd1e51bba1eda42ae0","size":1119},"layers":[{"mediaType":"application/vnd.oci.image.layer.v1.tar+gzip","digest":"sha256:a4108b69c3f2a06c303ddfd007e1a739e368de5a337e7dc3c298ba3e454cfb08","size":2455704},{"mediaType":"application/vnd.oci.image.layer.v1.tar+gzip","digest":"sha256:6e9e5cf384fc0ebb51c5ed1f3374762f8a28cfa5c6ee4e9517b29b89ed0ef6be","size":124872615}]}

Workaround is to build the image in docker form: podman --format docker

created time in 3 months

more