Anda dapat menggunakan kaniko untuk membuat gambar Docker dalam wadah saat melakukan tanpa Docker. Mari cari tahu cara menjalankan kaniko secara lokal dan di cluster Kubernetes.
Berikutnya adalah buku multi
Misalkan Anda memutuskan untuk membuat gambar Docker di cluster Kubernetes (yah, Anda harus). Apa yang nyaman, mari kita lihat contoh nyata, jadi lebih jelas.
Kami juga akan berbicara tentang Docker-in-Docker dan alternatifnya, kaniko, yang dengannya Anda dapat membuat gambar Docker tanpa menggunakan Docker. Terakhir, kita akan belajar cara mengonfigurasi perakitan gambar di kluster Kubernetes.
Penjelasan umum tentang Kubernetes ada di buku "Kubernetes in Action" ("Kubernetes in Action") .
Contoh nyata
Di web asli, kami memiliki banyak gambar Docker pribadi yang perlu disimpan di suatu tempat. Jadi kami menerapkan Hub Docker pribadi. Docker Hub publik memiliki dua fitur yang sangat kami minati.
Pertama, kami ingin membuat antrian yang akan mengumpulkan gambar Docker di Kubernetes secara tidak sinkron. Kedua, mengimplementasikan pengiriman gambar yang dikumpulkan ke registri Docker pribadi.
Biasanya, Docker CLI digunakan secara langsung untuk mengimplementasikan fungsi-fungsi ini:
$ docker build ... $ docker push ...
Tetapi di kluster Kubernetes, kami meng-host kontainer berdasarkan gambar Linux kecil dan dasar, di mana Docker tidak terkandung secara default. Jika sekarang kita ingin menggunakan Docker (mis. Docker docker build... ) dalam sebuah wadah, kita memerlukan sesuatu seperti Docker-in-Docker.
Apa yang salah dengan Docker-in-Docker?
Untuk mengumpulkan gambar kontainer di Docker, kita memerlukan daemon Docker yang berjalan di dalam wadah, yaitu Docker-in-Docker. Daemon Docker adalah lingkungan tervirtualisasi, dan wadah di Kubernet divirtualisasi sendiri. Artinya, jika Anda ingin menjalankan daemon Docker dalam sebuah wadah, Anda perlu menggunakan virtualisasi bersarang. Untuk melakukan ini, jalankan wadah dalam mode khusus - untuk mendapatkan akses ke sistem host. Tapi ini menimbulkan masalah keamanan: misalnya, Anda harus bekerja dengan sistem file yang berbeda (host dan wadah) atau menggunakan cache build dari sistem host. Itu sebabnya kami tidak ingin menyentuh Docker-in-Docker.
Kenalan dengan kaniko
Bukan Docker-in-Docker saja ... Ada solusi lain - kaniko . Ini adalah alat yang ditulis dalam Go , ini mengumpulkan gambar wadah dari Dockerfile tanpa Docker. Kemudian mengirimkannya ke registri Docker yang ditentukan. Disarankan untuk mengonfigurasi kaniko - gunakan gambar pelaksana yang sudah jadi yang dapat dijalankan sebagai wadah Docker atau wadah di Kubernetes.
Ingatlah bahwa kaniko masih dalam pengembangan dan tidak mendukung semua perintah Dockerfile, misalnya --chownflag untuk COPY .
Kaniko diluncurkan
Jika Anda ingin menjalankan kaniko, Anda perlu menentukan beberapa argumen untuk wadah kaniko. Pertama-tama masukkan Dockerfile dengan semua dependensinya ke wadah kaniko. Secara lokal (di Docker), opsi -v <__>:<__> digunakan untuk ini -v <__>:<__> , dan Kubernetes memiliki volume .
Setelah memasukkan dependensi Dockerfile ke wadah kaniko, tambahkan argumen --context , itu akan menunjukkan jalur ke direktori terlampir (di dalam wadah). Argumen selanjutnya adalah --dockerfile . Ini menunjukkan jalur ke Dockerfile (termasuk nama). Argumen penting lainnya adalah --destination dengan URL lengkap ke registri Docker (termasuk nama dan tag gambar).
Peluncuran lokal
Kaniko dimulai dengan beberapa cara. Misalnya, di komputer lokal menggunakan Docker (agar tidak mengacaukan dengan kluster Kubernetes). Jalankan kaniko dengan perintah berikut:
$ docker run \ -v $(pwd):/workspace \ gcr.io/kaniko-project/executor:latest \ --dockerfile=<path-to-dockerfile> \ --context=/workspace \ --destination=<repo-url-with-image-name>:<tag>
Jika otentikasi diaktifkan di registri Docker, kaniko harus masuk terlebih dahulu. Untuk melakukan ini, hubungkan config.jsonfile Docker lokal dengan kredensial untuk registri Docker ke wadah kaniko menggunakan perintah berikut:
$ docker run \ -v $(pwd):/workspace \ -v ~/.docker/config.json:/kaniko/.docker/config.json \ gcr.io/kaniko-project/executor:latest \ --dockerfile=<path-to-dockerfile> \ --context=/workspace \ --destination=<repo-url-with-image-name>:<tag>
Luncurkan di Kubernetes
Dalam contoh, kami ingin menjalankan kaniko di kluster Kubernetes. Dan kami juga membutuhkan sesuatu seperti antrian untuk merakit gambar. Jika terjadi kegagalan saat merakit atau mengirim gambar ke registri Docker, alangkah baiknya jika proses dimulai lagi secara otomatis. Untuk ini, ada Pekerjaan di Kubernetes. Konfigurasikan backoffLimit dengan menentukan seberapa sering proses harus coba lagi.
Cara termudah untuk menanamkan Dockerfile dengan dependensi dalam wadah kaniko adalah dengan objek PersistentVolumeClaim (dalam contoh kami, ini disebut kaniko-workspace ). Ini akan terikat ke wadah sebagai direktori, dan semua data harus sudah ada di kaniko-workspace . Katakanlah di wadah lain sudah ada Dockerfile dengan dependensi di kaniko-workspace /my-build di kaniko-workspace .
Jangan lupa bahwa dalam kesulitan AWS dengan PersistentVolumeClaim. Jika Anda membuat PersistentVolumeClaim di AWS, itu akan muncul hanya pada satu node di AWS cluster dan hanya akan tersedia di sana. (upd: pada kenyataannya, ketika membuat PVC, volume RDS akan dibuat di zona ketersediaan acak cluster Anda. Dengan demikian, volume ini akan tersedia untuk semua mesin di zona ini. Kubernetes sendiri mengontrol bahwa di bawahnya menggunakan PVC ini akan diluncurkan pada sebuah simpul di zona ketersediaan. RDS volyuma. - kira-kira Per.) Jadi, jika Anda menjalankan Job kaniko dan tugas ini ada di node lain, itu tidak akan mulai, karena PersistentVolumeClaim tidak tersedia. Mari kita berharap bahwa Sistem File Elastis Amazon akan segera tersedia di Kubernetes dan masalahnya hilang. (Pembaruan: EFS di Kubernetes didukung oleh penyedia penyimpanan . - kira - kira )
Sumber daya pekerjaan untuk membuat gambar Docker biasanya terlihat seperti ini:
apiVersion: batch/v1 kind: Job metadata: name: build-image spec: template: spec: containers: - name: build-image image: gcr.io/kaniko-project/executor:latest args: - "--context=/workspace/my-build" - "--dockerfile=/workspace/my-build/Dockerfile" - "--destination=<repo-url-with-image-name>:<tag>" volumeMounts: - name: workspace mountPath: /workspace volumes: - name: workspace persistentVolumeClaim: claimName: kaniko-workspace restartPolicy: Never backoffLimit: 3
Jika registri Docker tujuan memerlukan otentikasi, berikan file config.json dengan kredensial ke wadah kaniko. Cara termudah adalah dengan menghubungkan PersistentVolumeClaim ke wadah yang sudah memiliki file config.json . Di sini PersistentVolumeClaim akan di-mount bukan sebagai direktori, melainkan sebagai file di path /kaniko/.docker/config.json dalam wadah kaniko:
apiVersion: batch/v1 kind: Job metadata: name: build-image spec: template: spec: containers: - name: build-image image: gcr.io/kaniko-project/executor:latest args: - "--context=/workspace/my-build" - "--dockerfile=/workspace/my-build/Dockerfile" - "--destination=<repo-url-with-image-name>:<tag>" volumeMounts: - name: config-json mountPath: /kaniko/.docker/config.json subPath: config.json - name: workspace mountPath: /workspace volumes: - name: config-json persistentVolumeClaim: claimName: kaniko-credentials - name: workspace persistentVolumeClaim: claimName: kaniko-workspace restartPolicy: Never backoffLimit: 3
Jika Anda ingin memeriksa status pekerjaan build yang kubectl , gunakan kubectl . Untuk memfilter status dengan stdout , jalankan perintah:
$ kubectl get job build-image -o go-template='{{(index .status.conditions 0).type}}'
Ringkasan
Anda belajar dari artikel ketika Docker-in-Docker tidak cocok untuk membangun gambar Docker di Kubernetes. Punya gagasan tentang kaniko - sebuah alternatif untuk Docker-in-Docker, yang dengannya gambar Docker tanpa Docker dirakit. Kami juga belajar cara menulis sumber daya Ayub untuk mengumpulkan gambar Docker di Kubernetes. Dan akhirnya, mereka melihat bagaimana mengetahui status tugas yang sedang berlangsung.