Leuwih hade telat tinimbang henteu kungsi. Atanapi kumaha urang ampir ngalakukeun kasalahan anu serius ku henteu gaduh dukungan pikeun Dockerfiles biasa pikeun ngawangun gambar aplikasi.
Urang bakal ngobrol ngeunaan - Utilitas GitOps anu ngahijikeun sareng sistem CI / CD naon waé sareng nyayogikeun manajemén sadaya siklus kahirupan aplikasi, ngamungkinkeun:
- ngumpulkeun sareng nyebarkeun gambar,
- nyebarkeun aplikasi dina Kubernetes,
- mupus gambar anu henteu kapake nganggo kawijakan khusus.
Filosofi proyék nyaéta pikeun ngumpulkeun alat tingkat rendah kana sistem ngahijikeun tunggal anu masihan insinyur DevOps ngadalikeun aplikasi. Upami mungkin, utilitas anu tos aya (sapertos Helm sareng Docker) kedah dianggo. Upami teu aya solusi pikeun masalah, urang tiasa nyiptakeun sareng ngadukung sadayana anu dipikabutuh pikeun ieu.
Latar: kolektor gambar anjeun sorangan
Ieu anu kajantenan sareng kolektor gambar di werf: Dockerfile biasa henteu cekap pikeun urang. Upami anjeun gancang ningali sajarah proyék, masalah ieu parantos muncul dina versi awal werf (teras tetep ).
Nalika nyiptakeun alat pikeun ngawangun aplikasi kana gambar Docker, kami gancang sadar yén Dockerfile henteu cocog pikeun kami pikeun sababaraha tugas anu khusus:
- Kabutuhan pikeun ngawangun aplikasi wéb leutik anu khas dumasar kana skéma standar ieu:
- pasang katergantungan aplikasi di sakumna sistem,
- pasang sakumpulan perpustakaan dependensi aplikasi,
- ngumpulkeun aset,
- jeung paling importantly, update kode dina gambar gancang jeung éfisién.
- Nalika parobihan dilakukeun kana file proyék, pembina kedah gancang nyiptakeun lapisan énggal ku cara nerapkeun patch kana file anu dirobih.
- Upami file-file anu tangtu parantos robih, maka anjeun kedah ngawangun deui tahap gumantungna anu saluyu.
Dinten collector urang boga loba kemungkinan sejen, tapi ieu kahayang jeung pangjurung awal.
Sacara umum, tanpa mikir dua kali, urang angkatan diri sareng basa pamrograman anu kami anggo (tingali kahandap) sarta pencét jalan pikeun nerapkeun DSL sorangan! Luyu sareng tujuan, éta dimaksudkeun pikeun ngajelaskeun prosés perakitan sacara bertahap sareng nangtukeun katergantungan tahapan ieu dina file. Jeung complemented eta kolektor sorangan, anu ngancik DSL kana tujuan ahir - gambar anu dirakit. Mimitina DSL éta di Ruby, tapi sakumaha - konfigurasi kolektor urang mimiti dijelaskeun dina file YAML.
config heubeul pikeun dapp di Ruby
config ayeuna keur werf on YAML
Mékanisme kolektor ogé robah kana waktu. Mimitina, urang ngan saukur ngahasilkeun Dockerfile samentawis dina laleur tina konfigurasi urang, teras urang mimiti ngajalankeun paréntah perakitan dina wadah samentawis sareng komitmen.
NB: Di momen, kolektor urang, nu gawéna kalayan config sorangan (dina YAML) jeung disebut collector Stapel, geus dimekarkeun jadi alat cukup kuat. Katerangan lengkepna pantes pikeun tulisan anu misah, sareng detil dasar tiasa dipendakan dina .
Kasadaran ngeunaan masalah
Tapi kami sadar, sareng henteu langsung, yén kami parantos ngalakukeun hiji kasalahan: kami henteu nambihan kamampuan ngawangun gambar via Dockerfile standar sarta ngahijikeun kana infrastruktur manajemén aplikasi tungtung-to-tungtung sarua (ie ngumpulkeun gambar, nyebarkeun jeung ngabersihan aranjeunna). Kumaha éta tiasa ngadamel alat pikeun panyebaran di Kubernetes sareng henteu ngalaksanakeun dukungan Dockerfile, i.e. cara standar pikeun ngajelaskeun gambar pikeun kalolobaan proyék?
Gantina ngajawab patarosan ieu, kami nawiskeun solusi. Kumaha upami anjeun parantos gaduh Dockerfile (atanapi sakumpulan Dockerfiles) sareng hoyong nganggo werf?
NB: Ku jalan kitu, naha anjeun malah hoyong nganggo werf? Fitur utama turun ka handap:
- siklus manajemén aplikasi pinuh kaasup beberesih gambar;
- kamampuhan pikeun ngatur assembly sababaraha gambar sakaligus ti config tunggal;
- Ningkatkeun prosés panyebaran pikeun grafik anu cocog sareng Helm.
Daptar langkung lengkep aranjeunna tiasa dipendakan di .
Janten, upami sateuacana urang bakal nawiskeun nyerat ulang Dockerfile dina konfigurasi urang, ayeuna urang bakal bagja nyarios: "Hayu werf ngawangun Dockerfiles anjeun!"
Kumaha carana make?
Palaksanaan pinuh ku fitur ieu muncul dina sékrési éta . Prinsip umumna basajan: pangguna netepkeun jalur ka Dockerfile anu tos aya dina konfigurasi werf, teras ngajalankeun paréntahna werf build... tur éta - werf bakal ngumpul gambar. Hayu urang nempo conto abstrak.
Hayu urang ngumumkeun salajengna Dockerfile dina akar proyék:
FROM ubuntu:18.04
RUN echo Building ...
Sarta kami bakal ngumumkeun werf.yamlnu ngagunakeun ieu Dockerfile:
configVersion: 1
project: dockerfile-example
---
image: ~
dockerfile: ./Dockerfile
Sadayana! Kénca lumpat werf build:
Salaku tambahan, anjeun tiasa nyatakeun di handap ieu werf.yaml pikeun ngawangun sababaraha gambar tina Dockerfiles anu béda sakaligus:
configVersion: 1
project: dockerfile-example
---
image: backend
dockerfile: ./dockerfiles/Dockerfile-backend
---
image: frontend
dockerfile: ./dockerfiles/Dockerfile-frontend
Tungtungna, éta ogé ngadukung ngalangkungan parameter ngawangun tambahan, sapertos --build-arg и --add-host - via werf config. Katerangan lengkep ngeunaan konfigurasi gambar Dockerfile sayogi di .
Kumaha carana sangkan eta pagawean?
Salila prosés ngawangun, cache standar lapisan lokal dina fungsi Docker. Nanging, anu penting nyaéta yén éta ogé integrates konfigurasi Dockerfile kana infrastruktur na. Naon ieu hartosna?
- Unggal gambar diwangun ti Dockerfile diwangun ku hiji tahap disebut
dockerfile(Anjeun tiasa maca langkung seueur ngeunaan tahapan naon dina werf ). - Pikeun panggung
dockerfilewerf ngitung tanda tangan anu gumantung kana eusi konfigurasi Dockerfile. Nalika konfigurasi Dockerfile robih, tanda tangan panggung robihdockerfilesareng werf ngamimitian ngawangun deui tahap ieu sareng konfigurasi Dockerfile énggal. Upami tanda tangan henteu robih, maka werf nyandak gambar tina cache (detail langkung seueur ngeunaan panggunaan tanda tangan dina werf dijelaskeun dina ). - Salajengna, gambar anu dikumpulkeun tiasa diterbitkeun nganggo paréntah
werf publish(atawawerf build-and-publish) sareng dianggo pikeun nyebarkeun ka Kubernetes. Gambar anu diterbitkeun ka Docker Registry bakal dibersihkeun nganggo alat pembersihan werf standar, nyaéta. Gambar heubeul (leuwih heubeul ti N poé), gambar pakait sareng cabang Git non-existent, sarta kawijakan séjén bakal otomatis cleaned.
Langkung rinci ngeunaan titik anu dijelaskeun di dieu tiasa dipendakan dina dokuméntasi:
- ;
- ;
- .
Catetan jeung precautions
1. URL éksternal henteu dirojong dina ADD
Ayeuna teu dirojong ngagunakeun URL éksternal dina diréktif ADD. Werf moal ngamimitian ngawangun deui nalika sumber daya dina URL anu ditangtukeun robih. Urang rencanana pikeun nambahkeun fitur ieu pas.
2. Anjeun teu bisa nambahkeun .git kana gambar
Sacara umum, nambahkeun diréktori a .git dina gambar - prakték goréng anu jahat sareng ieu sababna:
- upami
.gittetep dina gambar ahir, ieu ngalanggar prinsip : Kusabab gambar final kudu numbu ka commit tunggal, teu mungkin mun ngalakukeungit checkoutkomitmen wenang. -
.gitningkatkeun ukuran gambar (Repository tiasa ageung kusabab kanyataan yén file ageung sakali ditambahkeun kana éta teras dihapus). Ukuran tangkal kerja anu ngan ukur aya hubunganana sareng komitmen khusus moal gumantung kana sajarah operasi di Git. Dina hal ieu, tambahan jeung panyabutan saterusna.gitti gambar ahir moal jalan: gambar masih bakal acquire lapisan tambahan - ieu téh kumaha Docker jalan. - Docker tiasa ngamimitian ngawangun deui anu teu perlu, sanaos komitmen anu sami diwangun, tapi tina tangkal-tangkal anu béda. Contona, GitLab nyiptakeun diréktori kloning anu misah di
/home/gitlab-runner/builds/HASH/[0-N]/yourprojectlamun assembly paralel diaktipkeun. The reassembly tambahan bakal alatan kanyataan yén diréktori.gitbéda dina versi kloning anu béda tina gudang anu sami, sanaos komitmen anu sami diwangun.
Titik terakhir ogé ngagaduhan akibat nalika nganggo werf. Werf ngabutuhkeun cache anu diwangun nalika ngajalankeun sababaraha paréntah (contona. werf deploy). Nalika paréntah ieu dijalankeun, werf ngitung tanda tangan panggung pikeun gambar anu dijelaskeun dina werf.yaml, sarta aranjeunna kedah dina cache assembly - disebutkeun paréntah moal bisa neruskeun gawé. Lamun tanda tangan panggung gumantung kana eusi .git, teras urang nampi cache anu teu stabil pikeun parobihan dina file anu teu relevan, sareng werf moal tiasa ngahampura pangawasan sapertos kitu (pikeun langkung rinci, tingali ).
Sacara umum nambahkeun ngan sababaraha file perlu ngaliwatan parentah ADD dina sagala hal ngaronjatkeun efisiensi jeung reliabilitas nu ditulis Dockerfile, sarta ogé ngaronjatkeun stabilitas cache dikumpulkeun pikeun ieu Dockerfile, pikeun parobahan anu teu relevan dina Git.
hasil
Jalur awal urang pikeun nyerat pembina urang sorangan pikeun kabutuhan khusus éta sesah, jujur sareng lugas: tibatan nganggo crutches di luhur Dockerfile standar, kami nyerat solusi kami nganggo sintaksis khusus. Sarta ieu miboga kaunggulan: collector Stapel copes kalawan tugas na sampurna.
Nanging, dina prosés nyerat pembina urang sorangan, urang leungiteun dukungan pikeun Dockerfiles anu tos aya. Cacat ieu ayeuna parantos dibenerkeun, sareng ka hareup urang rencanana pikeun ngembangkeun dukungan Dockerfile sareng pembina Stapel khusus pikeun ngawangun anu disebarkeun sareng pikeun ngawangun nganggo Kubernetes (nyaéta ngawangun dina pelari di jero Kubernetes, sapertos anu dilakukeun dina kaniko).
Janten, upami anjeun ujug-ujug gaduh sababaraha Dockerfiles ngagolér ... nyobaan !
PS Daptar dokuméntasi dina topik
- ;
- ;
- ;
- ;
- ;
- ;
- .
Baca ogé dina blog urang: "".
sumber: www.habr.com