Aku saranake sampeyan maca transkrip laporan dening Alexander Sigachev saka Inventos "Proses pangembangan lan tes karo Docker + Gitlab CI"
Wong-wong sing lagi miwiti ngleksanakake proses pangembangan lan tes adhedhasar Docker + Gitlab CI asring takon pitakonan dhasar. Where kanggo miwiti? Carane ngatur? Kepiye cara nguji?
Laporan iki apik amarga ngomong kanthi cara terstruktur babagan proses pangembangan lan tes nggunakake Docker lan Gitlab CI. Laporan kasebut dhewe wiwit taun 2017. Aku mikir yen saka laporan iki sampeyan bisa ngumpulake dhasar, metodologi, ide, lan pengalaman panggunaan.
Sing peduli, mangga ing ngisor kucing.
Jenengku Alexander Sigachev. Aku kerja ing Inventos. Aku bakal ngandhani sampeyan babagan pengalaman nggunakake Docker lan kepiye cara ngetrapake kanthi bertahap ing proyek ing perusahaan.
Topik laporan: Proses pangembangan nggunakake Docker lan Gitlab CI.
Iki minangka pirembagan kapindho babagan Docker. Ing wektu laporan pisanan, kita nggunakake Docker mung ing Pangembangan ing mesin pangembang. Jumlah karyawan sing nggunakake Docker kira-kira 2-3 wong. Mboko sithik, pengalaman ditampa lan kita pindhah luwih adoh. Link menyang kita .
Apa sing bakal ana ing laporan iki? Kita bakal nuduhake pengalaman babagan apa rakes sing diklumpukake, masalah apa sing wis ditanggulangi. Iku ora ayu nang endi wae, nanging ngidini kita nerusake.
Motto kita: dockerize kabeh kita njaluk tangan kita.
Masalah apa sing kita rampung?
Nalika perusahaan duwe sawetara tim, programer minangka sumber daya sing dienggo bareng. Ana tahapan nalika programmer ditarik metu saka siji proyek lan diwenehi proyek liyane kanggo sawetara wektu.
Supaya programmer cepet ngerti, dheweke kudu ngundhuh kode sumber proyek kasebut lan ngluncurake lingkungan kanthi cepet, sing bakal ngidini dheweke luwih maju kanggo ngrampungake masalah proyek kasebut.
Biasane, yen sampeyan miwiti saka ngeruk, ana dokumentasi cilik ing proyek kasebut. Mung wong lawas sing duwe informasi babagan carane nyetel. Karyawan nyiyapake papan kerja dhewe ing siji utawa rong dina. Kanggo nyepetake iki, kita nggunakake Docker.
Alesan sabanjure yaiku standarisasi setelan ing Pangembangan. Ing pengalaman, pangembang tansah njupuk inisiatif. Ing saben kasus kaping lima, domain khusus dilebokake, contone vasya.dev. Lungguh ing sandhingku yaiku Petya tanggaku, sing domaine petya.dev. Dheweke ngembangake situs web utawa sawetara komponen sistem nggunakake jeneng domain iki.
Nalika sistem tuwuh lan jeneng domain iki wiwit kalebu ing konfigurasi, konflik ing lingkungan Development muncul lan path situs ditulis maneh.
Bab sing padha kedadeyan karo setelan database. Sawetara wong ora ngganggu keamanan lan nggarap sandhi root kosong. Ing tataran instalasi, MySQL takon wong kanggo tembung sandhi lan tembung sandhi dadi 123. Asring kedadeyan yen konfigurasi database terus diganti gumantung saka komitmen pangembang. Ana sing mbenerake, ana sing ora mbenerake konfigurasi kasebut. Ana trik nalika kita sijine sawetara config test menyang .gitignore lan saben pangembang kudu nginstal database. Iki nggawe proses wiwitan luwih angel. Antarane liyane, sampeyan kudu ngelingi babagan database. Basis data kudu diinisialisasi, sandhi kudu didaftar, pangguna kudu didaftar, tandha kudu digawe, lan liya-liyane.
Masalah liyane yaiku versi perpustakaan sing beda. Asring kedadeyan yen pangembang nggarap proyek sing beda-beda. Ana proyek Warisan, sing diwiwiti limang taun kepungkur (saka 2017 - cathetan editor). Ing wiwitan kita miwiti nganggo MySQL 5.5. Ana uga proyek modern ing ngendi kita nyoba ngetrapake versi MySQL sing luwih modern, contone 5.7 utawa luwih lawas (ing 2017 - cathetan editor)
Sapa wae sing nggarap MySQL ngerti manawa perpustakaan kasebut duwe dependensi. Iku cukup masalah kanggo mbukak 2 database bebarengan. Paling ora, ana masalah kanggo nyambungake klien lawas menyang database anyar. Iki uga nyebabake sawetara masalah.
Masalah sabanjure nalika pangembang nggarap mesin lokal, dheweke nggunakake sumber daya lokal, file lokal, RAM lokal. Kabeh interaksi ing wektu ngembangaken solusi kanggo masalah digawa metu ing framework saka kasunyatan sing dianggo ing siji mesin. Conto bakal nalika kita duwe server backend ing Produksi 3, lan pangembang nyimpen file menyang direktori root lan saka ing kono nginx njupuk file kanggo nanggapi panjaluk kasebut. Nalika kode kasebut mlebu ing Produksi, ternyata file kasebut ana ing salah siji saka 3 server.
Arah layanan mikro saiki berkembang. Nalika kita dibagi aplikasi gedhe menyang sawetara komponen cilik sing sesambungan karo saben liyane. Iki ngidini sampeyan milih teknologi kanggo tumpukan tugas tartamtu. Iki uga ngidini sampeyan mbagi karya lan area tanggung jawab antarane pangembang.
Pangembang frontend, berkembang ing JS, meh ora ana pengaruh ing backend. Pengembang backend, ing siji, berkembang, ing kasus kita, Ruby on Rails lan ora ngganggu Frondend. Interaksi ditindakake kanthi nggunakake API.
Minangka bonus, nggunakake Docker kita bisa daur ulang sumber daya ing Staging. Saben proyek, amarga spesifik, mbutuhake setelan tartamtu. Secara fisik, perlu kanggo nyedhiyakake server virtual lan ngatur kanthi kapisah, utawa dibagi sawetara jinis lingkungan variabel lan proyek bisa saling pengaruh, gumantung saka versi perpustakaan.
piranti. Apa sing kita gunakake?
- Docker dhewe. A Dockerfile nggambarake dependensi saka aplikasi siji.
- Docker-compose minangka bundel sing nggabungake sawetara aplikasi Docker.
- Kita nggunakake GitLab kanggo nyimpen kode sumber.
- Kita nggunakake GitLab-CI kanggo integrasi sistem.
Laporan kasebut dumadi saka rong bagean.
Pérangan pisanan bakal ngandhani carane mbukak Docker ing mesin pangembang.
Bagean kapindho bakal ngomong babagan carane sesambungan karo GitLab, carane kita nglakokake tes lan carane kita muter menyang Staging.
Docker minangka teknologi sing ngidini (nggunakake pendekatan deklaratif) kanggo njlèntrèhaké komponen sing perlu. Iki minangka conto Dockerfile. Ing kene kita nyatakake yen kita diwenehi warisan saka gambar Docker resmi Ruby:2.3.0. Isine Ruby versi 2.3 diinstal. Kita nginstal perpustakaan perakitan sing dibutuhake lan NodeJS. Kita nerangake manawa kita nggawe direktori /app. Kita nemtokake direktori app minangka direktori kerja. Ing direktori iki kita nyeleh Gemfile minimal sing dibutuhake lan Gemfile.lock. Banjur kita mbangun proyek sing nginstal gambar dependensi iki. We nunjukaké sing wadhah bakal siap kanggo ngrungokake ing port external 3000. Printah pungkasan iku printah sing langsung mbukak aplikasi kita. Yen kita nglakokake printah project run, aplikasi bakal nyoba kanggo mbukak lan mbukak printah kasebut.
Iki minangka conto minimal saka file docker-compose. Ing kasus iki, kita nuduhake yen ana sambungan antarane rong wadhah. Iki langsung menyang layanan database lan layanan web. Aplikasi web kita biasane mbutuhake sawetara jinis database minangka backend kanggo nyimpen data. Awit kita nggunakake MySQL, contone karo MySQL - nanging ora ana sing ngalangi kita nggunakake sawetara database liyane (PostgreSQL, Redis).
Kita njupuk gambar MySQL 5.7.14 tanpa owah-owahan saka sumber resmi saka hub Docker. Kita ngumpulake gambar sing tanggung jawab kanggo aplikasi web kita saka direktori saiki. Sajrone peluncuran pisanan, dheweke nglumpukake gambar kanggo kita. Banjur nganggo perintah sing kita lakoni ing kene. Yen kita bali, kita bakal weruh manawa printah peluncuran ditetepake liwat Puma. Puma minangka layanan sing ditulis ing Ruby. Ing kasus kaloro kita override. Prentah iki bisa sewenang-wenang gumantung saka kabutuhan utawa tugas kita.
Kita uga njlèntrèhaké sing kita kudu nerusake port ing mesin inang pangembang saka 3000 kanggo 3000 port wadhah. Iki rampung kanthi otomatis nggunakake iptables lan mekanisme dhewe, sing langsung dipasang ing Docker.
Pangembang bisa, kaya sadurunge, ngakses alamat IP sing kasedhiya, contone, 127.0.0.1 alamat IP lokal utawa eksternal mesin.
Ing baris pungkasan ngandika sing wadhah web gumantung ing wadhah db. Nalika kita nelpon wadhah web kanggo diluncurake, docker-compose bakal miwiti database kanggo kita. Wis marang wiwitan database (nyatane, sawise Bukak saka wadhah! Iki ora njamin kesiapan database) bakal miwiti aplikasi kita, backend kita.
Iki ngidini kita ngindhari kesalahan nalika database ora munggah lan ngidini kita nyimpen sumber daya nalika mungkasi wadhah database, saéngga mbebasake sumber daya kanggo proyek liyane.
Apa nggunakake database dockerization ing project menehi kita? Kita ngrekam versi MySQL kanggo kabeh pangembang. Iki ngidini sampeyan ngindhari sawetara kasalahan sing bisa kedadeyan nalika versi beda, nalika sintaks, konfigurasi, lan setelan gawan diganti. Iki ngidini sampeyan nemtokake jeneng host umum kanggo database, login, sandhi. Kita pindhah saka zoo jeneng lan konflik ing file konfigurasi sing wis ana sadurunge.
Kita duwe kesempatan kanggo nggunakake config luwih optimal kanggo lingkungan Development, kang bakal beda-beda saka standar. MySQL dikonfigurasi kanthi gawan kanggo mesin sing ringkih lan kinerja sing metu saka kothak sithik banget.
Docker ngidini sampeyan nggunakake interpreter Python, Ruby, NodeJS, PHP saka versi sing dikarepake. We njaluk nyisihaken saka perlu kanggo nggunakake sawetara jinis manager versi. Sadurunge, paket rpm digunakake kanggo Ruby, sing ngidini sampeyan ngganti versi gumantung saka proyek kasebut. Thanks kanggo wadhah Docker, iki uga ngidini sampeyan migrasi kode lan versi kanthi lancar bebarengan karo dependensi. Kita ora duwe masalah kanggo mangerteni versi interpreter lan kode kasebut. Kanggo nganyari versi, sampeyan kudu ngedhunake wadhah lawas lan ngunggahake wadhah anyar. Yen ana sing salah, kita bisa ngedhunake wadhah anyar, ngunggahake wadhah lawas.
Sawise mbangun gambar, wadhah ing Pengembangan lan Produksi bakal padha. Iki utamané bener kanggo instalasi gedhe.
Ing Frontend kita nggunakake JavaScipt lan NodeJS.
Saiki kita duwe proyek pungkasan ing ReacJS. Pangembang ngluncurake kabeh ing wadhah lan dikembangake nggunakake hot-reload.
Sabanjure, tugas ngrakit JavaScipt diluncurake lan kode sing dipasang kanthi statis dikirim liwat nginx, nyimpen sumber daya.
Ing kene aku wis nyedhiyakake diagram proyek paling anyar.
Masalah apa sing sampeyan ngrampungake? Kita kudu mbangun sistem karo piranti seluler sesambungan. Dheweke nampa data. Salah sawijining kemungkinan yaiku ngirim kabar push menyang piranti iki.
Apa sing wis kita lakoni kanggo iki?
Kita dibagi aplikasi kasebut dadi komponen ing ngisor iki: bagean admin ing JS, backend sing bisa digunakake liwat antarmuka REST ing Ruby on Rails. Backend sesambungan karo database. Asil sing diasilake diwenehake marang klien. Panel admin sesambungan karo backend lan database liwat antarmuka REST.
Kita uga kudu ngirim kabar Push. Sadurunge iki, kita duwe proyek sing ditindakake mekanisme sing tanggung jawab kanggo ngirim kabar menyang platform seluler.
Kita wis ngembangake skema ing ngisor iki: operator saka browser sesambungan karo panel admin, panel admin sesambungan karo backend, tugas kanggo ngirim kabar Push.
Notifikasi push sesambungan karo komponen liyane sing diimplementasikake ing NodeJS.
Antrian dibangun lan kabar dikirim miturut mekanisme dhewe.
Loro database digambar ing kene. Saiki, nggunakake Docker, kita nggunakake 2 database independen sing ora ana hubungane karo siji liyane. Saliyane kasunyatan sing padha duwe jaringan virtual umum, lan data fisik disimpen ing direktori beda ing mesin pangembang.
Bab sing padha nanging ing nomer. Gunakake maneh kode penting ing kene.
Yen sadurunge kita ngomong babagan nggunakake maneh kode ing bentuk perpustakaan, mula ing conto iki layanan kita, sing nanggapi kabar Push, digunakake maneh minangka server lengkap. Iku menehi API. Lan pangembangan anyar kita sesambungan karo.
Nalika iku kita nggunakake versi 4 saka NodeJS. Saiki (ing 2017 - cathetan editor) ing perkembangan paling anyar kita nggunakake versi 7 saka NodeJS. Ora ana masalah ing komponen anyar kanggo ndherek versi anyar perpustakaan.
Yen perlu, sampeyan bisa refactor lan ngunggahake versi NodeJS saka layanan kabar Push.
Lan yen kita bisa njaga kompatibilitas API, mula bisa diganti karo proyek liyane sing digunakake sadurunge.
Apa sampeyan kudu nambah Docker? Kita nambah Dockerfile menyang repositori kita, sing nggambarake dependensi sing dibutuhake. Ing conto iki, komponen dibagi kanthi logis. Iki minangka kit minimal kanggo pangembang backend.
Nalika nggawe proyek anyar, kita nggawe Dockerfile lan njlèntrèhaké ekosistem sing dibutuhake (Python, Ruby, NodeJS). Ing docker-compose, nerangake ketergantungan sing dibutuhake - database. Kita njlèntrèhaké yèn kita butuh basis data saka versi kasebut, kanggo nyimpen data ana ing kana.
Kita nggunakake wadhah katelu sing kapisah karo nginx kanggo ngladeni konten statis. Iku bisa kanggo upload gambar. Backend nempatake ing volume sing wis disiapake, sing uga dipasang ing wadhah kanthi nginx, sing nyedhiyakake data statis.
Kanggo nyimpen konfigurasi nginx lan mysql, kita nambah folder Docker ing ngendi kita nyimpen konfigurasi sing dibutuhake. Nalika pangembang nggawe klon git saka repositori ing mesin, dheweke wis duwe proyek siap kanggo pangembangan lokal. Ora ana pitakonan babagan port utawa setelan sing bakal ditrapake.
Sabanjure kita duwe sawetara komponen: admin, info-API, kabar push.
Kanggo miwiti kabeh iki, kita nggawe repositori liyane sing diarani dockerized-app. Saiki kita nggunakake macem-macem repositori kanggo saben komponen. Iku mung beda logis - ing GitLab katon kaya folder, nanging ing mesin pangembang katon kaya folder kanggo proyek tartamtu. Siji tingkat ing ngisor iki minangka komponen sing bakal digabung.
Iki minangka conto isi dockerized-app. Kita uga nyelehake direktori Docker ing kene, ing ngendi kita ngisi konfigurasi sing dibutuhake kanggo interaksi kabeh komponen. Ana README.md sing njlèntrèhaké kanthi ringkes babagan cara miwiti proyek kasebut.
Ing kene kita wis ngetrapake rong file docker-compose. Iki ditindakake supaya bisa diluncurake kanthi bertahap. Nalika pangembang nggarap kernel, dheweke ora butuh kabar Push, dheweke mung mbukak file docker-compose lan, kanthi mangkono, sumber daya disimpen.
Yen ana perlu kanggo integrasi karo kabar Push, banjur docker-compose.yaml lan docker-compose-push.yaml diluncurake.
Wiwit docker-compose.yaml lan docker-compose-push.yaml ana ing folder kasebut, jaringan virtual siji digawe kanthi otomatis.
Katrangan saka komponen. Iki minangka file sing luwih maju sing tanggung jawab kanggo ngumpulake komponen. Apa sing luar biasa ing kene? Kene kita introduce komponen balancer.
Iki minangka gambar Docker sing wis siap sing nganggo nginx lan aplikasi sing ngrungokake soket Docker. Dinamis, nalika wadhah diuripake lan dipateni, konfigurasi nginx digawe maneh. Kita nyebarake penanganan komponen nggunakake jeneng domain tingkat katelu.
Kanggo lingkungan Pangembangan kita nggunakake domain .dev - api.informer.dev. Aplikasi kanthi domain .dev kasedhiya ing mesin lokal pangembang.
Banjur konfigurasi ditransfer menyang saben proyek lan kabeh proyek diluncurake bebarengan ing wektu sing padha.
Yen kita nggambarake kanthi grafis, ternyata klien kasebut minangka browser kita utawa sawetara alat sing bisa dijaluk menyang balancer.
Balancer nemtokake wadhah sing kudu diakses adhedhasar jeneng domain.
Iki bisa uga nginx, sing nyedhiyakake JS menyang panel admin. Iki bisa ditindakake kanthi nginx, sing nyedhiyakake API, utawa file statis, sing diwenehake dening nginx ing wangun loading gambar.
Diagram nuduhake yen kontaner disambungake menyang jaringan virtual lan didhelikake ing mburi proxy.
Ing mesin pangembang, sampeyan bisa ngakses wadhah sing ngerti IP, nanging ing prinsip kita ora nggunakake iki. Ana praktis ora perlu kanggo kontak langsung.
Conto apa sing kudu dakdeleng kanggo nggawe dockerisasi aplikasi? Miturut pendapatku, conto sing apik yaiku gambar docker resmi kanggo MySQL.
Iku cukup rumit. Ana akeh versi. Nanging fungsi kasebut ngidini sampeyan nutupi akeh kabutuhan sing bisa kedadeyan sajrone proses pangembangan luwih lanjut. Yen sampeyan njupuk wektu lan ngerti carane kabeh sesambungan, aku mikir sampeyan ora bakal duwe masalah ngleksanakake dhewe.
Hub.docker.com biasane ngemot pranala menyang github.com, ing ngendi data mentah diwenehake langsung saka ngendi sampeyan bisa nggawe gambar dhewe.
Luwih ing repositori iki ana skrip docker-endpoint.sh, sing tanggung jawab kanggo initialization awal lan proses luwih lanjut saka peluncuran aplikasi.
Uga ing conto iki ana kamungkinan konfigurasi nggunakake variabel lingkungan. Kanthi nemtokake variabel lingkungan nalika mbukak wadhah siji utawa liwat docker-compose, kita bisa ngomong yen kita kudu nyetel sandhi kosong kanggo docker kanggo root ing MySQL utawa apa wae sing dikarepake.
Ana pilihan kanggo nggawe sandi acak. Kita ngomong yen kita kudu pangguna, kita kudu nyetel sandhi kanggo pangguna, lan kita kudu nggawe database.
Ing proyek kita, kita wis rada nyawiji Dockerfile, sing tanggung jawab kanggo initialization. Ing kana kita nyelarasake karo kabutuhan kanggo mung nggedhekake hak pangguna sing digunakake aplikasi kasebut. Iki ndadekake iku bisa kanggo mung nggawe database saka console aplikasi ing mangsa. Aplikasi Ruby duwe perintah kanggo nggawe, ngowahi, lan mbusak database.
Iki minangka conto kaya versi MySQL tartamtu ing github.com. Sampeyan bisa mbukak Dockerfile lan ndeleng kepiye instalasi ing kana.
skrip docker-endpoint.sh tanggung jawab kanggo titik entri. Sajrone initialization dhisikan, sawetara tumindak preparation dibutuhake lan kabeh tumindak iki kalebu ing script initialization.
Ayo pindhah menyang bagean kapindho.
Kita ngalih menyang gitlab kanggo nyimpen kode sumber. Iki minangka sistem sing cukup kuat sing nduweni antarmuka visual.
Salah sawijining komponen Gitlab yaiku Gitlab CI. Iki ngidini sampeyan njlèntrèhaké seri printah sing bakal digunakake kanggo ngatur sistem pangiriman kode utawa mbukak testing otomatis.
Laporan ing Gitlab CI 2 — laporan saka klub Ruby Rusia cukup rinci lan bisa uga dadi kapentingan kanggo sampeyan.
Saiki kita bakal ndeleng apa sing dibutuhake kanggo ngaktifake Gitlab CI. Kanggo miwiti Gitlab CI, kita mung kudu sijine file .gitlab-ci.yml ing ROOT saka project.
Kene kita njlèntrèhaké sing kita arep kanggo nindakake urutan negara kayata test, panyebaran.
Kita nglakokake skrip sing langsung nelpon docker-compose build saka aplikasi kita. Iki minangka conto mung backend.
Sabanjure kita ngomong yen perlu kanggo mbukak migrasi kanggo ngganti database lan mbukak tes.
Yen skrip dieksekusi kanthi bener lan ora ngasilake kode kesalahan, sistem kasebut nerusake menyang tahap penyebaran kapindho.
Tahap penyebaran saiki ditindakake kanggo pementasan. Kita ora ngatur maneh tanpa downtime.
Kita mateni kabeh kontaner kanthi paksa, banjur ngunggahake kabeh kontaner maneh, diklumpukake ing tahap pertama sajrone tes.
Ayo mbukak migrasi database sing ditulis dening pangembang kanggo lingkungan variabel saiki.
Ana cathetan yen iki mung kudu ditrapake ing cabang master.
Ora bisa digunakake nalika ngganti cabang liyane.
Sampeyan bisa ngatur rollouts bebarengan cabang.
Kanggo ngatur luwih lanjut, kita kudu nginstal Gitlab Runner.
Utilitas iki ditulis nganggo Golang. Iki minangka file siji kaya sing umum ing jagad Golang, sing ora mbutuhake dependensi.
Ing wiwitan kita ndhaptar Gitlab Runner.
Kita nampa kunci ing antarmuka web Gitlab.
Banjur kita nelpon printah initialization ing baris printah.
Konfigurasi Gitlab Runner ing mode dialog (Shell, Docker, VirtualBox, SSH)
Kode ing Gitlab Runner bakal dieksekusi ing saben commit gumantung setelan .gitlab-ci.yml.
Kepiye tampilan visual ing Gitlab ing antarmuka web. Sawise nyambungake GItlab CI, kita duwe gendera sing nuduhake negara apa sing dibangun saiki.
Kita weruh yen 4 menit kepungkur, komitmen digawe sing lulus kabeh tes lan ora nyebabake masalah.
Kita bisa ndeleng bangunan kanthi luwih rinci. Ing kene kita weruh yen rong negara wis liwati. Status testing lan status penyebaran ing pementasan.
Yen kita klik ing mbangun tartamtu, bakal output console printah sing padha dibukak ing proses miturut .gitlab-ci.yml.
Iki minangka crita produk kita. Kita weruh manawa ana upaya sing sukses. Nalika tes dikirim, dheweke ora pindhah menyang langkah sabanjure lan kode pementasan ora dianyari.
Masalah apa sing diatasi nalika pementasan nalika nindakake docker? Sistem kita kalebu komponen lan kita mung kudu miwiti maneh sawetara komponen sing dianyari ing gudang, lan ora kabeh sistem.
Kanggo nindakake iki, kita kudu misahake kabeh menyang folder sing kapisah.
Sawise kita nindakake iki, kita duwe masalah karo kasunyatan sing Docker-nyipta nggawe papan jaringan dhewe kanggo saben folder lan ora ndeleng komponen saka pepadhamu.
Kanggo ngubengi, kita nggawe jaringan kanthi manual ing Docker. Ing Docker-compose ditulis yen sampeyan kudu nggunakake jaringan kasebut kanggo proyek iki.
Mangkono, saben komponen sing diwiwiti karo bolong iki ndeleng komponen ing bagean liya saka sistem.
Masalah sabanjure yaiku misahake pementasan ing antarane sawetara proyek.
Wiwit kabeh iki katon ayu lan sabisa kanggo produksi, iku apik kanggo nggunakake port 80 utawa 443, kang digunakake nang endi wae ing WEB.
Kepiye carane ngatasi iki? Kita nemtokake siji Gitlab Runner kanggo kabeh proyek gedhe.
Gitlab ngidini sampeyan ngluncurake sawetara Gitlab Runners sing disebarake, sing mung bakal nindakake kabeh tugas kanthi urutan sing kacau lan mbukak.
Kanggo ngindhari masalah omah, kita mbatesi klompok proyek kita menyang siji Gitlab Runner, sing bisa ngatasi volume kita tanpa masalah.
Kita mindhah nginx-proxy menyang skrip peluncuran sing kapisah lan nulis kothak kabeh proyek ing njero.
Proyek kita duwe siji kothak, lan balancer duwe sawetara kothak adhedhasar jeneng proyek. Bisa proxy luwih dening jeneng domain.
Panjaluk kita teka liwat domain ing port 80 lan ditanggulangi menyang klompok wadhah sing nglayani domain iki.
Apa masalah liyane sing ana? Iki sing kabeh kontaner mbukak minangka root minangka standar. Iki minangka host root sing ora padha karo sistem kasebut.
Nanging, yen sampeyan ngetik wadhah kasebut, bakal dadi ROOT lan file sing digawe ing wadhah iki entuk hak root.
Yen pangembang mlebu wadhah kasebut lan nggawe sawetara perintah ing kana sing ngasilake file, banjur ninggalake wadhah kasebut, banjur ing direktori kerja dheweke duwe file sing ora bisa diakses.
Kepiye carane bisa dirampungake? Sampeyan bisa nambah pangguna sing bakal ana ing wadhah kasebut.
Masalah apa sing muncul nalika kita nambahake pangguna?
Nalika nggawe pangguna, ID grup (UID) lan ID pangguna (GID) asring ora cocog.
Kanggo ngatasi masalah iki ing wadhah kita nggunakake pangguna karo ID 1000.
Ing kasus kita, iki bertepatan karo kasunyatan sing meh kabeh pangembang nggunakake OS Ubuntu. Lan ing Ubuntu OS pangguna pisanan duwe ID 1000.
Apa kita duwe rencana?
Waca maneh dokumentasi Docker. Proyek kasebut aktif berkembang, dokumentasi ganti. Data sing dipikolehi rong utawa telung sasi kepungkur alon-alon dadi ketinggalan jaman.
Sawetara masalah sing kita rampung bisa uga wis dirampungake kanthi cara standar.
Aku pancene pengin nerusake lan pindhah langsung menyang orkestrasi.
Salah sawijining conto yaiku mekanisme internal Docker sing diarani Docker Swarm, sing metu saka kothak. Aku pengin miwiti produksi adhedhasar teknologi Docker Swarm.
Wadah spawning ndadekake nggarap log ora trep. Saiki log diisolasi. Padha kasebar ing wadhah. Salah sawijining tugas yaiku nggawe akses sing trep kanggo log liwat antarmuka web.
Source: www.habr.com