Sampeyan saiki bisa nggawe gambar Docker ing werf nggunakake Dockerfile biasa

Luwih becik telat tinimbang ora nate. Utawa carane meh nggawe kesalahan serius amarga ora duwe dhukungan kanggo Dockerfiles biasa kanggo mbangun gambar aplikasi.

Kita bakal ngomong babagan werf - Utilitas GitOps sing nggabungake karo sistem CI/CD lan nyedhiyakake manajemen kabeh siklus urip aplikasi, ngidini:

• ngumpulake lan nerbitake gambar,
• nyebarake aplikasi ing Kubernetes,
• mbusak gambar sing ora digunakake nggunakake kabijakan khusus.

Filosofi proyek kasebut yaiku kanggo ngumpulake alat tingkat rendah dadi sistem terpadu sing menehi insinyur DevOps ngontrol aplikasi. Yen bisa, utilitas sing ana (kayata Helm lan Docker) kudu digunakake. Yen ora ana solusi kanggo masalah, kita bisa nggawe lan ndhukung kabeh sing perlu kanggo iki.

Latar mburi: kolektor gambar sampeyan dhewe

Iki kedadeyan karo kolektor gambar ing werf: Dockerfile biasa ora cukup kanggo kita. Yen sampeyan ndeleng kanthi cepet babagan sejarah proyek kasebut, masalah iki wis muncul ing versi pisanan werf (banjur isih dikenal minangka dapp).

Nalika nggawe alat kanggo nggawe aplikasi menyang gambar Docker, kita cepet nyadari yen Dockerfile ora cocok kanggo kita kanggo sawetara tugas sing spesifik:

1. Kebutuhan kanggo mbangun aplikasi web cilik sing khas miturut skema standar ing ngisor iki:
   • nginstal dependensi aplikasi ing saindenging sistem,
   • nginstal kumpulan perpustakaan dependensi aplikasi,
   • ngumpulake aset,
   • lan sing paling penting, nganyari kode ing gambar kanthi cepet lan efisien.
2. Nalika owah-owahan digawe kanggo file project, pembangun kudu cepet nggawe lapisan anyar dening nglamar patch kanggo file diganti.
3. Yen file tartamtu wis diganti, iku perlu kanggo mbangun maneh tataran gumantung cocog.

Dina iki kolektor kita duwe akeh kemungkinan liyane, nanging iki minangka kepinginan lan panjaluk awal.

Umumé, tanpa mikir kaping pindho, kita bersenjata nganggo basa pamrograman sing digunakake (ndeleng ngisor) lan kenek dalan kanggo ngleksanakake DSL dhewe! Sesuai karo tujuane, tujuane kanggo njlèntrèhaké proses perakitan kanthi bertahap lan nemtokake dependensi tahapan kasebut ing file. Lan nglengkapi kolektor dhewe, sing ngowahi DSL dadi tujuan pungkasan - gambar sing dirakit. Ing kawitan DSL ana ing Ruby, nanging minangka transisi menyang Golang - konfigurasi kolektor kita wiwit diterangake ing file YAML.

Konfigurasi lawas kanggo dapp ing Ruby

Konfigurasi saiki kanggo werf ing YAML

Mekanisme kolektor uga diganti liwat wektu. Kaping pisanan, kita mung nggawe Dockerfile sauntara kanthi cepet saka konfigurasi kita, lan banjur miwiti instruksi perakitan ing wadhah sementara lan komitmen.

NB: Ing wayahe, kolektor kita, sing dianggo karo konfigurasi dhewe (ing YAML) lan disebut kolektor Stapel, wis dikembangaké dadi alat cukup kuat. Katrangan rinci kasebut pantes kanggo artikel sing kapisah, lan rincian dhasar bisa ditemokake ing dokumentasi.

Kesadaran masalah

Nanging kita nyadari, lan ora langsung, yen kita wis salah: kita ora nambah kemampuan mbangun gambar liwat Dockerfile standar lan nggabungake menyang infrastruktur manajemen aplikasi end-to-end sing padha (yaiku ngumpulake gambar, nyebarake lan ngresiki). Kepiye carane bisa nggawe alat kanggo penyebaran ing Kubernetes lan ora ngetrapake dhukungan Dockerfile, yaiku. cara standar kanggo njlèntrèhaké gambar kanggo paling proyèk?..

