Skip to main content

Construction

Image building in Docker is the process of creating a container image that contains everything needed to run an application: from the base operating system to application-specific dependencies and configurations.

To do this in a Kubernetes we make use of the following tool:

Kaniko​

Kaniko is a fantastic tool for building container images within a Kubernetes environment without requiring root privileges! Here are some key details about Kaniko:

Key Features: Image Building in Kubernetes: Kaniko is a container image building tool that works in non-privileged environments, such as Kubernetes clusters. This means that it can run without the need for superuser access, making it ideal for controlled and more secure environments.

Dockerfile support: Uses the Dockerfile as the basis for building the image. It accepts the same syntax and commands as Docker to define the steps necessary to create the image.

Layer Caching: Kaniko employs an intelligent layer caching system that helps speed build times by leveraging existing cache layers for unchanged Dockerfile instructions.

Running as a Container: Runs as a container within the Kubernetes cluster. This means that the image construction is carried out in isolation from the host where it is running, which adds an additional layer of security and portability.

Benefits: Enhanced Security: By not requiring root privileges, Kaniko improves security when building images within restricted environments such as Kubernetes.

Portability: Allows building images without relying on a local environment, which facilitates portability and integration with CI/CD (Continuous Integration/Continuous Deployment) workflows.

Resource Optimization: By using Kubernetes, Kaniko efficiently leverages cluster resources to perform image building tasks, distributing the workload effectively.

Support for Private Repositories: You can authenticate and access private repositories to obtain base image layers during the build process.

Usage: To use Kaniko, you typically create a Kubernetes manifest (e.g., a YAML file) that describes the image build job using Kaniko as a pod within the cluster. This manifest specifies the location of the Dockerfile, the build context and other necessary details.

Community and Maintenance: Kaniko is an open source project maintained by the community and has an active user base. It is part of the Kubernetes ecosystem of tools and integrates well with modern CI/CD workflows.

Integration with Gitlab​

.gitlab-ci.yml
.docker_build:
  stage: build
  dependencies: ['pre_build_app']
  image:
    name: gcr.io/kaniko-project/executor@sha256:e935bfe222bc3ba84797e90a95fcfb1a63e61bcf81275c2cac5edfb0343b2e85
    entrypoint: [""]
  script:
    - mkdir tar_images
    - /kaniko/executor
      --context "${CI_PROJECT_DIR}"
      --dockerfile "${CI_PROJECT_DIR}/deployment/php/Dockerfile"
      --destination "${DOCKER_REGISTRY_URL}/osdo/osdo-app:${CI_COMMIT_TAG}" --no-push --tar-path tar_images/osdo_app.tar
  artifacts:
    paths:
      - tar_images
    when: on_success

Let's explain the most important things about this Job:

  • dependencies: ['pre_build_app']: The job .docker_build may have other associated dependencies if the application to be added to the container depends on previous jobs where the application was built for testing or compilation.

  • image: This job uses a base image to run Kaniko. The image used is gcr.io/kaniko-project/executor:latest.

  • script: In this section, the Docker image is built using Kaniko. The steps include creating a directory called tar_images, which is used to store the Docker image tar file. Kaniko is then executed with several arguments:

    • --context "${CI_PROJECT_DIR}": This specifies the build context as the root directory of the GitLab CI project.
    • --dockerfile "${CI_PROJECT_DIR}/deployment/php/Dockerfile": Here you provide the location of the Dockerfile that will be used to build the image. The Dockerfile is located in the deployment/php directory of the project.
    • --destination "${DOCKER_REGISTRY_URL}/osdo/osdo-app:${CI_COMMIT_TAG}": This defines the destination location where the built Docker image will be saved. It uses the URL of the Docker registry and adds a tag based on the tag of the current commit.
    • --no-push: This option prevents Kaniko from loading the image directly into a Docker registry. Instead, the image is saved in a local tar file.
    • --tar-path tar_images/osdo_app.tar: Specifies the location where the Docker image tar file will be saved, which is the tar_images directory.

  • artifacts: This section defines the artifacts that will be saved after this job is completed. In this case, the tar_images directory containing the Docker image tar file is being archived.

  • when: on_success: Indicates that artifacts will be saved only if this job runs successfully, which means that the Docker image was built successfully.