From 22bcd28931305ff68127ad55948038f5875030e9 Mon Sep 17 00:00:00 2001 From: Josh Soref Date: Sat, 21 Dec 2019 15:54:23 -0500 Subject: [PATCH] Grammar (#911) * spelling: environment * spelling: into * spelling: certificate * grammar: based on * spelling: its * spelling: non-root * grammar: unnecessary comma in a compound predicate * grammar: comma after introductory phrase * grammar: pronoun problem (per app.grammarly.com) --- README.md | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/README.md b/README.md index 5f51d57cf..095a1bb20 100644 --- a/README.md +++ b/README.md @@ -153,7 +153,7 @@ If you don't specify a prefix, kaniko will assume a local directory. For example, to use a GCS bucket called `kaniko-bucket`, you would pass in `--context=gs://kaniko-bucket/path/to/context.tar.gz`. ### Using Azure Blob Storage -If you are using Azure Blob Storage for context file, you will need to pass [Azure Storage Account Access Key](https://docs.microsoft.com/en-us/azure/storage/common/storage-configure-connection-string?toc=%2fazure%2fstorage%2fblobs%2ftoc.json) as an evironment variable named `AZURE_STORAGE_ACCESS_KEY` through Kubernetes Secrets +If you are using Azure Blob Storage for context file, you will need to pass [Azure Storage Account Access Key](https://docs.microsoft.com/en-us/azure/storage/common/storage-configure-connection-string?toc=%2fazure%2fstorage%2fblobs%2ftoc.json) as an environment variable named `AZURE_STORAGE_ACCESS_KEY` through Kubernetes Secrets ### Using Private Git Repository You can use `Personal Access Tokens` for Build Contexts from Private Repositories from [GitHub](https://blog.github.com/2012-09-21-easier-builds-and-deployments-using-git-over-https-and-oauth/). @@ -293,7 +293,7 @@ Before executing a command, kaniko checks the cache for the layer. If it exists, kaniko will pull and extract the cached layer instead of executing the command. If not, kaniko will execute the command and then push the newly created layer to the cache. -Users can opt in to caching by setting the `--cache=true` flag. +Users can opt into caching by setting the `--cache=true` flag. A remote repository for storing cached layers can be provided via the `--cache-repo` flag. If this flag isn't provided, a cached repo will be inferred from the `--destination` provided. @@ -343,7 +343,7 @@ Run kaniko with the `config.json` inside `/kaniko/.docker/config.json` #### Pushing to Amazon ECR -The Amazon ECR [credential helper](https://github.com/awslabs/amazon-ecr-credential-helper) is built in to the kaniko executor image. +The Amazon ECR [credential helper](https://github.com/awslabs/amazon-ecr-credential-helper) is built into the kaniko executor image. To configure credentials, you will need to do the following: 1. Update the `credHelpers` section of [config.json](https://github.com/awslabs/amazon-ecr-credential-helper#configuration) with the specific URI of your ECR registry: @@ -408,7 +408,7 @@ You can set it multiple times for multiple arguments. #### --cache -Set this flag as `--cache=true` to opt in to caching with kaniko. +Set this flag as `--cache=true` to opt into caching with kaniko. #### --cache-dir @@ -418,7 +418,7 @@ _This flag must be used in conjunction with the `--cache=true` flag._ #### --cache-repo -Set this flag to specify a remote repository which will be used to store cached layers. +Set this flag to specify a remote repository that will be used to store cached layers. If this flag is not provided, a cache repo will be inferred from the `--destination` flag. If `--destination=gcr.io/kaniko-project/test`, then cached layers will be stored in `gcr.io/kaniko-project/test/cache`. @@ -457,7 +457,7 @@ You can set it multiple times for multiple registries. #### --skip-tls-verify-registry -Set this flag to skip TLS cerificate validation when accessing a registry. It is supposed to be used for testing purposes only and should not be used in production! +Set this flag to skip TLS certificate validation when accessing a registry. It is supposed to be used for testing purposes only and should not be used in production! You can set it multiple times for multiple registries. #### --cleanup @@ -513,7 +513,7 @@ Set this flag as `--verbosity=` to set the lo ### Debug Image -The kaniko executor image is based off of scratch and doesn't contain a shell. +The kaniko executor image is based on scratch and doesn't contain a shell. We provide `gcr.io/kaniko-project/executor:debug`, a debug image which consists of the kaniko executor image along with a busybox shell to enter. You can launch the debug image with a shell entrypoint: @@ -530,7 +530,7 @@ kaniko relies on the security features of your container runtime to provide buil The minimum permissions kaniko needs inside your container are governed by a few things: -* The permissions required to unpack your base image into it's container +* The permissions required to unpack your base image into its container * The permissions required to execute the RUN commands inside the container If you have a minimal base image (SCRATCH or similar) that doesn't require @@ -555,7 +555,7 @@ Similar tools include: All of these tools build container images with different approaches. -BuildKit (and `img`) can perform as a non root user from within a container, but requires +BuildKit (and `img`) can perform as a non-root user from within a container but requires seccomp and AppArmor to be disabled to create nested containers. `kaniko` does not actually create nested containers, so it does not require seccomp and AppArmor to be disabled. @@ -568,7 +568,7 @@ builds can be done entirely without privilege). `umoci` works without any privileges, and also has no restrictions on the root filesystem being extracted (though it requires additional handling if your -filesystem is sufficiently complicated). However it has no `Dockerfile`-like +filesystem is sufficiently complicated). However, it has no `Dockerfile`-like build tooling (it's a slightly lower-level tool that can be used to build such builders -- such as `orca-build`). @@ -600,7 +600,7 @@ To Contribute to kaniko, see [DEVELOPMENT.md](DEVELOPMENT.md) and [CONTRIBUTING. When taking a snapshot, kaniko's hashing algorithms include (or in the case of [`--snapshotMode=time`](#--snapshotmode), only use) a file's [`mtime`](https://en.wikipedia.org/wiki/Inode#POSIX_inode_description) to determine -if the file has changed. Unfortunately there is a delay between when changes to a +if the file has changed. Unfortunately, there is a delay between when changes to a file are made and when the `mtime` is updated. This means: * With the time-only snapshot mode (`--snapshotMode=time`), kaniko may miss changes