Tinimbang njawab pitakonan iki, kita menehi solusi. Apa yen sampeyan wis duwe Dockerfile (utawa sakumpulan Dockerfiles) lan pengin nggunakake werf?

NB: Oalah, kok malah arep nganggo werf? Fitur utama yaiku ing ngisor iki:

• siklus manajemen aplikasi lengkap kalebu reresik gambar;
• kemampuan kanggo ngatur perakitan sawetara gambar bebarengan saka konfigurasi siji;
• Proses penyebaran luwih apik kanggo grafik sing cocog karo Helm.

Daftar sing luwih lengkap bisa ditemokake ing kaca proyek.

Dadi, yen sadurunge kita bakal menehi nulis ulang Dockerfile ing konfigurasi kita, saiki kita bakal seneng ngomong: "Ayo werf mbangun Dockerfiles sampeyan!"

Carane nggunakake?

Implementasi lengkap fitur iki muncul ing release werf v1.0.3-beta.1. Prinsip umum iku prasaja: pangguna nemtokake dalan menyang Dockerfile sing ana ing konfigurasi werf, banjur mbukak perintah kasebut. werf build... lan iku - werf bakal ngumpul gambar. Ayo ndeleng conto abstrak.

Ayo padha ngumumake sabanjure Dockerfile ing root proyek:

FROM ubuntu:18.04
RUN echo Building ...

Lan kita bakal ngumumake werf.yamlkang nggunakake iki Dockerfile:

configVersion: 1
project: dockerfile-example
---
image: ~
dockerfile: ./Dockerfile

Kabeh! Ngiwa mlayu werf build:

Kajaba iku, sampeyan bisa ngumumake ing ngisor iki werf.yaml kanggo mbangun sawetara gambar saka macem-macem Dockerfiles bebarengan:

configVersion: 1
project: dockerfile-example
---
image: backend
dockerfile: ./dockerfiles/Dockerfile-backend
---
image: frontend
dockerfile: ./dockerfiles/Dockerfile-frontend

Pungkasan, uga ndhukung paramèter mbangun tambahan, kayata --build-arg и --add-host - liwat konfigurasi werf. Katrangan lengkap babagan konfigurasi gambar Dockerfile kasedhiya ing kaca dokumentasi.

Carane ora iku bisa?

Sajrone proses mbangun, cache standar lapisan lokal ing Docker fungsi. Nanging, sing penting yaiku werf uga nggabungake konfigurasi Dockerfile menyang infrastruktur. Apa tegese iki?

1. Saben gambar sing dibangun saka Dockerfile dumadi saka siji tahapan sing diarani dockerfile (sampeyan bisa maca liyane babagan apa tahapan ing werf kene).
2. Kanggo panggung dockerfile werf ngitung teken sing gumantung ing isi konfigurasi Dockerfile. Nalika konfigurasi Dockerfile diganti, tandha panggung ganti dockerfile lan werf miwiti mbangun maneh tahap iki kanthi konfigurasi Dockerfile anyar. Yen teken ora ngganti, banjur werf njupuk gambar saka cache (rincian liyane babagan panggunaan teken ing werf diterangake ing laporan iki).
3. Sabanjure, gambar sing diklumpukake bisa diterbitake kanthi printah werf publish (utawa werf build-and-publish) lan gunakake kanggo penyebaran menyang Kubernetes. Gambar sing diterbitake menyang Docker Registry bakal diresiki nggunakake alat pembersihan werf standar, yaiku. Gambar lawas (lawas saka N dina), gambar sing digandhengake karo cabang Git sing ora ana, lan kabijakan liyane bakal diresiki kanthi otomatis.

Rincian liyane babagan poin sing diterangake ing kene bisa ditemokake ing dokumentasi:

• Proses penerbitan;
• Integrasi karo proses panyebaran Kubernetes;
• Proses reresik.

