Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

proxy.ttl not work #4352

Open
yulinor opened this issue May 15, 2024 · 6 comments
Open

proxy.ttl not work #4352

yulinor opened this issue May 15, 2024 · 6 comments

Comments

@yulinor
Copy link

yulinor commented May 15, 2024

Description

deploy a distribution as pull through cache,set proxy.ttl to 1h ,but not work.
Initially, proxy.ttl was set to 48h. After caching some images, the container was deleted and the proxy.ttl was modified to 1h and then a new container was created (the data directory is always mounted on the host).
But after waiting for several hours, the expected automatic cache clearing did not occur. Checking scheduler-state.json found that all cache images, whether cached when starting the service for the first time or cached for the second time, were set to 7 days. Expiration.
The configuration is as follows:

``yaml
version: 0.1
log:
level: debug
fields:
service: registry
environment: development
storage:
filesystem:
rootdirectory: /opt/registry/registry-data
delete:
enabled: true
cache:
blobdescriptor: inmemory
blobdescriptorsize: 10000
maintenance:
uploadpurging:
enabled: true
age: 168h
interval: 24h
dryrun: false
readonly:
enabled: false
proxy:
remoteurl: https://xxxxx
username: xxxx
password: xxxx
ttl: 48h
http:
addr: :5000
secret: ccr.ccs.tencentyun.com
debug:
addr: :5001
prometheus:
enabled: true
path: /metrics
health:
storagedriver:
enabled: true
interval: 10s
threshold: 3
auth:
htpasswd:
realm: basic-realm
path: /opt/registry/auth/htpasswd


```json
"proxmox/image@sha256:13808c22b207b066ef43572e57e4fb8c6172e887dd9a918c089a174a19371b7a": {
		"Key": "proxmox/image@sha256:13808c22b207b066ef43572e57e4fb8c6172e887dd9a918c089a174a19371b7a",
		"ExpiryData": "2024-05-21T11:59:03.590031813Z",
		"EntryType": 0
	},

Reproduce

docker run -itd -p 5000:5000 -p 5001:5001 --name mharbor -v /opt/registry/registry-data:/opt/registry/registry-data -v /opt/registry/auth:/opt/registry/auth -v /opt/registry/config/config.yml:/etc/docker/registry/config.yml registry:2

Expected behavior

The cache image release time should be 1h, not 7 days

registry version

/ # registry -v
registry github.com/docker/distribution 2.8.3

Additional Info

If the ttl takes effect, the first configuration is 48h, and the second time it is changed to 1h to restart the service, then will the first batch of cached images maintain the 48h expiration time, or will they be recalculated with the new ttl to see if they are currently expired or expire after 1h?

@yulinor
Copy link
Author

yulinor commented May 15, 2024

version: 0.1
log:
  level: debug
  fields:
    service: registry
    environment: development
storage:
  filesystem:
    rootdirectory: /opt/registry/registry-data
  delete:
    enabled: true   
  cache:
    blobdescriptor: inmemory
    blobdescriptorsize: 10000
  maintenance:
    uploadpurging:
      enabled: true
      age: 168h
      interval: 24h
      dryrun: false 
    readonly:
      enabled: false   
proxy:
  remoteurl: xxxx
  username: xxxx
  password: xxxx
  ttl: 48h 
http:
  addr: :5000
  secret: xxx
  debug:
    addr: :5001
    prometheus:
        enabled: true
        path: /metrics 
health:
  storagedriver:
    enabled: true
    interval: 10s
    threshold: 3   
auth:
  htpasswd:
    realm: basic-realm
    path: /opt/registry/auth/htpasswd

@yulinor yulinor changed the title proxy.tll not work proxy.ttl not work May 15, 2024
@yulinor
Copy link
Author

yulinor commented May 15, 2024

Use registry:3.0.0-alpha.1 to verify that ttl takes effect, v2.8.3 v2.8.2 fails

@yulinor
Copy link
Author

yulinor commented May 15, 2024

I think v2.8 needs to support the effective ttl, after all, the alpha version cannot be used in the production environment.

@milosgajdos
Copy link
Member

2.8.x is in a maintenance mode and will not be receiving any updates other than security patches and even that until the stable v3 is made. Then the v2 will be marked deprecated completely.

@yulinor
Copy link
Author

yulinor commented May 15, 2024

2.8.x is in a maintenance mode and will not be receiving any updates other than security patches and even that until the stable v3 is made. Then the v2 will be marked deprecated completely.

oh no,,,,
Then I suggest synchronizing this information in the usage documentation.
But it still cannot be accepted that the information in the document is not correct for the stable version.

@yulinor
Copy link
Author

yulinor commented May 15, 2024

2.8.x is in a maintenance mode and will not be receiving any updates other than security patches and even that until the stable v3 is made. Then the v2 will be marked deprecated completely.

image

In addition, the document says that proxy will automatically clean up expired caches, but I found that only the corresponding information will be deleted in scheduler-state.json, and the blobs data will not be deleted. Is there any other configuration adjustment?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants