[Kaniko]Hướng dẫn build image docker chạy trong container

Sử dụng Kaniko image container bên container hay trong k8s.

Video giải thích:

Các thông tin repository push image lên repository (docker hub, harbor)

kubectl create -n kanik secret \
docker-registry regcred \
--docker-server=https://docker.nimtechnology.com \
--docker-username=nim \
--docker-password=123456 \
--docker-email=mr.nim94@gmail.com

Manifest Pop và run k8s.
Pod này sẽ clone code từ git, check login vào repo.
Build image theo Dockerfile rồi push lên docker hub.

apiVersion: v1
kind: Pod
metadata:
  name: kaniko
spec:
  containers:
  - name: kaniko
    image: gcr.io/kaniko-project/executor:debug
    args: ["--context=git://github.com/vfarcic/kaniko-demo",
            "--destination=docker.nimtechnology.com/hometest/devops-toolkit:1.0.0"]
    volumeMounts:
      - name: kaniko-secret
        mountPath: /kaniko/.docker
  restartPolicy: Never
  volumes:
    - name: kaniko-secret
      secret:
        secretName: regcred
        items:
          - key: .dockerconfigjson
            path: config.json

Đây là log chạy

Sau khi pod chạy xong.

Links tham khảo thêm

https://gist.github.com/vfarcic/627fcfbfbc17a683a70210947e02eaa3

https://github.com/vfarcic/kaniko-demo

Build image docker with Kaniko and Argo Workflow.

    - name: build
      inputs:
        parameters:
          - name: oci-image
            value: ""
          - name: oci-tag
            value: ""
      container:
        image: gcr.io/kaniko-project/executor:latest
        args:
          - --context=/workdir/tools
          - --dockerfile=integration_test/docker/Dockerfile
          - --no-push
          - --tar-path=/workdir/.tar
        workingDir: /workdir
        volumeMounts:
          - name: workdir
            mountPath: /workdir

Certainly! Let’s delve into examples to illustrate how the --context and --dockerfile arguments are used with Kaniko, a tool for building Docker images.

Example 1: Basic Use

Suppose you have a project with the following structure:

/myproject
│
├── Dockerfile
└── src
    ├── app.py
    └── requirements.txt

• Dockerfile: Contains instructions to build your Docker image.
• src: Directory containing your application code.

In this case, the Dockerfile is in the root of your project (/myproject). To build this with Kaniko, your arguments might look like:

args:
  - --context=/myproject
  - --dockerfile=Dockerfile

• --context=/myproject: Tells Kaniko that the build context (source files including the Dockerfile) is located in the /myproject directory.
• --dockerfile=Dockerfile: Specifies that the Dockerfile is named “Dockerfile” and is located at the root of the context directory.

Example 2: Nested Dockerfile

Consider a more complex project structure:

/myproject
│
├── app
│   └── src
│       ├── app.py
│       └── requirements.txt
└── docker
    └── python
        └── Dockerfile

Here, the Dockerfile is not in the root but inside a nested directory (/myproject/docker/python). To build this, your Kaniko arguments would change:

args:
  - --context=/myproject
  - --dockerfile=docker/python/Dockerfile

• --context=/myproject: The build context includes the entire /myproject directory, encompassing both the application source code and the Dockerfile.
• --dockerfile=docker/python/Dockerfile: Specifies the path to the Dockerfile relative to the context directory.

In this second example, although the Dockerfile is not in the root of the context, Kaniko can still locate it because you provide the relative path to the Dockerfile from the context’s root.

These examples demonstrate how the --context and --dockerfile arguments are used to tell Kaniko where to find the Dockerfile and the build context in different project structures. This flexibility allows Kaniko to be integrated into various CI/CD workflows, accommodating a wide range of project layouts.