First, teori sethitik. Apa sing kedadeyan ?
Kanthi tembung sing prasaja, dokumen iki dirancang kanggo nyederhanakake pangembangan aplikasi SaaS, mbantu kanthi ngandhani pangembang lan insinyur DevOps babagan masalah lan praktik sing paling kerep ditemoni ing pangembangan aplikasi modern.
Dokumen kasebut digawe dening pangembang platform Heroku.
App Twelve-Factor bisa ditrapake kanggo aplikasi sing ditulis ing basa pamrograman lan nggunakake kombinasi layanan backing (database, antrian pesen, cache, lsp.).
Sedhela babagan faktor sing adhedhasar metodologi iki:
- basis kode - Siji basis kode sing dilacak ing kontrol versi - macem-macem penyebaran
- Ketergantungan - Secara eksplisit ngumumake lan ngisolasi dependensi
- Konfigurasi β Simpen konfigurasi ing runtime
- Layanan Backing - Coba layanan backing minangka sumber daya plug-in
- Mbangun, ngeculake, mbukak - Pisah kanthi ketat tahap perakitan lan eksekusi
- Pangolahan - Jalanake aplikasi minangka siji utawa luwih proses stateless
- Port binding - Layanan ekspor liwat port binding
- Paralelisme - Skala aplikasi sampeyan nggunakake proses
- Disposability - Nggedhekake linuwih kanthi wiwitan cepet lan mati sing resik
- Pangembangan aplikasi / paritas operasi - Tansah pangembangan, pementasan, lan lingkungan produksi sing padha
- logging - Deleng log minangka aliran acara
- Tugas administrasi - Nindakake tugas administrasi / manajemen nggunakake proses ad hoc
Sampeyan bisa entuk informasi luwih lengkap babagan 12 faktor saka sumber daya ing ngisor iki:
- - kudu maca
- - terjemahan resmi
- - dipikir seger ing 12 faktor kanthi tujuan kanggo nambah.
Apa penyebaran Blue-Green?
Penyebaran Biru-Ijo minangka cara ngirim aplikasi menyang produksi kanthi cara sing klien pungkasan ora weruh owah-owahan ing bagean. Ing tembung liyane, deploying aplikasi karo nul downtime.
Skema BG Deploy klasik katon kaya sing ditampilake ing gambar ing ngisor iki.
- Ing wiwitan ana 2 server fisik kanthi kode, aplikasi, proyek sing padha, lan ana router (balancer).
- Router wiwitane ngarahake kabeh panjalukan menyang salah sawijining server (ijo).
- Nalika sampeyan kudu ngeculake maneh, kabeh proyek dianyari ing server liyane (biru), sing saiki ora ngolah panjaluk apa wae.
- Sawise kode urip biru server wis rampung dianyari, router diwenehi printah kanggo ngalih saka ijo ing biru server.
- Saiki kabeh klien ndeleng asil saka kode mlaku karo biru server
- Kanggo sawetara wektu, ijo server serves minangka salinan serep ing cilik saka penyebaran prajurit ora kasil kanggo biru server lan ing cilik saka Gagal lan kewan omo, router ngalih aliran pangguna bali menyang ijo server karo versi stabil lawas, lan kode anyar dikirim kanggo revisi lan testing.
- Lan ing pungkasan proses kasebut, dianyari kanthi cara sing padha ijo server. Lan sawise nganyari, router ngalih aliran request bali menyang ijo server.
Kabeh katon apik banget lan sepisanan ora ana masalah.
Nanging amarga kita manggon ing donya modern, pilihan karo ngoper fisik minangka dituduhake ing skema klasik ora cocog karo kita. Rekam informasi kanggo saiki, kita bakal bali menyang mengko.
Saran sing ala lan apik
Nolak tanggung jawab: Conto ing ngisor iki nuduhake keperluan / metodologi sing digunakake, sampeyan bisa nggunakake pancen sembarang alternatif karo fungsi padha.
Umume conto bakal kanthi cara siji utawa liyane intersect karo pangembangan web (iki kaget), karo PHP lan Docker.
Paragraf ing ngisor iki nyedhiyakake katrangan praktis sing prasaja babagan panggunaan faktor nggunakake conto tartamtu; yen sampeyan pengin entuk luwih akeh teori babagan topik iki, tututi pranala ing ndhuwur menyang sumber asli.
1. Basis kode
Gunakake FTP lan FileZilla kanggo ngunggah file menyang server siji-sijine, aja nyimpen kode ing ngendi wae kajaba ing server produksi.
Proyek kasebut kudu duwe basis kode siji, yaiku kabeh kode asale saka siji Git gudang. Server (produksi, pementasan, test1, test2...) nggunakake kode saka cabang siji gudang umum. Kanthi cara iki, kita entuk konsistensi kode.
2. Ketergantungan
Download kabeh perpustakaan ing folder langsung menyang oyod proyek. Gawe nganyari mung kanthi nransfer kode anyar menyang folder kanthi versi perpustakaan saiki. Instal kabeh keperluan sing dibutuhake langsung ing server inang ing ngendi 20 layanan liyane mlaku.
A project kudu tansah duwe dhaftar cetha dingerteni saka dependensi (dening dependensi aku uga tegese lingkungan). Kabeh dependensi kudu ditetepake kanthi jelas lan diisolasi.
Ayo dadi conto pengarang ΠΈ docker.
pengarang - manajer paket sing ngidini sampeyan nginstal perpustakaan ing PHP. Komposer ngidini sampeyan nemtokake versi kanthi ketat utawa longgar, lan nemtokake kanthi jelas. Bisa uga ana 20 proyek sing beda-beda ing server lan saben bakal duwe dhaptar paket lan perpustakaan pribadi sing ora ana gandhengane.
docker - sarana sing ngidini sampeyan nemtokake lan ngisolasi lingkungan ing ngendi aplikasi bakal mbukak. Patut, kaya komposer, nanging luwih jero, kita bisa nemtokake apa aplikasi kasebut bisa digunakake. Pilih versi PHP tartamtu, instal mung paket sing perlu kanggo proyek kasebut, tanpa nambah apa-apa. Lan sing paling penting, tanpa ngganggu paket lan lingkungan mesin inang lan proyek liyane. Yaiku, kabeh proyek ing server sing mlaku liwat Docker bisa nggunakake kabeh paket paket lan lingkungan sing beda.
3. Konfigurasi
Simpen configs minangka konstanta langsung ing kode. Konstanta kapisah kanggo server test, kapisah kanggo produksi. Dasi operasi aplikasi gumantung ing lingkungan langsung ing logika bisnis saka project nggunakake yen liya mbangun.
Konfigurasi - iki mung cara sing penyebaran project kudu beda. Saenipun, konfigurasi kudu dilewati liwat variabel lingkungan (env vars).
Sing, sanajan sampeyan nyimpen sawetara file konfigurasi .config.prod .config.local lan ngganti jeneng ing wektu panyebaran kanggo .config (config utama saka kang aplikasi maca data) - iki ora pendekatan tengen, wiwit ing kasus iki informasi saka konfigurasi bakal kasedhiya kanggo umum kanggo kabeh pangembang aplikasi lan data saka server produksi bakal kompromi. Kabeh konfigurasi kudu disimpen langsung ing sistem panyebaran (CI / CD) lan digawe kanggo lingkungan sing beda-beda kanthi nilai sing beda-beda sing dibutuhake kanggo lingkungan tartamtu nalika panyebaran.
4. Layanan Pihak Katelu
Dadi strictly disambungake menyang lingkungan, nggunakake sambungan beda kanggo layanan padha ing lingkungan tartamtu.
Nyatane, titik iki banget tumpang tindih karo titik babagan konfigurasi, amarga tanpa titik iki, data konfigurasi normal ora bisa digawe lan, ing umum, kemampuan kanggo ngatur ora bakal ilang.
Kabeh sambungan menyang layanan eksternal, kayata server antrian, database, layanan caching, kudu padha kanggo lingkungan lokal lan lingkungan / produksi pihak katelu. Ing tembung liyane, sawayah-wayah, kanthi ngganti senar sambungan, aku bisa ngganti telpon menyang basis # 1 karo basis # 2 tanpa ngganti kode aplikasi. Utawa, katon ing ngarep, minangka conto, nalika skala layanan, sampeyan ora kudu nemtokake sambungan ing sembarang cara khusus kanggo server cache tambahan.
5. Mbangun, ngeculake, nglakokake
Duwe mung versi final saka kode ing server, karo ora kasempatan kanggo muter maneh release. Ora perlu ngisi ruang disk. Sapa wae sing mikir yen bisa ngeculake kode menyang produksi kanthi kesalahan yaiku programer sing ala!
Kabeh tahap penyebaran kudu dipisahake saka siji liyane.
Duwe kasempatan kanggo muter maneh. Gawe rilis nganggo salinan aplikasi lawas (wis dirakit lan siap perang) sing disimpen ing akses cepet, supaya yen ana kesalahan, sampeyan bisa mulihake versi lawas. Yaiku, kanthi syarat ana folder rilis lan folder saiki, lan sawise panyebaran sukses lan ngumpulake folder kasebut saiki disambung dening link simbolis kanggo release anyar sing dumunung nang rilis karo jeneng conventional saka nomer release.
Iki ngendi kita elinga panyebaran Blue-Green, sing ngidini sampeyan ora mung ngalih ing antarane kode, nanging uga ngalih ing antarane kabeh sumber daya lan malah lingkungan kanthi kemampuan kanggo muter maneh kabeh.
6. Pangolahan
Simpen data negara aplikasi langsung ing aplikasi kasebut dhewe. Gunakake sesi ing RAM aplikasi kasebut dhewe. Gunakake minangka akeh enggo bareng antarane layanan pihak katelu sabisa. Ngandelake kasunyatan manawa aplikasi mung bisa duwe siji proses lan ora ngidini skala.
Babagan sesi, nyimpen data mung ing cache sing dikontrol dening layanan pihak katelu (memcached, redis), dadi sanajan sampeyan duwe 20 proses aplikasi sing mlaku, sapa wae, sing wis ngakses cache, bakal bisa terus nggarap klien ing negara sing padha nalika pangguna nggarap aplikasi ing proses liyane. Kanthi pendekatan iki, ternyata ora ketompo carane akeh salinan layanan pihak katelu sing sampeyan gunakake, kabeh bakal bisa digunakake kanthi normal lan tanpa masalah karo akses menyang data.
7. Port naleni
Mung server web sing kudu ngerti cara nggarap layanan pihak katelu. Utawa luwih apik, instal layanan pihak katelu langsung ing server web. Contone, minangka modul PHP ing Apache.
Kabeh layanan sampeyan kudu bisa diakses saben liyane liwat akses menyang sawetara alamat lan port (localgost:5432, localhost:3000, nginx:80, php-fpm:9000), yaiku, saka nginx aku bisa ngakses php-fpm lan menyang postgres, lan saka php-fpm kanggo postgres lan nginx lan bener saka saben layanan aku bisa ngakses layanan liyane. Kanthi cara iki, kelangsungan layanan ora ana gandhengane karo kelangsungan layanan liyane.
8. Paralelisme
Bisa karo siji proses, yen ora, sawetara proses ora bakal bisa bebarengan!
Ninggalake kamar kanggo skala. Docker swarm apik kanggo iki.
Docker Swarm minangka alat kanggo nggawe lan ngatur klompok wadhah ing antarane mesin sing beda-beda lan akeh wadhah ing mesin sing padha.
Nggunakake grombolan, aku bisa nemtokake jumlah sumber daya aku bakal nyedhiakke kanggo saben proses lan carane akeh pangolahan layanan padha aku bakal miwiti, lan balancer internal, nampa data ing port tartamtu, bakal otomatis proxy kanggo pangolahan. Mangkono, ndeleng manawa beban ing server saya tambah, aku bisa nambah proses liyane, saengga bisa nyuda beban ing proses tartamtu.
9. Disposability
Aja nggunakake antrian kanggo nggarap proses lan data. Mateni siji proses kudu mengaruhi kabeh aplikasi. Yen salah siji layanan mudhun, kabeh bakal mudhun.
Saben proses lan layanan bisa dipateni sawayah-wayah lan iki ora kena mengaruhi layanan liyane (mesthi, iki ora ateges layanan kasebut ora kasedhiya kanggo layanan liyane, nanging layanan liyane ora bakal dipateni sawise iki). Kabeh pangolahan kudu diakhiri kanthi apik, supaya nalika diakhiri, ora ana data sing bakal rusak lan sistem bakal bisa digunakake kanthi bener nalika sampeyan nguripake maneh. Yaiku, sanajan kedadeyan darurat, data kasebut ora kena rusak (mekanisme transaksi cocok ing kene, pitakon ing basis data mung bisa digunakake ing klompok, lan yen paling ora siji pitakon saka grup gagal utawa dieksekusi kanthi kesalahan, banjur ora ana pitakon liyane saka grup sing pungkasane gagal).
10. Pangembangan aplikasi / paritas operasi
Produksi, pementasan lan versi lokal aplikasi kudu beda. Ing produksi kita nggunakake framework Yii Lite, lan Yii lokal, supaya bisa luwih cepet ing produksi!
Ing kasunyatan, kabeh panyebaran lan nggarap kode kudu ana ing lingkungan sing meh padha (kita ora ngomong babagan hardware fisik). Uga, sembarang pegawe pembangunan kudu bisa kanggo masang kode kanggo produksi yen perlu, lan ora sawetara departemen devops dilatih khusus, kang mung thanks kanggo kekuatan khusus bisa ngangkat aplikasi menyang produksi.
Docker uga mbantu kita babagan iki. Yen kabeh titik sadurunge diamati, nggunakake docker bakal nggawa proses deploying lingkungan ing produksi lan ing mesin lokal kanggo ngetik siji utawa loro printah.
11. Log
Kita nulis log menyang file lan database! Kita ora ngresiki file lan database saka log. Ayo tuku hard drive karo 9000 Peta bita lan iku nggoleki.
Kabeh log kudu dianggep minangka aliran acara. Aplikasi kasebut ora kudu melu ngolah log. Log kudu dadi output kanggo stdout utawa dikirim liwat protokol kayata udp, supaya nggarap log ora nggawe masalah kanggo aplikasi kasebut. graylog apik kanggo iki. Graylog nampa kabeh log liwat udp (protokol iki ora mbutuhake nunggu respon bab reception sukses paket) ora ngganggu aplikasi ing sembarang cara lan mung urusan karo struktur lan Processing log. Logika aplikasi ora owah kanggo nggarap pendekatan kasebut.
12. Tugas administrasi
Kanggo nganyari data, database, lan sapiturute, gunakake titik pungkasan sing digawe kanthi kapisah ing API, nglakokake 2 kaping saurutan bakal nyebabake kabeh diduplikasi. Nanging sampeyan ora bodho, sampeyan ora bakal klik kaping pindho, lan kita ora perlu migrasi.
Kabeh tugas administrasi kudu ditindakake ing lingkungan sing padha karo kabeh kode, ing tingkat rilis. Yaiku, yen kita kudu ngganti struktur database, mula kita ora bakal nindakake kanthi manual kanthi ngganti jeneng kolom lan nambah sing anyar liwat sawetara alat manajemen database visual. Kanggo perkara kasebut, kita nggawe skrip sing kapisah - migrasi, sing ditindakake ing endi wae lan ing kabeh lingkungan kanthi cara sing padha kanthi asil sing umum lan bisa dingerteni. Kanggo kabeh tugas liyane, kayata ngisi proyek kanthi data, metodologi sing padha kudu digunakake.
Tuladha implementasine ing PHP, Laravel, Laradock, Docker-Compose
P.S Kabeh conto digawe ing MacOS. Umume uga cocog kanggo Linux. Pangguna Windows, ngapura kula, nanging aku wis ora kerjo karo Windows kanggo dangu.
Ayo mbayangno kahanan sing ora duwe versi PHP sing diinstal ing PC lan ora ana apa-apa.
Instal versi paling anyar saka docker lan docker-compose. (iki bisa ditemokake ing Internet)
docker -v &&
docker-compose -v
1. Pasang
git clone https://github.com/Laradock/laradock.git &&
ls
Babagan Laradock, aku bakal ujar manawa iki pancen keren banget, sing ngemot akeh wadhah lan barang tambahan. Nanging aku ora nyaranake nggunakake Laradock kaya tanpa modifikasi ing produksi amarga redundansi. Iku luwih apik kanggo nggawe kontaner dhewe adhedhasar conto ing Laradock, iki bakal luwih dioptimalake, amarga ora ana sing perlu kabeh sing ana ing wektu sing padha.
2. Konfigurasi Laradock kanggo mbukak aplikasi kita.
cd laradock &&
cp env-example .env
2.1. Bukak direktori habr (folder induk ing ngendi laradock dikloning) ing sawetara editor. (Ing kasus PHPStorm)
Ing tataran iki kita mung menehi jeneng project.
2.2. Bukak gambar ruang kerja. (Ing kasus sampeyan, gambar bakal njupuk sawetara wektu kanggo mbangun)
Ruang kerja minangka gambar sing disiapake khusus kanggo nggarap kerangka atas jenenge pangembang.
We pindhah nang wadhah nggunakake
docker-compose up -d workspace &&
docker-compose exec workspace bash
2.3. Nginstal Laravel
composer create-project --prefer-dist laravel/laravel application
2.4. Sawise instalasi, kita mriksa apa direktori karo proyek wis digawe lan mateni nulis.
ls
exit
docker-compose down
2.5. Ayo bali menyang PHPStorm lan nyetel path sing bener kanggo aplikasi laravel ing file .env.
3. Tambah kabeh kode menyang Git.
Kanggo nindakake iki, kita bakal nggawe repositori ing Github (utawa ing ngendi wae). Ayo menyang direktori habr ing terminal lan nglakokake kode ing ngisor iki.
echo "# habr-12factor" >> README.md
git init
git add README.md
git commit -m "first commit"
git remote add origin [email protected]:nzulfigarov/habr-12factor.git # Π·Π΄Π΅ΡΡ Π±ΡΠ΄Π΅Ρ ΡΡΡΠ»ΠΊΠ° Π½Π° Π²Π°Ρ ΡΠ΅ΠΏΠΎ
git push -u origin master
git status
Ayo priksa manawa kabeh wis rapi.
Kanggo penak, aku nyaranake nggunakake sawetara antarmuka visual kanggo Git, ing kasusku . (iki link referral)
4. Ayo miwiti!
Sadurunge miwiti, priksa manawa ora ana sing macet ing port 80 lan 443.
docker-compose up -d nginx php-fpm
Dadi, proyek kita kalebu 3 layanan sing kapisah:
- nginx - server web
- php-fpm - php kanggo nampa panjalukan saka server web
- ruang kerja - php kanggo pangembang
Ing wayahe, kita wis entuk yen kita wis nggawe aplikasi sing ketemu 4 poin saka 12, yaiku:
1. basis kode - kabeh kode ana ing siji gudang (cathetan cilik: bisa uga bener kanggo nambah docker ing proyek laravel, nanging iki ora penting).
2. Ketergantungan - Kabeh dependensi kita ditulis kanthi jelas ing application/composer.json lan ing saben Dockerfile saben wadhah.
3. Layanan Backing β Saben layanan (php-fom, nignx, workspace) urip dhewe lan disambungake saka njaba lan nalika nggarap siji layanan, liyane ora bakal kena pengaruh.
4. Pangolahan - saben layanan iku siji proses. Saben layanan ora njaga negara internal.
5. Port binding
docker ps
Kaya sing kita deleng, saben layanan mlaku ing port dhewe lan bisa diakses kabeh layanan liyane.
6. Paralelisme
Docker ngidini kita ngasilake pirang-pirang proses layanan sing padha kanthi keseimbangan beban otomatis ing antarane.
Ayo padha mungkasi wadhah lan mbukak ing gendΓ©ra --skala
docker-compose down &&
docker-compose up -d --scale php-fpm=3 nginx php-fpm
Kaya sing kita deleng, salinan wis digawe saka wadhah php-fpm. Kita ora perlu ngganti apa-apa ing nggarap wadhah iki. Kita uga terus ngakses ing port 9000, lan Docker ngatur beban antarane kontaner kanggo kita.
7. Disposability - saben wadhah bisa dipateni tanpa cilaka liyane. Mungkasi utawa miwiti maneh wadhah ora bakal mengaruhi operasi aplikasi sajrone diluncurake sabanjure. Saben wadhah uga bisa diangkat kapan wae.
8. Pangembangan aplikasi / paritas operasi - kabeh lingkungan kita padha. Kanthi mbukak sistem ing server ing produksi, sampeyan ora kudu ngganti apa-apa ing printah sampeyan. Kabeh bakal adhedhasar Docker kanthi cara sing padha.
9. logging - kabeh log ing wadhah kasebut menyang stream lan katon ing konsol Docker. (ing kasus iki, nyatane, karo wadhah krasan liyane, iki bisa uga ora kedadeyan yen sampeyan ora ngurus)
docker-compose logs -f
Nanging ana sing nyekel yen nilai Default ing PHP lan Nginx uga nulis log menyang file. Kanggo nyukupi 12 faktor kasebut, perlu pedhot nulis log menyang file ing konfigurasi saben wadhah kanthi kapisah.
Docker uga menehi kemampuan kanggo ngirim log ora mung kanggo stdout, nanging uga kanggo perkara kayata graylog, sing dakkandhakake ing ndhuwur. Lan ing jero graylog, kita bisa ngoperasikake log kaya sing dikarepake lan aplikasi kita ora bakal weruh iki kanthi cara apa wae.
10. Tugas administrasi - kabeh tugas administrasi ditanggulangi dening laravel amarga alat artisan persis kaya sing dikarepake para pencipta aplikasi 12 faktor.
Minangka conto, aku bakal nuduhake carane sawetara printah dieksekusi.
We pindhah menyang wadhah.
docker-compose exec workspace bash
php artisan list
Saiki kita bisa nggunakake perintah apa wae. (Elinga yen kita ora ngatur database lan cache, supaya setengah saka printah ora bakal kaleksanan bener, amarga padha dirancang kanggo bisa karo cache lan database).
11. Konfigurasi lan 12. Mbangun, ngeculake, mbukak
Aku wanted kanggo ngaturake bagean iki kanggo Blue-Green Deployment, nanging ternyata banget ekstensif kanggo artikel iki. Aku bakal nulis artikel kapisah babagan iki.
Ing ringkesan, konsep kasebut adhedhasar sistem CI / CD kaya Jenkins ΠΈ Gitlab CI. Ing loro, sampeyan bisa nyetel variabel lingkungan sing digandhengake karo lingkungan tartamtu. Mulane, ing kahanan iki, titik c bakal kawujud Konfigurasi.
Lan titik babagan Mbangun, ngeculake, mbukak wis ditanggulangi dening dibangun ing fungsi karo jeneng Pipeline.
Pipeline ngidini sampeyan mbagi proses penyebaran dadi pirang-pirang tahapan, nyorot tahap perakitan, rilis lan eksekusi. Uga ing Pipeline, sampeyan bisa nggawe serep, lan apa wae. Iki minangka alat kanthi potensial tanpa wates.
Kode aplikasi ing .
Aja lali miwiti submodul nalika kloning repositori iki.
P.S.: Kabeh pendekatan iki bisa digunakake karo utilitas lan basa pamrograman liyane. Ingkang utama yaiku inti ora beda-beda.
Source: www.habr.com