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.