Verdaccio not working as expected after path mapping in a GCE Ingress controller

Describe the bug

At the outset, let me state that I don’t claim to be an expert in Verdaccio, Google Kubernetes Engine or Kubernetes. However, I have spent significant time working through the available resources and I still don’t see what I expect.

I am trying to setup Verdaccio to run in my GKE cluster for use by remote colleagues. I already have my main app running there, so I want to map a path to the Verdaccio port number. I have done this using the GKE Ingress controller. This is the (slightly modified) YAML:

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: ingress
  annotations:
    kubernetes.io/ingress.class: "gce"
    kubernetes.io/ingress.global-static-ip-name: "ip-address"
    networking.gke.io/managed-certificates: "certificate"
    networking.gke.io/v1beta1.FrontendConfig: "ingress-security-config"
spec:
 rules:
    - http:
        paths:
          - path: /*
            backend:
              serviceName: my_service
              servicePort: 5000
          - path: /verdaccio/*
            backend:
              serviceName: verdaccio-service
              servicePort: 4873

I have taken the configuration for the ConfigMap, Deployment, PVC and Service from here.

What I expect to see is that when I go to https://my.domain.com/verdaccio/ that I will see the Verdaccio WebUI. This situation is covered in the reverse proxy setup.

In the configmap I am specifying url_prefix:

url_prefix: /verdaccio/

and in the deployment I am setting the VERDACCIO_PUBLIC_URL:

 env:
    - name: VERDACCIO_PUBLIC_URL
      value: "https://my.domain.com"

I have not done any of the header manipulation mentioned in the reverse proxy setup. Partly because I don’t know how to and partly because this only seems to be necessary to change the path to static assets.

With this configuration, I expect to see the Verdaccio Web UI when I go to https://my.domain.com/verdaccio/, but what I see is JSON and when I look in the logs I can see that a GET request is being made to the npmjs registry and the JSON relates to the return value from that GET request. If I try and publish to the url, again I see that a GET request goes to npmjs.

If I switch Verdaccio to be mapped to the root of my domain (i.e. switch it with my app), then it works as expected, I can login and publish to the service. It is as soon as I change that mapping back that I get this result. I have tried with Verdaccio Docker images for version 5.0.4 and also 4.12, so I think this is not a V5 only issue. I have looked at #2190, but I am not certain that this is the same issue.

To Reproduce On a GKE cluster create a ConfigMap, Deployment, PVC and Service using the examples here.

Configure the ingress controller as shown above to map the Verdaccio port to the path /verdaccio/*

Set the url_prefix in the ConfigMap and the VERDACCIO_PUBLIC_URL in the Deployment as shown above.

Expected behavior

Expect to see the Verdaccio WebUI at the path https://my.domain.com/verdaccio/

Screenshots

Not applicable

Configuration File (cat ~/.config/verdaccio/config.yaml)

This is the YAML for the ConfigMap:

apiVersion: v1
kind: ConfigMap
metadata:
  name: verdaccio
  labels:
    app: verdaccio
data:
  config.yaml: |-
    #
    # This is the config file used for the docker images.
    # It allows all users to do anything, so don't use it on production systems.
    #
    # Do not configure host and port under `listen` in this file
    # as it will be ignored when using docker.
    # see https://github.com/verdaccio/verdaccio/blob/master/wiki/docker.md#docker-and-custom-port-configuration
    #
    # Look here for more config file examples:
    # https://github.com/verdaccio/verdaccio/tree/master/conf
    #
    # path to a directory with all packages
    storage: /verdaccio/storage
    # path to a directory with plugins to include
    plugins: /verdaccio/plugins
    web:
      # WebUI is enabled as default, if you want disable it, just uncomment this line
      enable: true
      title: Verdaccio
    url_prefix: /verdaccio/
    auth:
      htpasswd:
        file: /verdaccio/conf/htpasswd
        # Maximum amount of users allowed to register, defaults to "+infinity".
        # You can set this to -1 to disable registration.
        max_users: -1
    # a list of other known repositories we can talk to
    uplinks:
      npmjs:
        url: https://registry.npmjs.org/
    packages:
      '@*/*':
        # scoped packages
        access: $all
        publish: $authenticated
        proxy: npmjs
      '**':
        # allow all users (including non-authenticated users) to read and
        # publish all packages
        #
        # you can specify usernames/groupnames (depending on your auth plugin)
        # and three keywords: "$all", "$anonymous", "$authenticated"
        access: $all
        # allow all known users to publish packages
        # (anyone can register by default, remember?)
        publish: $authenticated
        # if package is not available locally, proxy requests to 'npmjs' registry
        proxy: npmjs
    # To use `npm audit` uncomment the following section
    middlewares:
      audit:
        enabled: false
    # log settings
    logs:
      - {type: stdout, format: pretty, level: http}
      #- {type: file, path: verdaccio.log, level: info}
  htpasswd: |-
    x1:###
    x2:###

Environment information

VERDACCIO_PUBLIC_URL: "https://my.domain.com"

[RossVertizan]

Thank you, you have confirmed my understanding. Don’t worry about the Ingress stuff, I think this is just a strange way I thought about it. I have an Ingress controller that has three different services hanging off it. All traffic comes in on port 443 (https) and traffic that matches a path of /verdaccio/* in the url gets mapped to port 4873, and in my case traffic that comes in and matches a path of /sio/* gets mapped to port 8083 (just another service you don’t need to know about, but to give the full example) and anything else gets mapped to port 5000. Each of these ports have separate http end points, and using the path as a way of identifying what should go where seems to be the common way of doing it (I’m not aware of other approaches). With the Google Cloud Ingress Controller, the end point receives the full URL, hence the need to be able to tell the app that the URL will look a little different than normal. With Nginx (an alternate Ingress solution), there are options that allow the url_prefix part to be removed so that the app just sees the base URL (domain name).

So, what I see is that the url_prefix does not appear to be being honoured, in that if I have a url_prefix of /verdaccio/, I get details about the Verdaccio package.

If the favicon.ico fix is possible, I’ll take a look at it again, when I can get the deployment to start.

Thanks for your quick answers.

[juanpicado]

My understanding was that if I define url_prefix then the Verdaccio “root” would be found at http://<verdaccio_server>/<url_prefix>, essentially meaning that Verdaccio is in a sub-directory and in order to hit the package query end point I would then need to do http://<verdaccio_server>/<url_prefix>/<packagename>,

As you describes, your thinking is correct at this point. The url_prefix affects fundamentally a way to override the path other than root. I’d omit examples since I’d guess you understand the usage of the property. This property is only useful if you do reverse proxy in your side and only affect the UI (web, js assets, etc…) and the metadata is being returned on fetch a package json (also known as dist field), but does not affect the server itself (https://github.com/verdaccio/verdaccio/pull/963). Even if you add url_prefix the /-/ping still is accessible via root. eg: http://xxx:port/-/ping Here more details https://verdaccio.org/blog/2021/04/14/verdaccio-5-migration-guide#url_prefix-improved-behavior

I map through the ingress controller to a different path that the url_prefix path would effectively be ignored in terms of the operation of Verdaccio.

This is the part I get lost, my understanding of Kubernetes still is a basic level, so I’m afraid I’m not much helpful here.

Anyhow, here I can share https://github.com/verdaccio/charts/issues/63 and https://github.com/verdaccio/charts/issues/62 where the community discuss topics related K8s and Helm, I guess they might help you faster than me.