2014-11-13 23:16:54 +00:00
|
|
|
package storage
|
|
|
|
|
|
|
|
import (
|
|
|
|
"fmt"
|
|
|
|
"path"
|
2014-11-19 22:59:05 +00:00
|
|
|
"strings"
|
2014-11-13 23:16:54 +00:00
|
|
|
|
2016-12-17 00:28:34 +00:00
|
|
|
"github.com/opencontainers/go-digest"
|
2014-11-13 23:16:54 +00:00
|
|
|
)
|
|
|
|
|
2015-08-18 01:51:05 +00:00
|
|
|
const (
|
|
|
|
storagePathVersion = "v2" // fixed storage layout version
|
|
|
|
storagePathRoot = "/docker/registry/" // all driver paths have a prefix
|
|
|
|
|
|
|
|
// TODO(stevvooe): Get rid of the "storagePathRoot". Initially, we though
|
|
|
|
// storage path root would configurable for all drivers through this
|
|
|
|
// package. In reality, we've found it simpler to do this on a per driver
|
|
|
|
// basis.
|
|
|
|
)
|
2014-11-13 23:16:54 +00:00
|
|
|
|
2015-08-18 01:51:05 +00:00
|
|
|
// pathFor maps paths based on "object names" and their ids. The "object
|
|
|
|
// names" mapped by are internal to the storage system.
|
2014-11-13 23:16:54 +00:00
|
|
|
//
|
2015-01-14 19:34:47 +00:00
|
|
|
// The path layout in the storage backend is roughly as follows:
|
2014-11-13 23:16:54 +00:00
|
|
|
//
|
2022-11-02 21:05:45 +00:00
|
|
|
// <root>/v2
|
2023-08-30 14:36:14 +00:00
|
|
|
// ├── blobs
|
2022-11-02 21:05:45 +00:00
|
|
|
// │ └── <algorithm>
|
|
|
|
// │ └── <split directory content addressable storage>
|
|
|
|
// └── repositories
|
|
|
|
// └── <name>
|
|
|
|
// ├── _layers
|
|
|
|
// │ └── <layer links to blob store>
|
|
|
|
// ├── _manifests
|
|
|
|
// │ ├── revisions
|
|
|
|
// │ │ └── <manifest digest path>
|
|
|
|
// │ │ └── link
|
|
|
|
// │ └── tags
|
|
|
|
// │ └── <tag>
|
|
|
|
// │ ├── current
|
|
|
|
// │ │ └── link
|
|
|
|
// │ └── index
|
|
|
|
// │ └── <algorithm>
|
|
|
|
// │ └── <hex digest>
|
|
|
|
// │ └── link
|
|
|
|
// └── _uploads
|
|
|
|
// └── <id>
|
|
|
|
// ├── data
|
|
|
|
// ├── hashstates
|
|
|
|
// │ └── <algorithm>
|
|
|
|
// │ └── <offset>
|
|
|
|
// └── startedat
|
2014-11-13 23:16:54 +00:00
|
|
|
//
|
2015-08-18 01:51:05 +00:00
|
|
|
// The storage backend layout is broken up into a content-addressable blob
|
2015-01-14 19:34:47 +00:00
|
|
|
// store and repositories. The content-addressable blob store holds most data
|
|
|
|
// throughout the backend, keyed by algorithm and digests of the underlying
|
2016-02-11 00:26:29 +00:00
|
|
|
// content. Access to the blob store is controlled through links from the
|
2015-01-14 19:34:47 +00:00
|
|
|
// repository to blobstore.
|
|
|
|
//
|
|
|
|
// A repository is made up of layers, manifests and tags. The layers component
|
|
|
|
// is just a directory of layers which are "linked" into a repository. A layer
|
|
|
|
// can only be accessed through a qualified repository name if it is linked in
|
|
|
|
// the repository. Uploads of layers are managed in the uploads directory,
|
Refactor Blob Service API
This PR refactors the blob service API to be oriented around blob descriptors.
Identified by digests, blobs become an abstract entity that can be read and
written using a descriptor as a handle. This allows blobs to take many forms,
such as a ReadSeekCloser or a simple byte buffer, allowing blob oriented
operations to better integrate with blob agnostic APIs (such as the `io`
package). The error definitions are now better organized to reflect conditions
that can only be seen when interacting with the blob API.
The main benefit of this is to separate the much smaller metadata from large
file storage. Many benefits also follow from this. Reading and writing has
been separated into discrete services. Backend implementation is also
simplified, by reducing the amount of metadata that needs to be picked up to
simply serve a read. This also improves cacheability.
"Opening" a blob simply consists of an access check (Stat) and a path
calculation. Caching is greatly simplified and we've made the mapping of
provisional to canonical hashes a first-class concept. BlobDescriptorService
and BlobProvider can be combined in different ways to achieve varying effects.
Recommend Review Approach
-------------------------
This is a very large patch. While apologies are in order, we are getting a
considerable amount of refactoring. Most changes follow from the changes to
the root package (distribution), so start there. From there, the main changes
are in storage. Looking at (*repository).Blobs will help to understand the how
the linkedBlobStore is wired. One can explore the internals within and also
branch out into understanding the changes to the caching layer. Following the
descriptions below will also help to guide you.
To reduce the chances for regressions, it was critical that major changes to
unit tests were avoided. Where possible, they are left untouched and where
not, the spirit is hopefully captured. Pay particular attention to where
behavior may have changed.
Storage
-------
The primary changes to the `storage` package, other than the interface
updates, were to merge the layerstore and blobstore. Blob access is now
layered even further. The first layer, blobStore, exposes a global
`BlobStatter` and `BlobProvider`. Operations here provide a fast path for most
read operations that don't take access control into account. The
`linkedBlobStore` layers on top of the `blobStore`, providing repository-
scoped blob link management in the backend. The `linkedBlobStore` implements
the full `BlobStore` suite, providing access-controlled, repository-local blob
writers. The abstraction between the two is slightly broken in that
`linkedBlobStore` is the only channel under which one can write into the global
blob store. The `linkedBlobStore` also provides flexibility in that it can act
over different link sets depending on configuration. This allows us to use the
same code for signature links, manifest links and blob links. Eventually, we
will fully consolidate this storage.
The improved cache flow comes from the `linkedBlobStatter` component
of `linkedBlobStore`. Using a `cachedBlobStatter`, these combine together to
provide a simple cache hierarchy that should streamline access checks on read
and write operations, or at least provide a single path to optimize. The
metrics have been changed in a slightly incompatible way since the former
operations, Fetch and Exists, are no longer relevant.
The fileWriter and fileReader have been slightly modified to support the rest
of the changes. The most interesting is the removal of the `Stat` call from
`newFileReader`. This was the source of unnecessary round trips that were only
present to look up the size of the resulting reader. Now, one must simply pass
in the size, requiring the caller to decide whether or not the `Stat` call is
appropriate. In several cases, it turned out the caller already had the size
already. The `WriterAt` implementation has been removed from `fileWriter`,
since it is no longer required for `BlobWriter`, reducing the number of paths
which writes may take.
Cache
-----
Unfortunately, the `cache` package required a near full rewrite. It was pretty
mechanical in that the cache is oriented around the `BlobDescriptorService`
slightly modified to include the ability to set the values for individual
digests. While the implementation is oriented towards caching, it can act as a
primary store. Provisions are in place to have repository local metadata, in
addition to global metadata. Fallback is implemented as a part of the storage
package to maintain this flexibility.
One unfortunate side-effect is that caching is now repository-scoped, rather
than global. This should have little effect on performance but may increase
memory usage.
Handlers
--------
The `handlers` package has been updated to leverage the new API. For the most
part, the changes are superficial or mechanical based on the API changes. This
did expose a bug in the handling of provisional vs canonical digests that was
fixed in the unit tests.
Configuration
-------------
One user-facing change has been made to the configuration and is updated in
the associated documentation. The `layerinfo` cache parameter has been
deprecated by the `blobdescriptor` cache parameter. Both are equivalent and
configuration files should be backward compatible.
Notifications
-------------
Changes the `notification` package are simply to support the interface
changes.
Context
-------
A small change has been made to the tracing log-level. Traces have been moved
from "info" to "debug" level to reduce output when not needed.
Signed-off-by: Stephen J Day <stephen.day@docker.com>
2015-05-12 07:10:29 +00:00
|
|
|
// which is key by upload id. When all data for an upload is received, the
|
2015-01-14 19:34:47 +00:00
|
|
|
// data is moved into the blob store and the upload directory is deleted.
|
|
|
|
// Abandoned uploads can be garbage collected by reading the startedat file
|
|
|
|
// and removing uploads that have been active for longer than a certain time.
|
|
|
|
//
|
|
|
|
// The third component of the repository directory is the manifests store,
|
|
|
|
// which is made up of a revision store and tag store. Manifests are stored in
|
2016-04-07 00:01:30 +00:00
|
|
|
// the blob store and linked into the revision store.
|
2015-01-14 19:34:47 +00:00
|
|
|
// While the registry can save all revisions of a manifest, no relationship is
|
|
|
|
// implied as to the ordering of changes to a manifest. The tag store provides
|
|
|
|
// support for name, tag lookups of manifests, using "current/link" under a
|
|
|
|
// named tag directory. An index is maintained to support deletions of all
|
|
|
|
// revisions of a given manifest tag.
|
2014-11-13 23:16:54 +00:00
|
|
|
//
|
|
|
|
// We cover the path formats implemented by this path mapper below.
|
|
|
|
//
|
2023-09-26 07:07:49 +00:00
|
|
|
// Repositories:
|
|
|
|
//
|
|
|
|
// repositoriesRootPathSpec: <root>/v2/repositories
|
|
|
|
//
|
2015-01-14 19:34:47 +00:00
|
|
|
// Manifests:
|
|
|
|
//
|
2022-07-10 02:04:50 +00:00
|
|
|
// manifestsPathSpec: <root>/v2/repositories/<name>/_manifests
|
|
|
|
// manifestRevisionsPathSpec: <root>/v2/repositories/<name>/_manifests/revisions/
|
2022-11-02 21:05:45 +00:00
|
|
|
// manifestRevisionPathSpec: <root>/v2/repositories/<name>/_manifests/revisions/<algorithm>/<hex digest>/
|
|
|
|
// manifestRevisionLinkPathSpec: <root>/v2/repositories/<name>/_manifests/revisions/<algorithm>/<hex digest>/link
|
2015-01-14 19:34:47 +00:00
|
|
|
//
|
|
|
|
// Tags:
|
|
|
|
//
|
2022-11-02 21:05:45 +00:00
|
|
|
// manifestTagsPathSpec: <root>/v2/repositories/<name>/_manifests/tags/
|
|
|
|
// manifestTagPathSpec: <root>/v2/repositories/<name>/_manifests/tags/<tag>/
|
|
|
|
// manifestTagCurrentPathSpec: <root>/v2/repositories/<name>/_manifests/tags/<tag>/current/link
|
|
|
|
// manifestTagIndexPathSpec: <root>/v2/repositories/<name>/_manifests/tags/<tag>/index/
|
|
|
|
// manifestTagIndexEntryPathSpec: <root>/v2/repositories/<name>/_manifests/tags/<tag>/index/<algorithm>/<hex digest>/
|
|
|
|
// manifestTagIndexEntryLinkPathSpec: <root>/v2/repositories/<name>/_manifests/tags/<tag>/index/<algorithm>/<hex digest>/link
|
2015-01-14 19:34:47 +00:00
|
|
|
//
|
2022-11-02 21:05:45 +00:00
|
|
|
// Blobs:
|
2015-01-14 19:34:47 +00:00
|
|
|
//
|
2022-11-02 21:05:45 +00:00
|
|
|
// layerLinkPathSpec: <root>/v2/repositories/<name>/_layers/<algorithm>/<hex digest>/link
|
|
|
|
// layersPathSpec: <root>/v2/repositories/<name>/_layers
|
2015-01-14 19:34:47 +00:00
|
|
|
//
|
|
|
|
// Uploads:
|
|
|
|
//
|
2022-11-02 21:05:45 +00:00
|
|
|
// uploadDataPathSpec: <root>/v2/repositories/<name>/_uploads/<id>/data
|
|
|
|
// uploadStartedAtPathSpec: <root>/v2/repositories/<name>/_uploads/<id>/startedat
|
|
|
|
// uploadHashStatePathSpec: <root>/v2/repositories/<name>/_uploads/<id>/hashstates/<algorithm>/<offset>
|
2015-01-14 19:34:47 +00:00
|
|
|
//
|
|
|
|
// Blob Store:
|
|
|
|
//
|
2016-01-19 22:26:15 +00:00
|
|
|
// blobsPathSpec: <root>/v2/blobs/
|
2022-11-02 21:05:45 +00:00
|
|
|
// blobPathSpec: <root>/v2/blobs/<algorithm>/<first two hex bytes of digest>/<hex digest>
|
|
|
|
// blobDataPathSpec: <root>/v2/blobs/<algorithm>/<first two hex bytes of digest>/<hex digest>/data
|
2014-11-13 23:16:54 +00:00
|
|
|
//
|
|
|
|
// For more information on the semantic meaning of each path and their
|
|
|
|
// contents, please see the path spec documentation.
|
2015-08-18 01:51:05 +00:00
|
|
|
func pathFor(spec pathSpec) (string, error) {
|
2014-11-13 23:16:54 +00:00
|
|
|
// Switch on the path object type and return the appropriate path. At
|
|
|
|
// first glance, one may wonder why we don't use an interface to
|
|
|
|
// accomplish this. By keep the formatting separate from the pathSpec, we
|
|
|
|
// keep separate the path generation componentized. These specs could be
|
|
|
|
// passed to a completely different mapper implementation and generate a
|
|
|
|
// different set of paths.
|
|
|
|
//
|
|
|
|
// For example, imagine migrating from one backend to the other: one could
|
|
|
|
// build a filesystem walker that converts a string path in one version,
|
|
|
|
// to an intermediate path object, than can be consumed and mapped by the
|
|
|
|
// other version.
|
|
|
|
|
2015-08-18 01:51:05 +00:00
|
|
|
rootPrefix := []string{storagePathRoot, storagePathVersion}
|
2014-11-22 01:04:35 +00:00
|
|
|
repoPrefix := append(rootPrefix, "repositories")
|
|
|
|
|
2014-11-13 23:16:54 +00:00
|
|
|
switch v := spec.(type) {
|
2015-01-14 19:34:47 +00:00
|
|
|
|
2022-07-10 02:04:50 +00:00
|
|
|
case manifestsPathSpec:
|
|
|
|
return path.Join(append(repoPrefix, v.name, "_manifests")...), nil
|
|
|
|
|
2016-01-19 22:26:15 +00:00
|
|
|
case manifestRevisionsPathSpec:
|
|
|
|
return path.Join(append(repoPrefix, v.name, "_manifests", "revisions")...), nil
|
|
|
|
|
2015-01-14 19:34:47 +00:00
|
|
|
case manifestRevisionPathSpec:
|
|
|
|
components, err := digestPathComponents(v.revision, false)
|
2014-11-13 23:16:54 +00:00
|
|
|
if err != nil {
|
|
|
|
return "", err
|
|
|
|
}
|
|
|
|
|
2015-02-02 21:17:33 +00:00
|
|
|
return path.Join(append(append(repoPrefix, v.name, "_manifests", "revisions"), components...)...), nil
|
2015-01-14 19:34:47 +00:00
|
|
|
case manifestRevisionLinkPathSpec:
|
2019-02-05 00:01:04 +00:00
|
|
|
root, err := pathFor(manifestRevisionPathSpec(v))
|
2015-01-14 19:34:47 +00:00
|
|
|
if err != nil {
|
|
|
|
return "", err
|
2014-11-19 22:39:32 +00:00
|
|
|
}
|
|
|
|
|
2015-01-14 19:34:47 +00:00
|
|
|
return path.Join(root, "link"), nil
|
|
|
|
case manifestTagsPathSpec:
|
2015-02-02 21:17:33 +00:00
|
|
|
return path.Join(append(repoPrefix, v.name, "_manifests", "tags")...), nil
|
2015-01-14 19:34:47 +00:00
|
|
|
case manifestTagPathSpec:
|
2015-08-18 01:51:05 +00:00
|
|
|
root, err := pathFor(manifestTagsPathSpec{
|
2015-01-14 19:34:47 +00:00
|
|
|
name: v.name,
|
|
|
|
})
|
|
|
|
if err != nil {
|
|
|
|
return "", err
|
|
|
|
}
|
|
|
|
|
|
|
|
return path.Join(root, v.tag), nil
|
|
|
|
case manifestTagCurrentPathSpec:
|
2019-02-05 00:01:04 +00:00
|
|
|
root, err := pathFor(manifestTagPathSpec(v))
|
2015-01-14 19:34:47 +00:00
|
|
|
if err != nil {
|
|
|
|
return "", err
|
|
|
|
}
|
|
|
|
|
2015-01-14 20:02:43 +00:00
|
|
|
return path.Join(root, "current", "link"), nil
|
2015-01-14 19:34:47 +00:00
|
|
|
case manifestTagIndexPathSpec:
|
2019-02-05 00:01:04 +00:00
|
|
|
root, err := pathFor(manifestTagPathSpec(v))
|
2015-01-14 19:34:47 +00:00
|
|
|
if err != nil {
|
|
|
|
return "", err
|
|
|
|
}
|
|
|
|
|
|
|
|
return path.Join(root, "index"), nil
|
2015-02-26 23:47:04 +00:00
|
|
|
case manifestTagIndexEntryLinkPathSpec:
|
2019-02-05 00:01:04 +00:00
|
|
|
root, err := pathFor(manifestTagIndexEntryPathSpec(v))
|
2015-02-26 23:47:04 +00:00
|
|
|
if err != nil {
|
|
|
|
return "", err
|
|
|
|
}
|
|
|
|
|
|
|
|
return path.Join(root, "link"), nil
|
2015-01-14 19:34:47 +00:00
|
|
|
case manifestTagIndexEntryPathSpec:
|
2015-08-18 01:51:05 +00:00
|
|
|
root, err := pathFor(manifestTagIndexPathSpec{
|
2015-01-14 19:34:47 +00:00
|
|
|
name: v.name,
|
|
|
|
tag: v.tag,
|
|
|
|
})
|
|
|
|
if err != nil {
|
|
|
|
return "", err
|
|
|
|
}
|
|
|
|
|
|
|
|
components, err := digestPathComponents(v.revision, false)
|
|
|
|
if err != nil {
|
|
|
|
return "", err
|
|
|
|
}
|
2014-11-13 23:16:54 +00:00
|
|
|
|
2015-02-26 23:47:04 +00:00
|
|
|
return path.Join(root, path.Join(components...)), nil
|
2015-01-14 19:34:47 +00:00
|
|
|
case layerLinkPathSpec:
|
|
|
|
components, err := digestPathComponents(v.digest, false)
|
2014-11-13 23:16:54 +00:00
|
|
|
if err != nil {
|
|
|
|
return "", err
|
|
|
|
}
|
|
|
|
|
Refactor Blob Service API
This PR refactors the blob service API to be oriented around blob descriptors.
Identified by digests, blobs become an abstract entity that can be read and
written using a descriptor as a handle. This allows blobs to take many forms,
such as a ReadSeekCloser or a simple byte buffer, allowing blob oriented
operations to better integrate with blob agnostic APIs (such as the `io`
package). The error definitions are now better organized to reflect conditions
that can only be seen when interacting with the blob API.
The main benefit of this is to separate the much smaller metadata from large
file storage. Many benefits also follow from this. Reading and writing has
been separated into discrete services. Backend implementation is also
simplified, by reducing the amount of metadata that needs to be picked up to
simply serve a read. This also improves cacheability.
"Opening" a blob simply consists of an access check (Stat) and a path
calculation. Caching is greatly simplified and we've made the mapping of
provisional to canonical hashes a first-class concept. BlobDescriptorService
and BlobProvider can be combined in different ways to achieve varying effects.
Recommend Review Approach
-------------------------
This is a very large patch. While apologies are in order, we are getting a
considerable amount of refactoring. Most changes follow from the changes to
the root package (distribution), so start there. From there, the main changes
are in storage. Looking at (*repository).Blobs will help to understand the how
the linkedBlobStore is wired. One can explore the internals within and also
branch out into understanding the changes to the caching layer. Following the
descriptions below will also help to guide you.
To reduce the chances for regressions, it was critical that major changes to
unit tests were avoided. Where possible, they are left untouched and where
not, the spirit is hopefully captured. Pay particular attention to where
behavior may have changed.
Storage
-------
The primary changes to the `storage` package, other than the interface
updates, were to merge the layerstore and blobstore. Blob access is now
layered even further. The first layer, blobStore, exposes a global
`BlobStatter` and `BlobProvider`. Operations here provide a fast path for most
read operations that don't take access control into account. The
`linkedBlobStore` layers on top of the `blobStore`, providing repository-
scoped blob link management in the backend. The `linkedBlobStore` implements
the full `BlobStore` suite, providing access-controlled, repository-local blob
writers. The abstraction between the two is slightly broken in that
`linkedBlobStore` is the only channel under which one can write into the global
blob store. The `linkedBlobStore` also provides flexibility in that it can act
over different link sets depending on configuration. This allows us to use the
same code for signature links, manifest links and blob links. Eventually, we
will fully consolidate this storage.
The improved cache flow comes from the `linkedBlobStatter` component
of `linkedBlobStore`. Using a `cachedBlobStatter`, these combine together to
provide a simple cache hierarchy that should streamline access checks on read
and write operations, or at least provide a single path to optimize. The
metrics have been changed in a slightly incompatible way since the former
operations, Fetch and Exists, are no longer relevant.
The fileWriter and fileReader have been slightly modified to support the rest
of the changes. The most interesting is the removal of the `Stat` call from
`newFileReader`. This was the source of unnecessary round trips that were only
present to look up the size of the resulting reader. Now, one must simply pass
in the size, requiring the caller to decide whether or not the `Stat` call is
appropriate. In several cases, it turned out the caller already had the size
already. The `WriterAt` implementation has been removed from `fileWriter`,
since it is no longer required for `BlobWriter`, reducing the number of paths
which writes may take.
Cache
-----
Unfortunately, the `cache` package required a near full rewrite. It was pretty
mechanical in that the cache is oriented around the `BlobDescriptorService`
slightly modified to include the ability to set the values for individual
digests. While the implementation is oriented towards caching, it can act as a
primary store. Provisions are in place to have repository local metadata, in
addition to global metadata. Fallback is implemented as a part of the storage
package to maintain this flexibility.
One unfortunate side-effect is that caching is now repository-scoped, rather
than global. This should have little effect on performance but may increase
memory usage.
Handlers
--------
The `handlers` package has been updated to leverage the new API. For the most
part, the changes are superficial or mechanical based on the API changes. This
did expose a bug in the handling of provisional vs canonical digests that was
fixed in the unit tests.
Configuration
-------------
One user-facing change has been made to the configuration and is updated in
the associated documentation. The `layerinfo` cache parameter has been
deprecated by the `blobdescriptor` cache parameter. Both are equivalent and
configuration files should be backward compatible.
Notifications
-------------
Changes the `notification` package are simply to support the interface
changes.
Context
-------
A small change has been made to the tracing log-level. Traces have been moved
from "info" to "debug" level to reduce output when not needed.
Signed-off-by: Stephen J Day <stephen.day@docker.com>
2015-05-12 07:10:29 +00:00
|
|
|
// TODO(stevvooe): Right now, all blobs are linked under "_layers". If
|
|
|
|
// we have future migrations, we may want to rename this to "_blobs".
|
|
|
|
// A migration strategy would simply leave existing items in place and
|
|
|
|
// write the new paths, commit a file then delete the old files.
|
2015-01-14 19:34:47 +00:00
|
|
|
|
Refactor Blob Service API
This PR refactors the blob service API to be oriented around blob descriptors.
Identified by digests, blobs become an abstract entity that can be read and
written using a descriptor as a handle. This allows blobs to take many forms,
such as a ReadSeekCloser or a simple byte buffer, allowing blob oriented
operations to better integrate with blob agnostic APIs (such as the `io`
package). The error definitions are now better organized to reflect conditions
that can only be seen when interacting with the blob API.
The main benefit of this is to separate the much smaller metadata from large
file storage. Many benefits also follow from this. Reading and writing has
been separated into discrete services. Backend implementation is also
simplified, by reducing the amount of metadata that needs to be picked up to
simply serve a read. This also improves cacheability.
"Opening" a blob simply consists of an access check (Stat) and a path
calculation. Caching is greatly simplified and we've made the mapping of
provisional to canonical hashes a first-class concept. BlobDescriptorService
and BlobProvider can be combined in different ways to achieve varying effects.
Recommend Review Approach
-------------------------
This is a very large patch. While apologies are in order, we are getting a
considerable amount of refactoring. Most changes follow from the changes to
the root package (distribution), so start there. From there, the main changes
are in storage. Looking at (*repository).Blobs will help to understand the how
the linkedBlobStore is wired. One can explore the internals within and also
branch out into understanding the changes to the caching layer. Following the
descriptions below will also help to guide you.
To reduce the chances for regressions, it was critical that major changes to
unit tests were avoided. Where possible, they are left untouched and where
not, the spirit is hopefully captured. Pay particular attention to where
behavior may have changed.
Storage
-------
The primary changes to the `storage` package, other than the interface
updates, were to merge the layerstore and blobstore. Blob access is now
layered even further. The first layer, blobStore, exposes a global
`BlobStatter` and `BlobProvider`. Operations here provide a fast path for most
read operations that don't take access control into account. The
`linkedBlobStore` layers on top of the `blobStore`, providing repository-
scoped blob link management in the backend. The `linkedBlobStore` implements
the full `BlobStore` suite, providing access-controlled, repository-local blob
writers. The abstraction between the two is slightly broken in that
`linkedBlobStore` is the only channel under which one can write into the global
blob store. The `linkedBlobStore` also provides flexibility in that it can act
over different link sets depending on configuration. This allows us to use the
same code for signature links, manifest links and blob links. Eventually, we
will fully consolidate this storage.
The improved cache flow comes from the `linkedBlobStatter` component
of `linkedBlobStore`. Using a `cachedBlobStatter`, these combine together to
provide a simple cache hierarchy that should streamline access checks on read
and write operations, or at least provide a single path to optimize. The
metrics have been changed in a slightly incompatible way since the former
operations, Fetch and Exists, are no longer relevant.
The fileWriter and fileReader have been slightly modified to support the rest
of the changes. The most interesting is the removal of the `Stat` call from
`newFileReader`. This was the source of unnecessary round trips that were only
present to look up the size of the resulting reader. Now, one must simply pass
in the size, requiring the caller to decide whether or not the `Stat` call is
appropriate. In several cases, it turned out the caller already had the size
already. The `WriterAt` implementation has been removed from `fileWriter`,
since it is no longer required for `BlobWriter`, reducing the number of paths
which writes may take.
Cache
-----
Unfortunately, the `cache` package required a near full rewrite. It was pretty
mechanical in that the cache is oriented around the `BlobDescriptorService`
slightly modified to include the ability to set the values for individual
digests. While the implementation is oriented towards caching, it can act as a
primary store. Provisions are in place to have repository local metadata, in
addition to global metadata. Fallback is implemented as a part of the storage
package to maintain this flexibility.
One unfortunate side-effect is that caching is now repository-scoped, rather
than global. This should have little effect on performance but may increase
memory usage.
Handlers
--------
The `handlers` package has been updated to leverage the new API. For the most
part, the changes are superficial or mechanical based on the API changes. This
did expose a bug in the handling of provisional vs canonical digests that was
fixed in the unit tests.
Configuration
-------------
One user-facing change has been made to the configuration and is updated in
the associated documentation. The `layerinfo` cache parameter has been
deprecated by the `blobdescriptor` cache parameter. Both are equivalent and
configuration files should be backward compatible.
Notifications
-------------
Changes the `notification` package are simply to support the interface
changes.
Context
-------
A small change has been made to the tracing log-level. Traces have been moved
from "info" to "debug" level to reduce output when not needed.
Signed-off-by: Stephen J Day <stephen.day@docker.com>
2015-05-12 07:10:29 +00:00
|
|
|
blobLinkPathComponents := append(repoPrefix, v.name, "_layers")
|
|
|
|
|
|
|
|
return path.Join(path.Join(append(blobLinkPathComponents, components...)...), "link"), nil
|
2018-11-02 01:24:16 +00:00
|
|
|
case layersPathSpec:
|
2018-11-02 01:35:32 +00:00
|
|
|
return path.Join(append(repoPrefix, v.name, "_layers")...), nil
|
2016-01-19 22:26:15 +00:00
|
|
|
case blobsPathSpec:
|
|
|
|
blobsPathPrefix := append(rootPrefix, "blobs")
|
|
|
|
return path.Join(blobsPathPrefix...), nil
|
|
|
|
case blobPathSpec:
|
|
|
|
components, err := digestPathComponents(v.digest, true)
|
|
|
|
if err != nil {
|
|
|
|
return "", err
|
|
|
|
}
|
|
|
|
|
|
|
|
blobPathPrefix := append(rootPrefix, "blobs")
|
|
|
|
return path.Join(append(blobPathPrefix, components...)...), nil
|
2015-01-14 19:34:47 +00:00
|
|
|
case blobDataPathSpec:
|
|
|
|
components, err := digestPathComponents(v.digest, true)
|
|
|
|
if err != nil {
|
|
|
|
return "", err
|
|
|
|
}
|
|
|
|
|
|
|
|
components = append(components, "data")
|
|
|
|
blobPathPrefix := append(rootPrefix, "blobs")
|
2014-11-25 00:21:02 +00:00
|
|
|
return path.Join(append(blobPathPrefix, components...)...), nil
|
2015-01-14 19:34:47 +00:00
|
|
|
|
2015-01-08 22:10:08 +00:00
|
|
|
case uploadDataPathSpec:
|
Refactor Blob Service API
This PR refactors the blob service API to be oriented around blob descriptors.
Identified by digests, blobs become an abstract entity that can be read and
written using a descriptor as a handle. This allows blobs to take many forms,
such as a ReadSeekCloser or a simple byte buffer, allowing blob oriented
operations to better integrate with blob agnostic APIs (such as the `io`
package). The error definitions are now better organized to reflect conditions
that can only be seen when interacting with the blob API.
The main benefit of this is to separate the much smaller metadata from large
file storage. Many benefits also follow from this. Reading and writing has
been separated into discrete services. Backend implementation is also
simplified, by reducing the amount of metadata that needs to be picked up to
simply serve a read. This also improves cacheability.
"Opening" a blob simply consists of an access check (Stat) and a path
calculation. Caching is greatly simplified and we've made the mapping of
provisional to canonical hashes a first-class concept. BlobDescriptorService
and BlobProvider can be combined in different ways to achieve varying effects.
Recommend Review Approach
-------------------------
This is a very large patch. While apologies are in order, we are getting a
considerable amount of refactoring. Most changes follow from the changes to
the root package (distribution), so start there. From there, the main changes
are in storage. Looking at (*repository).Blobs will help to understand the how
the linkedBlobStore is wired. One can explore the internals within and also
branch out into understanding the changes to the caching layer. Following the
descriptions below will also help to guide you.
To reduce the chances for regressions, it was critical that major changes to
unit tests were avoided. Where possible, they are left untouched and where
not, the spirit is hopefully captured. Pay particular attention to where
behavior may have changed.
Storage
-------
The primary changes to the `storage` package, other than the interface
updates, were to merge the layerstore and blobstore. Blob access is now
layered even further. The first layer, blobStore, exposes a global
`BlobStatter` and `BlobProvider`. Operations here provide a fast path for most
read operations that don't take access control into account. The
`linkedBlobStore` layers on top of the `blobStore`, providing repository-
scoped blob link management in the backend. The `linkedBlobStore` implements
the full `BlobStore` suite, providing access-controlled, repository-local blob
writers. The abstraction between the two is slightly broken in that
`linkedBlobStore` is the only channel under which one can write into the global
blob store. The `linkedBlobStore` also provides flexibility in that it can act
over different link sets depending on configuration. This allows us to use the
same code for signature links, manifest links and blob links. Eventually, we
will fully consolidate this storage.
The improved cache flow comes from the `linkedBlobStatter` component
of `linkedBlobStore`. Using a `cachedBlobStatter`, these combine together to
provide a simple cache hierarchy that should streamline access checks on read
and write operations, or at least provide a single path to optimize. The
metrics have been changed in a slightly incompatible way since the former
operations, Fetch and Exists, are no longer relevant.
The fileWriter and fileReader have been slightly modified to support the rest
of the changes. The most interesting is the removal of the `Stat` call from
`newFileReader`. This was the source of unnecessary round trips that were only
present to look up the size of the resulting reader. Now, one must simply pass
in the size, requiring the caller to decide whether or not the `Stat` call is
appropriate. In several cases, it turned out the caller already had the size
already. The `WriterAt` implementation has been removed from `fileWriter`,
since it is no longer required for `BlobWriter`, reducing the number of paths
which writes may take.
Cache
-----
Unfortunately, the `cache` package required a near full rewrite. It was pretty
mechanical in that the cache is oriented around the `BlobDescriptorService`
slightly modified to include the ability to set the values for individual
digests. While the implementation is oriented towards caching, it can act as a
primary store. Provisions are in place to have repository local metadata, in
addition to global metadata. Fallback is implemented as a part of the storage
package to maintain this flexibility.
One unfortunate side-effect is that caching is now repository-scoped, rather
than global. This should have little effect on performance but may increase
memory usage.
Handlers
--------
The `handlers` package has been updated to leverage the new API. For the most
part, the changes are superficial or mechanical based on the API changes. This
did expose a bug in the handling of provisional vs canonical digests that was
fixed in the unit tests.
Configuration
-------------
One user-facing change has been made to the configuration and is updated in
the associated documentation. The `layerinfo` cache parameter has been
deprecated by the `blobdescriptor` cache parameter. Both are equivalent and
configuration files should be backward compatible.
Notifications
-------------
Changes the `notification` package are simply to support the interface
changes.
Context
-------
A small change has been made to the tracing log-level. Traces have been moved
from "info" to "debug" level to reduce output when not needed.
Signed-off-by: Stephen J Day <stephen.day@docker.com>
2015-05-12 07:10:29 +00:00
|
|
|
return path.Join(append(repoPrefix, v.name, "_uploads", v.id, "data")...), nil
|
2015-01-08 22:10:08 +00:00
|
|
|
case uploadStartedAtPathSpec:
|
Refactor Blob Service API
This PR refactors the blob service API to be oriented around blob descriptors.
Identified by digests, blobs become an abstract entity that can be read and
written using a descriptor as a handle. This allows blobs to take many forms,
such as a ReadSeekCloser or a simple byte buffer, allowing blob oriented
operations to better integrate with blob agnostic APIs (such as the `io`
package). The error definitions are now better organized to reflect conditions
that can only be seen when interacting with the blob API.
The main benefit of this is to separate the much smaller metadata from large
file storage. Many benefits also follow from this. Reading and writing has
been separated into discrete services. Backend implementation is also
simplified, by reducing the amount of metadata that needs to be picked up to
simply serve a read. This also improves cacheability.
"Opening" a blob simply consists of an access check (Stat) and a path
calculation. Caching is greatly simplified and we've made the mapping of
provisional to canonical hashes a first-class concept. BlobDescriptorService
and BlobProvider can be combined in different ways to achieve varying effects.
Recommend Review Approach
-------------------------
This is a very large patch. While apologies are in order, we are getting a
considerable amount of refactoring. Most changes follow from the changes to
the root package (distribution), so start there. From there, the main changes
are in storage. Looking at (*repository).Blobs will help to understand the how
the linkedBlobStore is wired. One can explore the internals within and also
branch out into understanding the changes to the caching layer. Following the
descriptions below will also help to guide you.
To reduce the chances for regressions, it was critical that major changes to
unit tests were avoided. Where possible, they are left untouched and where
not, the spirit is hopefully captured. Pay particular attention to where
behavior may have changed.
Storage
-------
The primary changes to the `storage` package, other than the interface
updates, were to merge the layerstore and blobstore. Blob access is now
layered even further. The first layer, blobStore, exposes a global
`BlobStatter` and `BlobProvider`. Operations here provide a fast path for most
read operations that don't take access control into account. The
`linkedBlobStore` layers on top of the `blobStore`, providing repository-
scoped blob link management in the backend. The `linkedBlobStore` implements
the full `BlobStore` suite, providing access-controlled, repository-local blob
writers. The abstraction between the two is slightly broken in that
`linkedBlobStore` is the only channel under which one can write into the global
blob store. The `linkedBlobStore` also provides flexibility in that it can act
over different link sets depending on configuration. This allows us to use the
same code for signature links, manifest links and blob links. Eventually, we
will fully consolidate this storage.
The improved cache flow comes from the `linkedBlobStatter` component
of `linkedBlobStore`. Using a `cachedBlobStatter`, these combine together to
provide a simple cache hierarchy that should streamline access checks on read
and write operations, or at least provide a single path to optimize. The
metrics have been changed in a slightly incompatible way since the former
operations, Fetch and Exists, are no longer relevant.
The fileWriter and fileReader have been slightly modified to support the rest
of the changes. The most interesting is the removal of the `Stat` call from
`newFileReader`. This was the source of unnecessary round trips that were only
present to look up the size of the resulting reader. Now, one must simply pass
in the size, requiring the caller to decide whether or not the `Stat` call is
appropriate. In several cases, it turned out the caller already had the size
already. The `WriterAt` implementation has been removed from `fileWriter`,
since it is no longer required for `BlobWriter`, reducing the number of paths
which writes may take.
Cache
-----
Unfortunately, the `cache` package required a near full rewrite. It was pretty
mechanical in that the cache is oriented around the `BlobDescriptorService`
slightly modified to include the ability to set the values for individual
digests. While the implementation is oriented towards caching, it can act as a
primary store. Provisions are in place to have repository local metadata, in
addition to global metadata. Fallback is implemented as a part of the storage
package to maintain this flexibility.
One unfortunate side-effect is that caching is now repository-scoped, rather
than global. This should have little effect on performance but may increase
memory usage.
Handlers
--------
The `handlers` package has been updated to leverage the new API. For the most
part, the changes are superficial or mechanical based on the API changes. This
did expose a bug in the handling of provisional vs canonical digests that was
fixed in the unit tests.
Configuration
-------------
One user-facing change has been made to the configuration and is updated in
the associated documentation. The `layerinfo` cache parameter has been
deprecated by the `blobdescriptor` cache parameter. Both are equivalent and
configuration files should be backward compatible.
Notifications
-------------
Changes the `notification` package are simply to support the interface
changes.
Context
-------
A small change has been made to the tracing log-level. Traces have been moved
from "info" to "debug" level to reduce output when not needed.
Signed-off-by: Stephen J Day <stephen.day@docker.com>
2015-05-12 07:10:29 +00:00
|
|
|
return path.Join(append(repoPrefix, v.name, "_uploads", v.id, "startedat")...), nil
|
2015-03-24 17:35:01 +00:00
|
|
|
case uploadHashStatePathSpec:
|
|
|
|
offset := fmt.Sprintf("%d", v.offset)
|
|
|
|
if v.list {
|
|
|
|
offset = "" // Limit to the prefix for listing offsets.
|
|
|
|
}
|
2015-05-22 01:44:08 +00:00
|
|
|
return path.Join(append(repoPrefix, v.name, "_uploads", v.id, "hashstates", string(v.alg), offset)...), nil
|
2015-04-07 22:52:48 +00:00
|
|
|
case repositoriesRootPathSpec:
|
|
|
|
return path.Join(repoPrefix...), nil
|
2014-11-13 23:16:54 +00:00
|
|
|
default:
|
|
|
|
// TODO(sday): This is an internal error. Ensure it doesn't escape (panic?).
|
|
|
|
return "", fmt.Errorf("unknown path spec: %#v", v)
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// pathSpec is a type to mark structs as path specs. There is no
|
|
|
|
// implementation because we'd like to keep the specs and the mappers
|
|
|
|
// decoupled.
|
|
|
|
type pathSpec interface {
|
|
|
|
pathSpec()
|
|
|
|
}
|
|
|
|
|
2022-07-10 02:04:50 +00:00
|
|
|
// manifestPathSpec describes the directory path for a manifest.
|
|
|
|
type manifestsPathSpec struct {
|
|
|
|
name string
|
|
|
|
}
|
|
|
|
|
|
|
|
func (manifestsPathSpec) pathSpec() {}
|
|
|
|
|
2016-01-19 22:26:15 +00:00
|
|
|
// manifestRevisionsPathSpec describes the directory path for
|
|
|
|
// a manifest revision.
|
|
|
|
type manifestRevisionsPathSpec struct {
|
|
|
|
name string
|
|
|
|
}
|
|
|
|
|
|
|
|
func (manifestRevisionsPathSpec) pathSpec() {}
|
|
|
|
|
2015-01-14 19:34:47 +00:00
|
|
|
// manifestRevisionPathSpec describes the components of the directory path for
|
|
|
|
// a manifest revision.
|
|
|
|
type manifestRevisionPathSpec struct {
|
|
|
|
name string
|
|
|
|
revision digest.Digest
|
|
|
|
}
|
|
|
|
|
|
|
|
func (manifestRevisionPathSpec) pathSpec() {}
|
|
|
|
|
|
|
|
// manifestRevisionLinkPathSpec describes the path components required to look
|
|
|
|
// up the data link for a revision of a manifest. If this file is not present,
|
|
|
|
// the manifest blob is not available in the given repo. The contents of this
|
|
|
|
// file should just be the digest.
|
|
|
|
type manifestRevisionLinkPathSpec struct {
|
|
|
|
name string
|
|
|
|
revision digest.Digest
|
|
|
|
}
|
|
|
|
|
|
|
|
func (manifestRevisionLinkPathSpec) pathSpec() {}
|
|
|
|
|
|
|
|
// manifestTagsPathSpec describes the path elements required to point to the
|
|
|
|
// manifest tags directory.
|
|
|
|
type manifestTagsPathSpec struct {
|
2014-12-09 19:06:51 +00:00
|
|
|
name string
|
|
|
|
}
|
|
|
|
|
2015-01-14 19:34:47 +00:00
|
|
|
func (manifestTagsPathSpec) pathSpec() {}
|
2014-12-09 19:06:51 +00:00
|
|
|
|
2015-01-14 19:34:47 +00:00
|
|
|
// manifestTagPathSpec describes the path elements required to point to the
|
|
|
|
// manifest tag links files under a repository. These contain a blob id that
|
|
|
|
// can be used to look up the data and signatures.
|
|
|
|
type manifestTagPathSpec struct {
|
2014-11-22 01:04:35 +00:00
|
|
|
name string
|
|
|
|
tag string
|
|
|
|
}
|
|
|
|
|
2015-01-14 19:34:47 +00:00
|
|
|
func (manifestTagPathSpec) pathSpec() {}
|
|
|
|
|
|
|
|
// manifestTagCurrentPathSpec describes the link to the current revision for a
|
|
|
|
// given tag.
|
|
|
|
type manifestTagCurrentPathSpec struct {
|
|
|
|
name string
|
|
|
|
tag string
|
|
|
|
}
|
|
|
|
|
|
|
|
func (manifestTagCurrentPathSpec) pathSpec() {}
|
|
|
|
|
|
|
|
// manifestTagCurrentPathSpec describes the link to the index of revisions
|
|
|
|
// with the given tag.
|
|
|
|
type manifestTagIndexPathSpec struct {
|
|
|
|
name string
|
|
|
|
tag string
|
|
|
|
}
|
|
|
|
|
|
|
|
func (manifestTagIndexPathSpec) pathSpec() {}
|
|
|
|
|
2015-02-26 23:47:04 +00:00
|
|
|
// manifestTagIndexEntryPathSpec contains the entries of the index by revision.
|
2015-01-14 19:34:47 +00:00
|
|
|
type manifestTagIndexEntryPathSpec struct {
|
|
|
|
name string
|
|
|
|
tag string
|
|
|
|
revision digest.Digest
|
|
|
|
}
|
|
|
|
|
|
|
|
func (manifestTagIndexEntryPathSpec) pathSpec() {}
|
2014-11-22 01:04:35 +00:00
|
|
|
|
2015-02-26 23:47:04 +00:00
|
|
|
// manifestTagIndexEntryLinkPathSpec describes the link to a revisions of a
|
|
|
|
// manifest with given tag within the index.
|
|
|
|
type manifestTagIndexEntryLinkPathSpec struct {
|
|
|
|
name string
|
|
|
|
tag string
|
|
|
|
revision digest.Digest
|
|
|
|
}
|
|
|
|
|
|
|
|
func (manifestTagIndexEntryLinkPathSpec) pathSpec() {}
|
|
|
|
|
2018-11-02 01:24:16 +00:00
|
|
|
// layersPathSpec contains the path for the layers inside a repo
|
|
|
|
type layersPathSpec struct {
|
2018-11-02 01:35:32 +00:00
|
|
|
name string
|
2018-11-02 01:24:16 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
func (layersPathSpec) pathSpec() {}
|
|
|
|
|
2023-08-30 14:36:14 +00:00
|
|
|
// layerLinkPathSpec specifies a path for a blob link, which is a file with a
|
Refactor Blob Service API
This PR refactors the blob service API to be oriented around blob descriptors.
Identified by digests, blobs become an abstract entity that can be read and
written using a descriptor as a handle. This allows blobs to take many forms,
such as a ReadSeekCloser or a simple byte buffer, allowing blob oriented
operations to better integrate with blob agnostic APIs (such as the `io`
package). The error definitions are now better organized to reflect conditions
that can only be seen when interacting with the blob API.
The main benefit of this is to separate the much smaller metadata from large
file storage. Many benefits also follow from this. Reading and writing has
been separated into discrete services. Backend implementation is also
simplified, by reducing the amount of metadata that needs to be picked up to
simply serve a read. This also improves cacheability.
"Opening" a blob simply consists of an access check (Stat) and a path
calculation. Caching is greatly simplified and we've made the mapping of
provisional to canonical hashes a first-class concept. BlobDescriptorService
and BlobProvider can be combined in different ways to achieve varying effects.
Recommend Review Approach
-------------------------
This is a very large patch. While apologies are in order, we are getting a
considerable amount of refactoring. Most changes follow from the changes to
the root package (distribution), so start there. From there, the main changes
are in storage. Looking at (*repository).Blobs will help to understand the how
the linkedBlobStore is wired. One can explore the internals within and also
branch out into understanding the changes to the caching layer. Following the
descriptions below will also help to guide you.
To reduce the chances for regressions, it was critical that major changes to
unit tests were avoided. Where possible, they are left untouched and where
not, the spirit is hopefully captured. Pay particular attention to where
behavior may have changed.
Storage
-------
The primary changes to the `storage` package, other than the interface
updates, were to merge the layerstore and blobstore. Blob access is now
layered even further. The first layer, blobStore, exposes a global
`BlobStatter` and `BlobProvider`. Operations here provide a fast path for most
read operations that don't take access control into account. The
`linkedBlobStore` layers on top of the `blobStore`, providing repository-
scoped blob link management in the backend. The `linkedBlobStore` implements
the full `BlobStore` suite, providing access-controlled, repository-local blob
writers. The abstraction between the two is slightly broken in that
`linkedBlobStore` is the only channel under which one can write into the global
blob store. The `linkedBlobStore` also provides flexibility in that it can act
over different link sets depending on configuration. This allows us to use the
same code for signature links, manifest links and blob links. Eventually, we
will fully consolidate this storage.
The improved cache flow comes from the `linkedBlobStatter` component
of `linkedBlobStore`. Using a `cachedBlobStatter`, these combine together to
provide a simple cache hierarchy that should streamline access checks on read
and write operations, or at least provide a single path to optimize. The
metrics have been changed in a slightly incompatible way since the former
operations, Fetch and Exists, are no longer relevant.
The fileWriter and fileReader have been slightly modified to support the rest
of the changes. The most interesting is the removal of the `Stat` call from
`newFileReader`. This was the source of unnecessary round trips that were only
present to look up the size of the resulting reader. Now, one must simply pass
in the size, requiring the caller to decide whether or not the `Stat` call is
appropriate. In several cases, it turned out the caller already had the size
already. The `WriterAt` implementation has been removed from `fileWriter`,
since it is no longer required for `BlobWriter`, reducing the number of paths
which writes may take.
Cache
-----
Unfortunately, the `cache` package required a near full rewrite. It was pretty
mechanical in that the cache is oriented around the `BlobDescriptorService`
slightly modified to include the ability to set the values for individual
digests. While the implementation is oriented towards caching, it can act as a
primary store. Provisions are in place to have repository local metadata, in
addition to global metadata. Fallback is implemented as a part of the storage
package to maintain this flexibility.
One unfortunate side-effect is that caching is now repository-scoped, rather
than global. This should have little effect on performance but may increase
memory usage.
Handlers
--------
The `handlers` package has been updated to leverage the new API. For the most
part, the changes are superficial or mechanical based on the API changes. This
did expose a bug in the handling of provisional vs canonical digests that was
fixed in the unit tests.
Configuration
-------------
One user-facing change has been made to the configuration and is updated in
the associated documentation. The `layerinfo` cache parameter has been
deprecated by the `blobdescriptor` cache parameter. Both are equivalent and
configuration files should be backward compatible.
Notifications
-------------
Changes the `notification` package are simply to support the interface
changes.
Context
-------
A small change has been made to the tracing log-level. Traces have been moved
from "info" to "debug" level to reduce output when not needed.
Signed-off-by: Stephen J Day <stephen.day@docker.com>
2015-05-12 07:10:29 +00:00
|
|
|
// blob id. The blob link will contain a content addressable blob id reference
|
2014-11-13 23:16:54 +00:00
|
|
|
// into the blob store. The format of the contents is as follows:
|
|
|
|
//
|
2022-11-02 21:05:45 +00:00
|
|
|
// <algorithm>:<hex digest of layer data>
|
2014-11-13 23:16:54 +00:00
|
|
|
//
|
|
|
|
// The following example of the file contents is more illustrative:
|
|
|
|
//
|
2022-11-02 21:05:45 +00:00
|
|
|
// sha256:96443a84ce518ac22acb2e985eda402b58ac19ce6f91980bde63726a79d80b36
|
2014-11-13 23:16:54 +00:00
|
|
|
//
|
Refactor Blob Service API
This PR refactors the blob service API to be oriented around blob descriptors.
Identified by digests, blobs become an abstract entity that can be read and
written using a descriptor as a handle. This allows blobs to take many forms,
such as a ReadSeekCloser or a simple byte buffer, allowing blob oriented
operations to better integrate with blob agnostic APIs (such as the `io`
package). The error definitions are now better organized to reflect conditions
that can only be seen when interacting with the blob API.
The main benefit of this is to separate the much smaller metadata from large
file storage. Many benefits also follow from this. Reading and writing has
been separated into discrete services. Backend implementation is also
simplified, by reducing the amount of metadata that needs to be picked up to
simply serve a read. This also improves cacheability.
"Opening" a blob simply consists of an access check (Stat) and a path
calculation. Caching is greatly simplified and we've made the mapping of
provisional to canonical hashes a first-class concept. BlobDescriptorService
and BlobProvider can be combined in different ways to achieve varying effects.
Recommend Review Approach
-------------------------
This is a very large patch. While apologies are in order, we are getting a
considerable amount of refactoring. Most changes follow from the changes to
the root package (distribution), so start there. From there, the main changes
are in storage. Looking at (*repository).Blobs will help to understand the how
the linkedBlobStore is wired. One can explore the internals within and also
branch out into understanding the changes to the caching layer. Following the
descriptions below will also help to guide you.
To reduce the chances for regressions, it was critical that major changes to
unit tests were avoided. Where possible, they are left untouched and where
not, the spirit is hopefully captured. Pay particular attention to where
behavior may have changed.
Storage
-------
The primary changes to the `storage` package, other than the interface
updates, were to merge the layerstore and blobstore. Blob access is now
layered even further. The first layer, blobStore, exposes a global
`BlobStatter` and `BlobProvider`. Operations here provide a fast path for most
read operations that don't take access control into account. The
`linkedBlobStore` layers on top of the `blobStore`, providing repository-
scoped blob link management in the backend. The `linkedBlobStore` implements
the full `BlobStore` suite, providing access-controlled, repository-local blob
writers. The abstraction between the two is slightly broken in that
`linkedBlobStore` is the only channel under which one can write into the global
blob store. The `linkedBlobStore` also provides flexibility in that it can act
over different link sets depending on configuration. This allows us to use the
same code for signature links, manifest links and blob links. Eventually, we
will fully consolidate this storage.
The improved cache flow comes from the `linkedBlobStatter` component
of `linkedBlobStore`. Using a `cachedBlobStatter`, these combine together to
provide a simple cache hierarchy that should streamline access checks on read
and write operations, or at least provide a single path to optimize. The
metrics have been changed in a slightly incompatible way since the former
operations, Fetch and Exists, are no longer relevant.
The fileWriter and fileReader have been slightly modified to support the rest
of the changes. The most interesting is the removal of the `Stat` call from
`newFileReader`. This was the source of unnecessary round trips that were only
present to look up the size of the resulting reader. Now, one must simply pass
in the size, requiring the caller to decide whether or not the `Stat` call is
appropriate. In several cases, it turned out the caller already had the size
already. The `WriterAt` implementation has been removed from `fileWriter`,
since it is no longer required for `BlobWriter`, reducing the number of paths
which writes may take.
Cache
-----
Unfortunately, the `cache` package required a near full rewrite. It was pretty
mechanical in that the cache is oriented around the `BlobDescriptorService`
slightly modified to include the ability to set the values for individual
digests. While the implementation is oriented towards caching, it can act as a
primary store. Provisions are in place to have repository local metadata, in
addition to global metadata. Fallback is implemented as a part of the storage
package to maintain this flexibility.
One unfortunate side-effect is that caching is now repository-scoped, rather
than global. This should have little effect on performance but may increase
memory usage.
Handlers
--------
The `handlers` package has been updated to leverage the new API. For the most
part, the changes are superficial or mechanical based on the API changes. This
did expose a bug in the handling of provisional vs canonical digests that was
fixed in the unit tests.
Configuration
-------------
One user-facing change has been made to the configuration and is updated in
the associated documentation. The `layerinfo` cache parameter has been
deprecated by the `blobdescriptor` cache parameter. Both are equivalent and
configuration files should be backward compatible.
Notifications
-------------
Changes the `notification` package are simply to support the interface
changes.
Context
-------
A small change has been made to the tracing log-level. Traces have been moved
from "info" to "debug" level to reduce output when not needed.
Signed-off-by: Stephen J Day <stephen.day@docker.com>
2015-05-12 07:10:29 +00:00
|
|
|
// This indicates that there is a blob with the id/digest, calculated via
|
2014-11-13 23:16:54 +00:00
|
|
|
// sha256 that can be fetched from the blob store.
|
|
|
|
type layerLinkPathSpec struct {
|
|
|
|
name string
|
2014-11-19 22:39:32 +00:00
|
|
|
digest digest.Digest
|
2014-11-13 23:16:54 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
func (layerLinkPathSpec) pathSpec() {}
|
|
|
|
|
2014-11-25 00:21:02 +00:00
|
|
|
// blobAlgorithmReplacer does some very simple path sanitization for user
|
2015-12-16 01:18:13 +00:00
|
|
|
// input. Paths should be "safe" before getting this far due to strict digest
|
|
|
|
// requirements but we can add further path conversion here, if needed.
|
2014-11-25 00:21:02 +00:00
|
|
|
var blobAlgorithmReplacer = strings.NewReplacer(
|
|
|
|
"+", "/",
|
|
|
|
".", "/",
|
|
|
|
";", "/",
|
|
|
|
)
|
2014-11-13 23:16:54 +00:00
|
|
|
|
2016-01-19 22:26:15 +00:00
|
|
|
// blobsPathSpec contains the path for the blobs directory
|
|
|
|
type blobsPathSpec struct{}
|
|
|
|
|
|
|
|
func (blobsPathSpec) pathSpec() {}
|
|
|
|
|
|
|
|
// blobPathSpec contains the path for the registry global blob store.
|
|
|
|
type blobPathSpec struct {
|
|
|
|
digest digest.Digest
|
|
|
|
}
|
2015-01-14 19:34:47 +00:00
|
|
|
|
2016-01-19 22:26:15 +00:00
|
|
|
func (blobPathSpec) pathSpec() {}
|
2015-01-14 19:34:47 +00:00
|
|
|
|
|
|
|
// blobDataPathSpec contains the path for the registry global blob store. For
|
|
|
|
// now, this contains layer data, exclusively.
|
|
|
|
type blobDataPathSpec struct {
|
2014-11-25 00:21:02 +00:00
|
|
|
digest digest.Digest
|
2014-11-13 23:16:54 +00:00
|
|
|
}
|
|
|
|
|
2015-01-14 19:34:47 +00:00
|
|
|
func (blobDataPathSpec) pathSpec() {}
|
2014-11-13 23:16:54 +00:00
|
|
|
|
2015-01-08 22:10:08 +00:00
|
|
|
// uploadDataPathSpec defines the path parameters of the data file for
|
|
|
|
// uploads.
|
|
|
|
type uploadDataPathSpec struct {
|
|
|
|
name string
|
Refactor Blob Service API
This PR refactors the blob service API to be oriented around blob descriptors.
Identified by digests, blobs become an abstract entity that can be read and
written using a descriptor as a handle. This allows blobs to take many forms,
such as a ReadSeekCloser or a simple byte buffer, allowing blob oriented
operations to better integrate with blob agnostic APIs (such as the `io`
package). The error definitions are now better organized to reflect conditions
that can only be seen when interacting with the blob API.
The main benefit of this is to separate the much smaller metadata from large
file storage. Many benefits also follow from this. Reading and writing has
been separated into discrete services. Backend implementation is also
simplified, by reducing the amount of metadata that needs to be picked up to
simply serve a read. This also improves cacheability.
"Opening" a blob simply consists of an access check (Stat) and a path
calculation. Caching is greatly simplified and we've made the mapping of
provisional to canonical hashes a first-class concept. BlobDescriptorService
and BlobProvider can be combined in different ways to achieve varying effects.
Recommend Review Approach
-------------------------
This is a very large patch. While apologies are in order, we are getting a
considerable amount of refactoring. Most changes follow from the changes to
the root package (distribution), so start there. From there, the main changes
are in storage. Looking at (*repository).Blobs will help to understand the how
the linkedBlobStore is wired. One can explore the internals within and also
branch out into understanding the changes to the caching layer. Following the
descriptions below will also help to guide you.
To reduce the chances for regressions, it was critical that major changes to
unit tests were avoided. Where possible, they are left untouched and where
not, the spirit is hopefully captured. Pay particular attention to where
behavior may have changed.
Storage
-------
The primary changes to the `storage` package, other than the interface
updates, were to merge the layerstore and blobstore. Blob access is now
layered even further. The first layer, blobStore, exposes a global
`BlobStatter` and `BlobProvider`. Operations here provide a fast path for most
read operations that don't take access control into account. The
`linkedBlobStore` layers on top of the `blobStore`, providing repository-
scoped blob link management in the backend. The `linkedBlobStore` implements
the full `BlobStore` suite, providing access-controlled, repository-local blob
writers. The abstraction between the two is slightly broken in that
`linkedBlobStore` is the only channel under which one can write into the global
blob store. The `linkedBlobStore` also provides flexibility in that it can act
over different link sets depending on configuration. This allows us to use the
same code for signature links, manifest links and blob links. Eventually, we
will fully consolidate this storage.
The improved cache flow comes from the `linkedBlobStatter` component
of `linkedBlobStore`. Using a `cachedBlobStatter`, these combine together to
provide a simple cache hierarchy that should streamline access checks on read
and write operations, or at least provide a single path to optimize. The
metrics have been changed in a slightly incompatible way since the former
operations, Fetch and Exists, are no longer relevant.
The fileWriter and fileReader have been slightly modified to support the rest
of the changes. The most interesting is the removal of the `Stat` call from
`newFileReader`. This was the source of unnecessary round trips that were only
present to look up the size of the resulting reader. Now, one must simply pass
in the size, requiring the caller to decide whether or not the `Stat` call is
appropriate. In several cases, it turned out the caller already had the size
already. The `WriterAt` implementation has been removed from `fileWriter`,
since it is no longer required for `BlobWriter`, reducing the number of paths
which writes may take.
Cache
-----
Unfortunately, the `cache` package required a near full rewrite. It was pretty
mechanical in that the cache is oriented around the `BlobDescriptorService`
slightly modified to include the ability to set the values for individual
digests. While the implementation is oriented towards caching, it can act as a
primary store. Provisions are in place to have repository local metadata, in
addition to global metadata. Fallback is implemented as a part of the storage
package to maintain this flexibility.
One unfortunate side-effect is that caching is now repository-scoped, rather
than global. This should have little effect on performance but may increase
memory usage.
Handlers
--------
The `handlers` package has been updated to leverage the new API. For the most
part, the changes are superficial or mechanical based on the API changes. This
did expose a bug in the handling of provisional vs canonical digests that was
fixed in the unit tests.
Configuration
-------------
One user-facing change has been made to the configuration and is updated in
the associated documentation. The `layerinfo` cache parameter has been
deprecated by the `blobdescriptor` cache parameter. Both are equivalent and
configuration files should be backward compatible.
Notifications
-------------
Changes the `notification` package are simply to support the interface
changes.
Context
-------
A small change has been made to the tracing log-level. Traces have been moved
from "info" to "debug" level to reduce output when not needed.
Signed-off-by: Stephen J Day <stephen.day@docker.com>
2015-05-12 07:10:29 +00:00
|
|
|
id string
|
2015-01-08 22:10:08 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
func (uploadDataPathSpec) pathSpec() {}
|
|
|
|
|
2023-08-30 14:36:14 +00:00
|
|
|
// uploadStartedAtPathSpec defines the path parameters for the file that stores the
|
2015-01-08 22:10:08 +00:00
|
|
|
// start time of an uploads. If it is missing, the upload is considered
|
|
|
|
// unknown. Admittedly, the presence of this file is an ugly hack to make sure
|
|
|
|
// we have a way to cleanup old or stalled uploads that doesn't rely on driver
|
|
|
|
// FileInfo behavior. If we come up with a more clever way to do this, we
|
|
|
|
// should remove this file immediately and rely on the startetAt field from
|
|
|
|
// the client to enforce time out policies.
|
|
|
|
type uploadStartedAtPathSpec struct {
|
|
|
|
name string
|
Refactor Blob Service API
This PR refactors the blob service API to be oriented around blob descriptors.
Identified by digests, blobs become an abstract entity that can be read and
written using a descriptor as a handle. This allows blobs to take many forms,
such as a ReadSeekCloser or a simple byte buffer, allowing blob oriented
operations to better integrate with blob agnostic APIs (such as the `io`
package). The error definitions are now better organized to reflect conditions
that can only be seen when interacting with the blob API.
The main benefit of this is to separate the much smaller metadata from large
file storage. Many benefits also follow from this. Reading and writing has
been separated into discrete services. Backend implementation is also
simplified, by reducing the amount of metadata that needs to be picked up to
simply serve a read. This also improves cacheability.
"Opening" a blob simply consists of an access check (Stat) and a path
calculation. Caching is greatly simplified and we've made the mapping of
provisional to canonical hashes a first-class concept. BlobDescriptorService
and BlobProvider can be combined in different ways to achieve varying effects.
Recommend Review Approach
-------------------------
This is a very large patch. While apologies are in order, we are getting a
considerable amount of refactoring. Most changes follow from the changes to
the root package (distribution), so start there. From there, the main changes
are in storage. Looking at (*repository).Blobs will help to understand the how
the linkedBlobStore is wired. One can explore the internals within and also
branch out into understanding the changes to the caching layer. Following the
descriptions below will also help to guide you.
To reduce the chances for regressions, it was critical that major changes to
unit tests were avoided. Where possible, they are left untouched and where
not, the spirit is hopefully captured. Pay particular attention to where
behavior may have changed.
Storage
-------
The primary changes to the `storage` package, other than the interface
updates, were to merge the layerstore and blobstore. Blob access is now
layered even further. The first layer, blobStore, exposes a global
`BlobStatter` and `BlobProvider`. Operations here provide a fast path for most
read operations that don't take access control into account. The
`linkedBlobStore` layers on top of the `blobStore`, providing repository-
scoped blob link management in the backend. The `linkedBlobStore` implements
the full `BlobStore` suite, providing access-controlled, repository-local blob
writers. The abstraction between the two is slightly broken in that
`linkedBlobStore` is the only channel under which one can write into the global
blob store. The `linkedBlobStore` also provides flexibility in that it can act
over different link sets depending on configuration. This allows us to use the
same code for signature links, manifest links and blob links. Eventually, we
will fully consolidate this storage.
The improved cache flow comes from the `linkedBlobStatter` component
of `linkedBlobStore`. Using a `cachedBlobStatter`, these combine together to
provide a simple cache hierarchy that should streamline access checks on read
and write operations, or at least provide a single path to optimize. The
metrics have been changed in a slightly incompatible way since the former
operations, Fetch and Exists, are no longer relevant.
The fileWriter and fileReader have been slightly modified to support the rest
of the changes. The most interesting is the removal of the `Stat` call from
`newFileReader`. This was the source of unnecessary round trips that were only
present to look up the size of the resulting reader. Now, one must simply pass
in the size, requiring the caller to decide whether or not the `Stat` call is
appropriate. In several cases, it turned out the caller already had the size
already. The `WriterAt` implementation has been removed from `fileWriter`,
since it is no longer required for `BlobWriter`, reducing the number of paths
which writes may take.
Cache
-----
Unfortunately, the `cache` package required a near full rewrite. It was pretty
mechanical in that the cache is oriented around the `BlobDescriptorService`
slightly modified to include the ability to set the values for individual
digests. While the implementation is oriented towards caching, it can act as a
primary store. Provisions are in place to have repository local metadata, in
addition to global metadata. Fallback is implemented as a part of the storage
package to maintain this flexibility.
One unfortunate side-effect is that caching is now repository-scoped, rather
than global. This should have little effect on performance but may increase
memory usage.
Handlers
--------
The `handlers` package has been updated to leverage the new API. For the most
part, the changes are superficial or mechanical based on the API changes. This
did expose a bug in the handling of provisional vs canonical digests that was
fixed in the unit tests.
Configuration
-------------
One user-facing change has been made to the configuration and is updated in
the associated documentation. The `layerinfo` cache parameter has been
deprecated by the `blobdescriptor` cache parameter. Both are equivalent and
configuration files should be backward compatible.
Notifications
-------------
Changes the `notification` package are simply to support the interface
changes.
Context
-------
A small change has been made to the tracing log-level. Traces have been moved
from "info" to "debug" level to reduce output when not needed.
Signed-off-by: Stephen J Day <stephen.day@docker.com>
2015-05-12 07:10:29 +00:00
|
|
|
id string
|
2015-01-08 22:10:08 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
func (uploadStartedAtPathSpec) pathSpec() {}
|
|
|
|
|
2015-03-24 17:35:01 +00:00
|
|
|
// uploadHashStatePathSpec defines the path parameters for the file that stores
|
|
|
|
// the hash function state of an upload at a specific byte offset. If `list` is
|
|
|
|
// set, then the path mapper will generate a list prefix for all hash state
|
Refactor Blob Service API
This PR refactors the blob service API to be oriented around blob descriptors.
Identified by digests, blobs become an abstract entity that can be read and
written using a descriptor as a handle. This allows blobs to take many forms,
such as a ReadSeekCloser or a simple byte buffer, allowing blob oriented
operations to better integrate with blob agnostic APIs (such as the `io`
package). The error definitions are now better organized to reflect conditions
that can only be seen when interacting with the blob API.
The main benefit of this is to separate the much smaller metadata from large
file storage. Many benefits also follow from this. Reading and writing has
been separated into discrete services. Backend implementation is also
simplified, by reducing the amount of metadata that needs to be picked up to
simply serve a read. This also improves cacheability.
"Opening" a blob simply consists of an access check (Stat) and a path
calculation. Caching is greatly simplified and we've made the mapping of
provisional to canonical hashes a first-class concept. BlobDescriptorService
and BlobProvider can be combined in different ways to achieve varying effects.
Recommend Review Approach
-------------------------
This is a very large patch. While apologies are in order, we are getting a
considerable amount of refactoring. Most changes follow from the changes to
the root package (distribution), so start there. From there, the main changes
are in storage. Looking at (*repository).Blobs will help to understand the how
the linkedBlobStore is wired. One can explore the internals within and also
branch out into understanding the changes to the caching layer. Following the
descriptions below will also help to guide you.
To reduce the chances for regressions, it was critical that major changes to
unit tests were avoided. Where possible, they are left untouched and where
not, the spirit is hopefully captured. Pay particular attention to where
behavior may have changed.
Storage
-------
The primary changes to the `storage` package, other than the interface
updates, were to merge the layerstore and blobstore. Blob access is now
layered even further. The first layer, blobStore, exposes a global
`BlobStatter` and `BlobProvider`. Operations here provide a fast path for most
read operations that don't take access control into account. The
`linkedBlobStore` layers on top of the `blobStore`, providing repository-
scoped blob link management in the backend. The `linkedBlobStore` implements
the full `BlobStore` suite, providing access-controlled, repository-local blob
writers. The abstraction between the two is slightly broken in that
`linkedBlobStore` is the only channel under which one can write into the global
blob store. The `linkedBlobStore` also provides flexibility in that it can act
over different link sets depending on configuration. This allows us to use the
same code for signature links, manifest links and blob links. Eventually, we
will fully consolidate this storage.
The improved cache flow comes from the `linkedBlobStatter` component
of `linkedBlobStore`. Using a `cachedBlobStatter`, these combine together to
provide a simple cache hierarchy that should streamline access checks on read
and write operations, or at least provide a single path to optimize. The
metrics have been changed in a slightly incompatible way since the former
operations, Fetch and Exists, are no longer relevant.
The fileWriter and fileReader have been slightly modified to support the rest
of the changes. The most interesting is the removal of the `Stat` call from
`newFileReader`. This was the source of unnecessary round trips that were only
present to look up the size of the resulting reader. Now, one must simply pass
in the size, requiring the caller to decide whether or not the `Stat` call is
appropriate. In several cases, it turned out the caller already had the size
already. The `WriterAt` implementation has been removed from `fileWriter`,
since it is no longer required for `BlobWriter`, reducing the number of paths
which writes may take.
Cache
-----
Unfortunately, the `cache` package required a near full rewrite. It was pretty
mechanical in that the cache is oriented around the `BlobDescriptorService`
slightly modified to include the ability to set the values for individual
digests. While the implementation is oriented towards caching, it can act as a
primary store. Provisions are in place to have repository local metadata, in
addition to global metadata. Fallback is implemented as a part of the storage
package to maintain this flexibility.
One unfortunate side-effect is that caching is now repository-scoped, rather
than global. This should have little effect on performance but may increase
memory usage.
Handlers
--------
The `handlers` package has been updated to leverage the new API. For the most
part, the changes are superficial or mechanical based on the API changes. This
did expose a bug in the handling of provisional vs canonical digests that was
fixed in the unit tests.
Configuration
-------------
One user-facing change has been made to the configuration and is updated in
the associated documentation. The `layerinfo` cache parameter has been
deprecated by the `blobdescriptor` cache parameter. Both are equivalent and
configuration files should be backward compatible.
Notifications
-------------
Changes the `notification` package are simply to support the interface
changes.
Context
-------
A small change has been made to the tracing log-level. Traces have been moved
from "info" to "debug" level to reduce output when not needed.
Signed-off-by: Stephen J Day <stephen.day@docker.com>
2015-05-12 07:10:29 +00:00
|
|
|
// offsets for the upload identified by the name, id, and alg.
|
2015-03-24 17:35:01 +00:00
|
|
|
type uploadHashStatePathSpec struct {
|
|
|
|
name string
|
Refactor Blob Service API
This PR refactors the blob service API to be oriented around blob descriptors.
Identified by digests, blobs become an abstract entity that can be read and
written using a descriptor as a handle. This allows blobs to take many forms,
such as a ReadSeekCloser or a simple byte buffer, allowing blob oriented
operations to better integrate with blob agnostic APIs (such as the `io`
package). The error definitions are now better organized to reflect conditions
that can only be seen when interacting with the blob API.
The main benefit of this is to separate the much smaller metadata from large
file storage. Many benefits also follow from this. Reading and writing has
been separated into discrete services. Backend implementation is also
simplified, by reducing the amount of metadata that needs to be picked up to
simply serve a read. This also improves cacheability.
"Opening" a blob simply consists of an access check (Stat) and a path
calculation. Caching is greatly simplified and we've made the mapping of
provisional to canonical hashes a first-class concept. BlobDescriptorService
and BlobProvider can be combined in different ways to achieve varying effects.
Recommend Review Approach
-------------------------
This is a very large patch. While apologies are in order, we are getting a
considerable amount of refactoring. Most changes follow from the changes to
the root package (distribution), so start there. From there, the main changes
are in storage. Looking at (*repository).Blobs will help to understand the how
the linkedBlobStore is wired. One can explore the internals within and also
branch out into understanding the changes to the caching layer. Following the
descriptions below will also help to guide you.
To reduce the chances for regressions, it was critical that major changes to
unit tests were avoided. Where possible, they are left untouched and where
not, the spirit is hopefully captured. Pay particular attention to where
behavior may have changed.
Storage
-------
The primary changes to the `storage` package, other than the interface
updates, were to merge the layerstore and blobstore. Blob access is now
layered even further. The first layer, blobStore, exposes a global
`BlobStatter` and `BlobProvider`. Operations here provide a fast path for most
read operations that don't take access control into account. The
`linkedBlobStore` layers on top of the `blobStore`, providing repository-
scoped blob link management in the backend. The `linkedBlobStore` implements
the full `BlobStore` suite, providing access-controlled, repository-local blob
writers. The abstraction between the two is slightly broken in that
`linkedBlobStore` is the only channel under which one can write into the global
blob store. The `linkedBlobStore` also provides flexibility in that it can act
over different link sets depending on configuration. This allows us to use the
same code for signature links, manifest links and blob links. Eventually, we
will fully consolidate this storage.
The improved cache flow comes from the `linkedBlobStatter` component
of `linkedBlobStore`. Using a `cachedBlobStatter`, these combine together to
provide a simple cache hierarchy that should streamline access checks on read
and write operations, or at least provide a single path to optimize. The
metrics have been changed in a slightly incompatible way since the former
operations, Fetch and Exists, are no longer relevant.
The fileWriter and fileReader have been slightly modified to support the rest
of the changes. The most interesting is the removal of the `Stat` call from
`newFileReader`. This was the source of unnecessary round trips that were only
present to look up the size of the resulting reader. Now, one must simply pass
in the size, requiring the caller to decide whether or not the `Stat` call is
appropriate. In several cases, it turned out the caller already had the size
already. The `WriterAt` implementation has been removed from `fileWriter`,
since it is no longer required for `BlobWriter`, reducing the number of paths
which writes may take.
Cache
-----
Unfortunately, the `cache` package required a near full rewrite. It was pretty
mechanical in that the cache is oriented around the `BlobDescriptorService`
slightly modified to include the ability to set the values for individual
digests. While the implementation is oriented towards caching, it can act as a
primary store. Provisions are in place to have repository local metadata, in
addition to global metadata. Fallback is implemented as a part of the storage
package to maintain this flexibility.
One unfortunate side-effect is that caching is now repository-scoped, rather
than global. This should have little effect on performance but may increase
memory usage.
Handlers
--------
The `handlers` package has been updated to leverage the new API. For the most
part, the changes are superficial or mechanical based on the API changes. This
did expose a bug in the handling of provisional vs canonical digests that was
fixed in the unit tests.
Configuration
-------------
One user-facing change has been made to the configuration and is updated in
the associated documentation. The `layerinfo` cache parameter has been
deprecated by the `blobdescriptor` cache parameter. Both are equivalent and
configuration files should be backward compatible.
Notifications
-------------
Changes the `notification` package are simply to support the interface
changes.
Context
-------
A small change has been made to the tracing log-level. Traces have been moved
from "info" to "debug" level to reduce output when not needed.
Signed-off-by: Stephen J Day <stephen.day@docker.com>
2015-05-12 07:10:29 +00:00
|
|
|
id string
|
2015-05-22 01:44:08 +00:00
|
|
|
alg digest.Algorithm
|
2015-03-24 17:35:01 +00:00
|
|
|
offset int64
|
|
|
|
list bool
|
|
|
|
}
|
|
|
|
|
|
|
|
func (uploadHashStatePathSpec) pathSpec() {}
|
|
|
|
|
2015-04-07 22:52:48 +00:00
|
|
|
// repositoriesRootPathSpec returns the root of repositories
|
2022-11-02 21:05:45 +00:00
|
|
|
type repositoriesRootPathSpec struct{}
|
2015-04-07 22:52:48 +00:00
|
|
|
|
|
|
|
func (repositoriesRootPathSpec) pathSpec() {}
|
|
|
|
|
2015-01-14 19:34:47 +00:00
|
|
|
// digestPathComponents provides a consistent path breakdown for a given
|
2014-11-25 00:21:02 +00:00
|
|
|
// digest. For a generic digest, it will be as follows:
|
|
|
|
//
|
2022-11-02 21:05:45 +00:00
|
|
|
// <algorithm>/<hex digest>
|
2014-11-25 00:21:02 +00:00
|
|
|
//
|
2015-01-14 19:34:47 +00:00
|
|
|
// If multilevel is true, the first two bytes of the digest will separate
|
|
|
|
// groups of digest folder. It will be as follows:
|
2014-11-25 00:21:02 +00:00
|
|
|
//
|
2022-11-02 21:05:45 +00:00
|
|
|
// <algorithm>/<first two bytes of digest>/<full digest>
|
2015-01-14 19:34:47 +00:00
|
|
|
func digestPathComponents(dgst digest.Digest, multilevel bool) ([]string, error) {
|
2014-11-25 00:21:02 +00:00
|
|
|
if err := dgst.Validate(); err != nil {
|
|
|
|
return nil, err
|
|
|
|
}
|
|
|
|
|
2015-05-22 01:44:08 +00:00
|
|
|
algorithm := blobAlgorithmReplacer.Replace(string(dgst.Algorithm()))
|
2022-11-08 12:51:11 +00:00
|
|
|
hex := dgst.Encoded()
|
2014-11-25 00:21:02 +00:00
|
|
|
prefix := []string{algorithm}
|
2015-01-14 19:34:47 +00:00
|
|
|
|
|
|
|
var suffix []string
|
|
|
|
|
|
|
|
if multilevel {
|
|
|
|
suffix = append(suffix, hex[:2])
|
2014-11-25 00:21:02 +00:00
|
|
|
}
|
2014-11-13 23:16:54 +00:00
|
|
|
|
2015-01-14 19:34:47 +00:00
|
|
|
suffix = append(suffix, hex)
|
|
|
|
|
2014-11-25 00:21:02 +00:00
|
|
|
return append(prefix, suffix...), nil
|
2014-11-13 23:16:54 +00:00
|
|
|
}
|
2016-01-19 22:26:15 +00:00
|
|
|
|
|
|
|
// Reconstructs a digest from a path
|
|
|
|
func digestFromPath(digestPath string) (digest.Digest, error) {
|
|
|
|
digestPath = strings.TrimSuffix(digestPath, "/data")
|
|
|
|
dir, hex := path.Split(digestPath)
|
|
|
|
dir = path.Dir(dir)
|
|
|
|
dir, next := path.Split(dir)
|
|
|
|
|
|
|
|
// next is either the algorithm OR the first two characters in the hex string
|
|
|
|
var algo string
|
|
|
|
if next == hex[:2] {
|
|
|
|
algo = path.Base(dir)
|
|
|
|
} else {
|
|
|
|
algo = next
|
|
|
|
}
|
|
|
|
|
2022-11-08 12:51:11 +00:00
|
|
|
dgst := digest.NewDigestFromEncoded(digest.Algorithm(algo), hex)
|
2016-01-19 22:26:15 +00:00
|
|
|
return dgst, dgst.Validate()
|
|
|
|
}
|