Commit Graph

36 Commits

Author SHA1 Message Date
Maxime BOSSARD df488dac40
Reproducing and Fixing #2892 (#2893)
* Add an integration test to reproduce #2892

* Fix go compilation

* Fix docker run cmd

* Fixing entrypoint

* Test warmer with cache in a volume.

* Add missing comma

* Fix imports

* Fix dir

* Add logs

* fix

* Use test framework to log

* Fix warmer failing if image already in cache.

* Fix format.
2023-12-14 17:00:54 -08:00
Maxime BOSSARD e4791117c5
fix: resolve warmer memory leak. (#2763)
* Fix warmer memory leak. Write down images directly into a temp file. Add a script to test warmer in boxed memory conditions. Fixes: #2754

* Document usage of boxed_warm_in_docker.sh integration test.
2023-11-28 19:30:13 -08:00
Manish Giri 7bfc73c3ad
fix: Remove references to deprecated io/ioutil pkg (#2867)
* Update benchmark_test

* Updae tar.go

* Update further refs

* Commit next set of replacements

* Reverting changes in vendor folder

* Update integreation_with_context_test.go

* Update k8s_test.go

* Update remaining usages

* Replace conflicting usage of fs local variable
2023-11-28 13:02:53 -08:00
alexezio 0743c19176
feat: cache dockerfile images through warmer (#2499)
* feat: cache dockerfile images through warmer

* Fix logical error in conditional statement

* Addressed review feedback

1. Updated help text for the --build-arg flag to indicate it should be used with the dockerfile flag.
2. Updated the documentation to include the optional --build-arg flag.
3. Added unit tests for `ParseDockerfile`, covering scenarios for missing Dockerfile, invalid Dockerfile, single stage Dockerfile, multi-stage Dockerfile and Args Dockerfile

---------

Co-authored-by: 连奔驰 <benchi.lian@thoughtworks.com>
2023-06-21 12:00:22 -07:00
Eric 7525828ef9
Add mTLS (client cert) registry authentication (#2180)
* Add mTLS (client cert) support

Add support for Mutual TLS (mTLS) client certificate authentication.
The expected format of the new --registry-client-cert flag is the same
as the existing --registry-certificate flag, which will allow
different client certificates for different registries:

--registry-client-cert my.registry.url=/path/to/cert.crt,/path/to/key.key

* tidy: Rename mTLS (Client Cert) flag to be in line with others

This flag didn't describe that it was for the client certs uses with
the registry. Although this should be reasonably obvious, I like the
consistency with the other registry flag.

* test: Added unit tests for mTLS (Client Cert) loading

* test: Add 2 more tests for comma split formatting

since the comma splitting is a new portion of code let's make sure
that that format works well too in other cases

* tidy: Fix formatting of flag help text

* tidy: Made invalid cert format error consistent

I was running the tests and saw the message:

Failed to load client certificate/key '/path/to/client/certificate.cert' for my.registry.name, format is my.registry.name=/path/to/cert,/path/to/key

I then realized that it'd be a lot nicer if this showed the user what
they input, and how they should change it (rather than decomposing it:

Failed to load client certificate/key 'my.registry.name=/path/to/client/certificate.cert', expected format: my.registry.name=/path/to/cert,/path/to/key

* test: Fixed incorrect test argument

This didn't fail the test before because it's only attempting to show
that certs only get loaded and used for their associated registry but
it's important to keep this correct.

This case is covered by the test below, "RegistriesClientCertificates
incorrect cert format"

* doc: Add new flag to README.md

* mod: Fail to push if there was a problem loading client certs

Rather than warning that there was an issue, we should fail if the
requested client certificates were not found or failed to load.

This feels a lot better than waiting for the build to finish then
failing later.

* mod: Return an error if the certificate authority fails to load, just like client certs

The MakeTransport function was changed in the previous commit to
allow returning errors if there was a problem loading certificates,
rather than just print warnings.

This feels a lot better as you get the error immediately that there's
a problem to fix, rather than getting a warning, then later an error
that the server's certificate could not be verified.

* tidy: fix golint issues
2023-05-18 14:20:51 -07:00
Joël Pepper 14ea7c4071
Fix Integration tests (#2425)
* fix(ci): Bump golangci-lint to 1.51.1

* chore(lint): fix gofmt and goimport issues

* chore(lint): fix linter issues

- Adapted error comparison according to linter recommendation
- Disabled noctx linting for http request where canceling makes no sense
- Disabled nilerror linting where nil error is returned on purpose
- Disabled makezero linter where slice is explicitly deepcopied

* chore(ci): Update go version in tests workflows

* fix(ci): Allow boilerplate years from 2000-2099

Previously the regex only allowed the copyright notice to contain the
years 2018,2019,2020,2021, or 2022. This commit widens to regex to
20\d\d allowing any year in the range [2000-2099]

* feat(ci): Replace minikube with k3s for intregration tests

The existing setup for minikube is very complicated, replicating most of
the setup steps for a full kubernetes cluster in an only partially
supported minikube configuration (driver=none). Furthermore the existing
setup has been broken for sometime, likely, at least in part due to the
changes to CNI and CRI in recent kubernetes versions.

Since what we actually need is only a running Kubernetes cluster on the
node and access to a registry on localhost:5000, we can switch the
extremely complicated minikube setup for a lightweight cluster using
k3s. Minikube came with a default addon for running a registry on every
node, but the same is not the case for k3s, instead we make use of the
package helm controller and its HelmChart CR to deploy twuni/docker-registry.helm
and expose it on localhost using the integrated LoadBalancer controller.

* fix(test-684): pin base container version

The dockerfile for the regression test connected to issue 684 used a
rolling tag as base image, making it flaky and fail since it was
introduced.

This commit pins the base image to the digest of bionic-20200219, which,
based on the date of the commit that introduced to the dockerfile would
be the most newest ubuntu build and likely what the "rolling" tag
resolved to back then. Since this also an image from the pre-oci days of
ubuntu, this circumvents a bug in container-diff as well
(https://github.com/GoogleContainerTools/container-diff/issues/389)
2023-03-21 12:30:54 -04:00
Natalie Arellano 4d077e2a40
Provide `--cache-repo` as OCI image layout path (#2250)
* Adds the ability to provide `--cache-repo` as an OCI image layout path

- Adds cache.LayoutCache to implement cache.LayerCache interface
- When opts.CacheRepo has "oci:" prefix, instantiates a LayoutCache

Signed-off-by: Natalie Arellano <narellano@vmware.com>

* Add integration test for layout cache

Signed-off-by: Natalie Arellano <narellano@vmware.com>

* Updates from PR review

Signed-off-by: Natalie Arellano <narellano@vmware.com>

Signed-off-by: Natalie Arellano <narellano@vmware.com>
2022-09-28 10:19:02 -04:00
Max Walther 1ee4140024
Try to warm all images and warn about errors (#1653)
When providing multiple images to warm, the warmer stops at the first error.
There are use cases however where an image is provided to the warmer which does not yet exist on purpose (e.g. CI/CD latest image only created at first release).
Thus we want to try all given images and only error if none of them work.
2021-06-04 10:07:57 -07:00
Colin b33f9655eb
Support warming images by digest (#1629) 2021-04-22 11:51:33 -07:00
Vincent Behar dde98a8e73
feat(warmer): Warmer now supports all registry-related flags (#1499)
which means we can now:
- set up one or more mirrors
- set up registries certificates
- skip TLS verify
- use plain HTTP
using the same set of flags that are defined for the executor
2020-12-10 22:55:43 -08:00
tsufeki 4af795bf4a Use current platform when fetching image in warmer
Cache warming fetched images without specifying platform, which resulted
in always pulling default linux/amd64. Even when kaniko was built and
run on arm64.

This change brings warmer's behaviour in line with executor's by
specifying runtime.GOOS/GOARCH.

Fixes #1372
2020-08-07 15:52:15 +02:00
Ben Einaudi 2f6090dcd7 Remove use of DefaultTransport
Using DefaultTransport and manipulating its tls configuration may lead to unexpected behaviour
2020-05-20 11:43:13 +02:00
Stijn De Haes 3fa8f686db Support for private registries in the cache warmer
Closes #503

Signed-off-by: Stijn De Haes <stijndehaes@gmail.com>
2020-01-15 15:35:42 +01:00
Cole Wippern 776fa43eb2 refactor cache.Warm and add tests 2020-01-10 12:29:17 -08:00
Cole Wippern b1b0513c05 Fix #926 cache warmer and method signature 2020-01-10 12:29:16 -08:00
Nao YONASHIRO cbba7cec3f chore: fix typo 2019-12-21 14:44:12 -08:00
Cole Wippern a6e458caf1 Update error handling and logging for cache
Previously we returned a low level file system error when checking for
a cached image. By adding a more human friendly log message and explicit
error handling we improve upon the user experience.
2019-11-22 14:54:38 -08:00
tralexa 75083a0c55
Merge branch 'master' into master 2019-09-16 15:58:17 +03:00
Sharif Elgamal 56eeaf41e6
Merge pull request #452 from sharifelgamal/cache-fix
Create cache directory if it doesn't already exist
2019-08-02 13:41:38 -07:00
Sharif Elgamal 8a24115b6a
Prevent panic on nil image 2019-08-02 13:25:20 -07:00
v.rul 7750094ec1 Add checking image presence in cache prior to downloading it
This changes allow to use kaniko-warmer multiple times without unnecessary docker image downloads.
To check image presence in cache directory I'm using existing cache function that is used by kaniko-executor.
I've considered building separate function to only check image presence, but it will have pretty much the same code.
Questionable decision is to embed CacheOptions type to KanikoOptions and WarmerOptions. Probably this should be resolved by creating interface providing needed options and implement it both mentioned structs. But I've struggled to get a meaningfull name to it.
To replicate previous behaviour of downloading regardless of cache state I've added --force(-f) option.

This changes provides crucial speed-up when downloading images from remote registry is slow.

Closes #722
2019-07-24 18:09:21 +03:00
tralexa 66a052255f
Insecure is now honored 2019-06-02 12:24:22 +03:00
Taylor Barrella 5c0603a967 Update go-containerregistry
Resolves #607

* Deleted a duplicate Gopkg.lock block for github.com/otiai10/copy to
  prevent `dep ensure` from deleting it from vendor/

* Searched for breaking changes. Only found ones for
  remote.Delete/List/Write/WriteIndex. Searched for those and fixed

* Noticed that NewInsecureRegistry was deprecated and replaced it
2019-05-25 15:56:20 -07:00
dlorenc 4b7e2b3a06
Update the cache warmer to also save manifests. (#576) 2019-02-21 14:09:22 -06:00
dlorenc 378a3f9573
Look for manifests in the local cache next to the full images. (#570)
Calculating a manifest from a v1.tarball is very expensive. We can
store those locally as well, and use them if they exist.

This should eventually be replaced with oci layout support once that exists
in ggcr.
2019-02-19 13:54:41 -06:00
Fredrik Lönnegren 1b54bda32e Fix typo 2019-02-19 16:43:20 +01:00
James Rawlings af50bcec69 let's return errors when warming a cache (#553)
* let's return errors when warming a cache

* Fix lint error in warm.go
2019-02-08 15:14:53 -06:00
Daisuke Taniwaki f8f59ea4c6 Add insecure-registry and tls-skip-verify-registry flags (#537) 2019-01-29 13:29:47 -06:00
dlorenc fcd1976d3b
Make the Digest calculation faster for locally-cached images. (#534)
Right now when we find a v1.Tarball in the local disk cache, we
recompute the digest. This is very expensive and redundant, because
we store tarballs by their digest and use that as a key to look them up.
2019-01-22 13:28:21 -06:00
dlorenc 996bec885f
Refactor our credential fetching to only get k8s credentials if we are on k8s. (#522) 2019-01-11 11:36:43 -07:00
Sharif Elgamal 29b7c3e879
Adding TTL to caching (#488)
* Adding TTL to caching

* uncomment added lines

* cache TTL works for layers now

* remove debugging

* parse booleans correctly

* parse booleans correctly everywhere

* fix boolean parsing condition

* refactor benchmarking calls

* defer file properly
2018-12-13 14:20:25 -08:00
dlorenc 52a6ce6685
More cache cleanups: (#397)
- move the layer cache to an interface
- refactor the DockerCommand implementations to support Cached and non-cached implementations.
2018-11-01 09:11:21 -07:00
Sharif Elgamal effac9dfc3
Persistent volume caching for base images (#383)
* comments

* initial commit for persisent volume caching

* cache warmer works

* general cleanup

* adding some debugging

* adding missing files

* Fixing up cache retrieval and cleanup

* fix tests

* removing auth since we only cache public images

* simplifying the caching logic

* fixing logic

* adding volume cache to integration tests. remove auth from cache warmer image.

* add building warmer to integration-test

* move sample yaml files to examples dir

* small test fix
2018-10-11 13:38:05 -07:00
Priya Wadhwa e2ca1152f4 Rename flags and default caching to false
Rename --use-cache to --cache, and --cache to --cache-repo to clarify
what the flags are used for. Default caching to false.
2018-09-24 13:18:42 -07:00
Priya Wadhwa f7ba67ea25 Specify cache key to differentiate cache layers 2018-09-14 09:53:03 -07:00
Priya Wadhwa c216fbf91b Add layer caching to kaniko
To add layer caching to kaniko, I added two flags: --cache and
--use-cache.

If --use-cache is set, then the cache will be used, and if --cache is
specified then that repo will be used to store cached layers. If --cache
isn't set, a cache will be inferred from the destination provided.

Currently, caching only works for RUN commands. Before executing the
command, kaniko checks if the cached layer exists. If it does, it pulls
it and extracts it. It then adds those files to the snapshotter and
append a layer to the config history.  If the cached layer does not exist, kaniko executes the command and
pushes the newly created layer to the cache.

All cached layers are tagged with a stable key, which is built based off
of:

1. The base image digest
2. The current state of the filesystem
3. The current command being run
4. The current config file (to account for metadata changes)

I also added two integration tests to make sure caching works

1. Dockerfile_test_cache runs 'date', which should be exactly the same
the second time the image is built
2. Dockerfile_test_cache_install makes sure apt-get install can be
reproduced
2018-09-13 18:32:53 -07:00