Whether you love or hate containers, there are only a handful of ways to work with them properly that ensures proper application use with Docker. While there do exist a handful of solutions on the web and on the cloud to deal with all the needs that come with running Docker, Kaniko has something amazing to offer.
Kaniko was released as a standalone addition through the Google cloud interface and has been inducted under the Cloud Native Computing Foundation(CNCF). Kaniko as a tool helps users to build containerized images from their Docker applications through the Dockerfiles. It doesn’t require any standalone Docker run daemon’s to process it through.
Let’s take a more defined look at some of it’s more undiscussed elements, advantages and demerits.
The Problems People Run Into With Docker
Docker has become an industry standard with a multitude of uses and benefits but still has cross dependency issues due to the need for a DockerFile to rely upon interactive access to a Docker daemon. This essentially requires root access on your machine to run.
Users can thus run into problems for making containerized images in environments that don’t provide any support or can’t run the Docker daemons. Kubernetes clusters are a good example of this.
Kanniko, services these issues by creating a method to convert the container images from a Dockerfile even in the absence of any privileged root access. Users can use Kaniko to build an image from a Dockerfile and push it to a registry all in one go. Since it doesn’t require any special privileges or permissions, it can be installed and run on a typical Kubernetes cluster, Google Kubernetes Engine, or in any environment that lacks access control.
Docker vs Kaniko Source: Stackshare
Kaniko is usually run as a container itself, and needs the following information to build a docker image as per the user requirements:-
The path to Dockerfile.
The path to build a context (workspace) directory. The build context directory is a repository that contains all the necessary resources that are required while building an image.
Destination/URL of the repository where the image will be pushed after the execution completes.
How Does Kaniko Work Exactly?
Kaniko can be run as a container image that takes in the three arguments as previously seen. Once this information has been included to the main registry, the final push will contain only a static Go binary plus the configuration files needed for pushing and pulling images.
The Kaniko executor then finds and extracts the base image file system to the root, which is the image in the FROM line of the Dockerfile. It executes each command in order, and takes a snapshot of the file system after each command.
The snapshot created is then fed into a user-space by running the filesystem and comparing it to the prior state that was stored in memory. Kaniko then combines any changes made to the filesystem as a new layer to the original image. These changes are also reflected in the image metadata. After executing every command in the Dockerfile, the user is then free to push the newly built image to the output registry.
Kaniko unpacks the filesystem, executes commands and creates a copy of the filesystem completely in the user-space within the requirements of the user’s image, which is how it bypasses the needs for any privilege access needs on the machine where it is being deployed. The docker daemon or CLI is not involved in this entire process.
Image Container Creation Steps Source: Google CloudOps
The Merits and Pitfalls of Kaniko
Kaniko’s serverless all in one solution for handling container issues seems like a welcoming change from the more convoluted mess that users face when using Kubernetes or Docker. The lack of root access needs in clusters combined with a simpler interface for languages makes Kaniko an amazing tool to use, especially for software engineers who need fast acting methods to copy and deploy applications through a common Docker setup. Since there’s no dependency on the daemon process, users are free to run Kaniko in any kind of environment.
Kaniko executes each command within the Dockerfile completely in the userspace using an executor image: gcr.io/kaniko-project/executor which is often made to run inside the container. Kaniko then uses the system interface to run commands inside the Dockerfile and creates a copy of the file system after each command.
If there are changes to the file system, the executor pipeline takes a snapshot of the filesystem change and reports it as a “diff” layer. These changes are later made permanent in the image metadata. This brings another merit for using Kaniko which is a seamless mechanism to execute files and run applications.
Some backlash for the system seems to be pitched at the build for Kaniko taking up too many resources and execution time, depending on the applications which can make it unreliable when not working with a serverless platform with much needed computing. Most common build runs for Kaniko have been reported to be much slower compared to it’s cloud build. The general solution may be to simply stick to the cloud version but may not always be the best approach if cloud access isn’t always available.
Comparison between common tools Source: Slideshare
Final Thoughts and Review
If you still haven’t used Kaniko for easing the process of container image deployment and copying, it doesn’t hurt to take a small dive at community documentations and even running the application. Kaniko has a fairly simple syntax that can be run with just a few commands through the command line and has no major dependencies for it to be run.
Users shouldn’t be put off by the extreme dependence towards containers, seeing how resources can be better utilized if proper images can be built on top of them. As an application that is focused on Kubernetes and Docker, Kaniko has much to apply itself onto other common platforms and architectures.
For the novice or the expert, there are several resources available on the community pages and even on Google’s flagship website for Kaniko to get you started. Tune as we take a much needed look at other applications in the next articles.
Top comments (0)