* Allow to disable the fallback to the default registry on image pull
When one or more registry mirror(s) are deffined with the 'registry-mirror' argument, if none of those mirrors include the image,
the current behavior is to fallback to the default registry.
If a whitelist (or some image restriction) is applied at the mirror side, fallbacking to the default registry makes that restriction useless.
This new argument allows to skip the fallback and abort the build if the mirror rejects an image.
If it is not set, is completelly transparent.
* fix typo on command help
* 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>
* 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
Describes work-around for #1803 - add an example of how to work around issues encountered out of the box when trying to pass build-args that contain spaces in their values
* Clarify usage of --skip-tls-verify-registry argument
Referring to --skip-tls-verify-registry as a "flag" is misleading since
command line flags usually require no value. Thus, the documentation
is updated to match the behavior of the command line argument.
* Clarify usage of --insecure-registry argument
Referring to --insecure-registry as a "flag" is misleading since
command line flags usually require no value. Thus, the documentation
is updated to match the behavior of the command line argument.
* Collapse integration test workflows into one config
Remove last traces of Travis, including env vars and `make travis-setup`
and badges in README
* fix lint
* make integration tests pass on PRs
* Remove tarball.WithCompressedCaching flag to resolve OOM Killed error
Large images cannot be build as the kaniko container will be killed due to an OOM error. Removing the tarball compression drastically reduces the memory required to push large image layers. Fixes#1680
This change may increase the build time for smaller images. Therefore a command line option to trigger the compression or a more intelligent behaviour may be useful.
* Add new command line flag to toggle compressed caching
* Add unittest for build with --compressed-caching command line flag set to false
Fixes#1473
The initial implementation of the registry mirror only allowed a single mirror, and if pulling from the mirror failed, the build would fail.
This change introduces:
- multiple registry mirrors instead of a single one
- fallback if an image can't be pulled from a registry
This is the same behavior as the docker daemon and will allow using a registry mirror such as `mirror.gcr.io` which is incomplete and doesn't have all the content that the default registry on docker.io has.
Note that there are no changes in the CLI flags, the `--registry-mirror` flag is still valid. But now it can be used multiple times to set up more than one registry mirror.
Co-authored-by: Tejal Desai <tejaldesai@google.com>
In the context of Docker Hub ratelimit, registry mirror has been applied
more and more. It's very unfortunate that kaniko doesn't take the same
form as docker/containerd. The registry mirror shouldn't have scheme
like `https://` included. This is not explicitly described in the doc.
Cached COPY layers are expensive in that they both need to be retrieved
over the network and occupy space in the layer cache.
They are unnecessary in that we already have all resources needed to
execute the COPY locally, and doing so is a trivial file-system
operation. This is in contrast to RUN layers, which can do
arbitrary and unbounded work.
The end result is that cached COPY commands were more expensive when
cached, not less. Remove them.
Resolves#1357
Hi there,
The preferred spelling seems to be all lowercase: I fixed those with uppercase K.
(Sorry for this modest intial contribution ;-) but I hope to come back with more..
Didier