Cathetan lan pancegahan

1. URL njaba ora didhukung ing ADD

Saiki ora didhukung kanggo nggunakake URL eksternal ing arahan ADD. Werf ora bakal miwiti mbangun maneh nalika sumber ing URL kasebut diganti. We rencana kanggo nambah fitur iki rauh.

2. Sampeyan ora bisa nambah .git kanggo gambar

Umumé, nambah direktori .git ing gambar - laku ala ganas lan kene sebabe:

1. yen .git tetep ing gambar final, iki nglanggar prinsip 12 faktor app: Wiwit gambar final kudu disambung menyang commit siji, iku ngirim ora bisa kanggo nindakake git checkout sewenang-wenang.
2. .git nambah ukuran gambar (gudang bisa gedhe amarga kasunyatan sing file gedhe wis tau ditambahake lan banjur dibusak). Ukuran wit kerja sing mung ana gandhengane karo komitmen tartamtu ora bakal gumantung ing riwayat operasi ing Git. Ing kasus iki, tambahan lan mbusak sakteruse .git saka gambar final ora bakal bisa: gambar isih ndarbeni lapisan ekstra - iki carane Docker dianggo.
3. Docker bisa miwiti mbangun maneh sing ora perlu, sanajan komitmen sing padha dibangun, nanging saka wit kerja sing beda. Contone, GitLab nggawe direktori kloning sing kapisah ing /home/gitlab-runner/builds/HASH/[0-N]/yourproject nalika rakitan paralel diaktifake. Reassembly ekstra bakal amarga kasunyatan sing direktori .git beda ing versi kloning sing beda saka gudang sing padha, sanajan komit sing padha dibangun.

Titik pungkasan uga duwe akibat nalika nggunakake werf. Werf mbutuhake cache sing dibangun nalika nindakake sawetara perintah (contone. werf deploy). Nalika printah iki mbukak, werf ngetung teken panggung kanggo gambar kasebut ing werf.yaml, lan kudu ana ing cache perakitan - yen prentah ora bisa terus digunakake. Yen tandha panggung gumantung isi .git, banjur entuk cache sing ora stabil kanggo owah-owahan ing file sing ora relevan, lan werf ora bakal bisa ngapura kesalahan kasebut (kanggo rincian liyane, deleng dokumentasi).

Umumé mung nambah file tartamtu sing perlu liwat instruksi ADD ing kasus nambah efficiency lan linuwih saka ditulis Dockerfile, lan uga nambah stabilitas cache sing diklumpukake kanggo iki Dockerfile, kanggo owah-owahan sing ora relevan ing Git.

Asile

Path awal kanggo nulis pembangun dhewe kanggo kabutuhan tartamtu angel, jujur ​​lan langsung: tinimbang nggunakake kruk ing ndhuwur Dockerfile standar, kita nulis solusi nganggo sintaks khusus. Lan iki duwe kaluwihan: kolektor Stapel ngrampungake tugas kanthi sampurna.

Nanging, ing proses nulis pembangun kita dhewe, kita ora ngerti dhukungan kanggo Dockerfiles sing ana. Cacat iki saiki wis didandani, lan ing mangsa ngarep kita bakal ngembangake dhukungan Dockerfile bebarengan karo pembangun Stapel khusus kanggo mbangun sing disebarake lan kanggo mbangun nggunakake Kubernetes (yaiku mbangun ing pelari ing Kubernetes, kaya sing ditindakake ing kaniko).

Dadi, yen sampeyan dumadakan duwe sawetara Dockerfiles sing ana ... nyoba werf!

PS Dhaptar dokumentasi ing topik

• Panuntun kanggo wiwitan cepet;
• konfigurasi dockerfile builder;
• Tahap piranti ing werf;
• Proses penerbitan gambar;
• Integrasi karo proses panyebaran Kubernetes;
• Proses reresik;
• Stapel builder minangka alternatif kanggo Dockerfile.

Waca uga ing blog kita: "werf - alat kita kanggo CI/CD ing Kubernetes (review lan laporan video)".

Source: www.habr.com