In example docker compose, how does "background" talk to the registry?

[kylegoetz]

I am running a docker compose very similar to the example with the DB, portus, portus-in-background, and the registry (plus adminer).

The images I push to the registry succeed, but the Portus UI never reflects the changes. If I log in to the DB with adminer, I can see the images in the registry_events table.

As per the compose file, registry hits the portus container with the webhooks. This explains how the events are showing up in the DB. (And the correct namespace exists in Portus that matches the container's namespace when pushed to the registry.)

My understanding is that you only get the updates if you are running the background process, which ensures the synchronization of registry and DB+Portus.

I am running background as well. However, looking at the compose structure, background depends on portus, but nowhere is portus configured to know about background's existence or URL (which would be http(s)://background:3000 as nginx does not have any mention of background in the config you have for it).

Moreover, background has nothing configured in it to know how to communicate with registry. It depends on the database and portus, but no mention of registry, so how does it ensure the database is synced with the registry?

Is the docker-compose.yml file not set up correctly? Or am I missing something?

[kylegoetz]

Well, the answer appears to be that I needed to put in my docker-compose.yml file under background.environment:

# Sync config
- PORTUS_BACKGROUND_REGISTRY_ENABLED=true
- PORTUS_BACKGROUND_SYNC_ENABLED=true
- PORTUS_BACKGROUND_SYNC_STRATEGY=update

Looks like Portus will only sync with the registry when you first create the containers, but never after that, unless you configure background to sync regularly, which the above does.

I suggest this be added to the example, or an explanation given as to why this is missing, as I can't imagine why anyone would only ever want to import a registry's data on first creation rather than keeping it synced going forward. Is the example just for a read-only demo and no read-write demo?

[Jean-Baptiste-Lasselle]

unless

(All tested on portus 2.4.3)

Hi @kylegoetz Thank you so much for your issue :

• I am currently probably like you, working on building up a real production ready Portus / OCI image registry
• It is the first time I hear about those configuration variables, though I spent days and hours across portus documentation. For example, found a proper way to generate (and rotate) the value of PORTUS_SECRET_KEY_BASE, and it was thrilling, but oh my god, when I think of what was said about that n the doc, I amsosorry for portus first timers... (almost zero, not even the rotate verb or rotation word), cf. this doc page, you Ctrl + F PORTUS_SECRET_KEY_BASE....
• So I am not surprised to learn a new critical aspect of portus, especially important ! . Here worth mentioning, and why I thank you so much, is that your point will greatly help me also unveil the Garbage Collection process, extremely important for production environments.

I do agree with you, on your point, support your request, and there is a real need for even more...

However

I have a setup where none of :

  background: 
    environment:
    # Sync config
      - PORTUS_BACKGROUND_REGISTRY_ENABLED=true
      - PORTUS_BACKGROUND_SYNC_ENABLED=true
      - PORTUS_BACKGROUND_SYNC_STRATEGY=update

are set for the background

Yet, I do have a webui that refreshes when I docker push a new OCI image.

So setting :

  background: 
    environment:
    # Sync config
      - PORTUS_BACKGROUND_REGISTRY_ENABLED=true
      - PORTUS_BACKGROUND_SYNC_ENABLED=true
      - PORTUS_BACKGROUND_SYNC_STRATEGY=update

has no relation with your problem or solves your problem by accident. Indeed :

• Obviously, the solution yo give shows that sync is not activated by default. It has to be "activated" using the variables you mentioned.
• So, do you think it is the way OpenSUSE engineers programmed Portus : by defaults, the WebUI doesn't show any new image pushed to the registry ? I think not, noway ever. But I'm really investigating, and sharing my questioning.

As for your accurate problem, I found such issues caused by things like :

• SSL Certificate and PKI consistency (who trusts who)
• wrong port numbers specified for webhook endpoints in regsitry.yml, or docker-compose.yml

Never the less

I also did wonder how the background service could refresh the portus web app, and what I understood, first, is that it's through the database :

• you docker push a new image
• so registry sends a webhook registry event notification to portus to its endpoint https://PROTUS_SERVICE_NETNAME:3000/v2/webhooks/events (a URL like that)
• portus forwards to background
• backgound updates database,
• portus webapp picks up the updated data and refreshes the webui

But obviously enough as I write now, this flow is weirdo/bizarre (why portus doesn't update database himself ? ), and you remind me of all my tests results :

• I did confirmed that the registry sends the webhook to portus, not background (I changed network name resolution and network aliases in docker-compose.yml, tobe sure)
• it is most likely that the actual flow, with or without sync functionality, actually is :
  • you docker push a new image
  • so registry sends a webhook registry event notification to portus to its (an URL like that) https://PROTUS_SERVICE_NETNAME:3000/v2/webhooks/events endpoint
  • portus web app updates database (I wondered before, if portus delegates the tasks to update database, to background, but I don't have a test suite yet,that will make me sure of it)
  • portus web app refreshes the webui

All in all, thank you so much for this issue, sharing about those env. variables,and I'll read with interest any further comments, add infos, from you.

[Jean-Baptiste-Lasselle]

@kylegoetz honestly, look at https://github.com/SUSE/Portus/issues/2241#issuecomment-586653023 it's crazy :laughing: :rocket: (biiiiiiig thank you)

[Jean-Baptiste-Lasselle]

@kylegoetz about :

why anyone would only ever want to import a registry's data on first creation rather than keeping it synced going forward.

Actually, this is the best business case ever :

• You already have a registry full of many images
• and you want to keep it all, e.g. you just want to switch from harbor to portus.
• Another thank you cause that's one of the most important business case I wanted to fully automate.
• And howdy I think now it's even more interesting : cause now I'm wondering hm, how can scale out that process ? the registry has tens of thousands of images, and we want portus to take control of it all.
• And.... I don't see any rather, between importing an existing registry, and continuously sync . Actually if I imported first,I certainly want to keep it all in sync,don't you?

[Jean-Baptiste-Lasselle]

Hi @kylegoetz I want today give more info, interesting :

• I assumed, given what you were reporting, that the SYNC feature of protus, is disabled by default, so it has to be activated.
• Well it turns out that it's quite the opposite, see https://github.com/SUSE/Portus/issues/2281#issuecomment-587154193

So when you explicitly set your variables, well it did... nothing. So I now even more think that you solved your problem by accident, not by setting those variables you talked about.

I am really interested in any future tests results you'll feedback here.

And I think I can say now, that I characterized a problem with portus documentation, thanks to your issue, see. : https://github.com/SUSE/Portus/issues/2241#issuecomment-586972528

[stale[bot]]

Thanks for all your contributions! This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.