Writable Asset Cache #171
Writable Asset Cache #171
Conversation
Signed-off-by: Emily Casey <[email protected]>
|
|
||
| The way caching currently works in CNB, the layer cache is scoped to a particular image and the cached layers are only restored during a rebuild of that exact image. There are good reasons for this. First of all, on the first build of a new app there is no way of knowing which layers might be helpful to restore. Because layers affect the behavior of subsequent buildpacks and may be directly included in the final app image (launch layers), the potential consequences of deliberate cache poisoning or accidental leakage of unexpected changes between images are high. Buildpacks general cannot predict the diffID of a given layer and therefore have no way to check the integrity of a restored layer. Therefore it is essential that layer caching remains scoped to rebuilds. | ||
|
|
||
| However, caching of assets, particularly if they are not restored to a layer, presents much less risk. Buildpacks generally known the hash of the asset they are attempting to download and can therefore check the integrity of a cached asset before using it in a layer. |
There was a problem hiding this comment.
| However, caching of assets, particularly if they are not restored to a layer, presents much less risk. Buildpacks generally known the hash of the asset they are attempting to download and can therefore check the integrity of a cached asset before using it in a layer. | |
| However, caching of assets, particularly if they are not restored to a layer, presents much less risk. Buildpacks generally know the hash of the asset they are attempting to download and can therefore check the integrity of a cached asset before using it in a layer. |
|
|
||
|  | ||
|
|
||
|
|
There was a problem hiding this comment.
An example buildpack using this new $CNB_ASSET_CACHE would be very valuable in addition to this awesome flowchart.
|
@elcasey I am very much interested in this RFC. I have a similar concern too. We are still on design phase to start implementation of buildpacks in our enterprise and we use Jenkins for our CiCd and I have the same concern. When we run our pack build there is no guarantee that the build will run on same Jenkins node as we have lot of cluster nodes and any one node can pick up the build process. Hopefully this RFC would solve our concerns as we need to be able to reuse the Docker cached layers across the clustered nodes. Thanks |
|
Maintainers, As you review this RFC please queue up issues to be created using the following commands: Issues(none) |
Readable