Lehenik eta behin, teoria apur bat. Zer gertatu da ?
Hitz sinpleetan, dokumentu hau SaaS aplikazioen garapena errazteko diseinatuta dago, garatzaileei eta DevOps ingeniariei aplikazio modernoen garapenean gehien aurkitzen diren arazo eta praktiken berri ematen lagunduz.
Dokumentua Heroku plataformako garatzaileek sortu dute.
Twelve-Factor App aplikazioa edozein programazio-lengoaian idatzitako eta babes-zerbitzuen edozein konbinazio erabiliz (datu-baseak, mezu-ilarak, cacheak, etab.) aplika daiteke.
Metodologia hau oinarritzen den faktoreei buruz laburki:
- Kode-oinarria - Kode-oinarri bat bertsio-kontrolean jarraituta - hainbat inplementazio
- Mendekotasunak β Mendekotasunak esplizituki deklaratzea eta isolatzea
- konfigurazioa - Gorde konfigurazioa exekuzioan
- Laguntza Zerbitzuak β Kontuan hartu babeskopia zerbitzuak plug-in-baliabide gisa
- Eraiki, askatu, exekutatu β Zorrotz bereizi muntaketa eta exekuzio faseak
- Prozesuak β Exekutatu aplikazioa estaturik gabeko prozesu bat edo gehiago gisa
- Portua lotzea β Esportatu zerbitzuak portuen loturaren bidez
- Paralelismoa β Eskalatu zure aplikazioa prozesuak erabiliz
- Erabileragarritasuna - Maximizatu fidagarritasuna abiarazteko eta itzaltze garbiarekin
- Aplikazioen garapena/eragiketa parekotasuna β Mantendu zure garapen, eszenatze eta produkzio inguruneak ahalik eta antzekoen
- Erregistratzea - Ikusi erregistroa gertaeren korronte gisa
- Administrazio zereginak β Ad hoc prozesuak erabiliz administrazio/kudeaketa lanak egitea
12 faktoreei buruzko informazio gehiago lor dezakezu baliabide hauetatik:
- - irakurri beharrekoa
- - Itzulpen ofiziala
- - 12 faktoreei begirada berria, horiek hobetzeko helburuarekin.
Zer da Blue-Green hedapena?
Blue-Green inplementazioa aplikazio bat entregatzeko metodo bat da ekoizpen azken bezeroak bere aldetik aldaketarik ikusten ez duen moduan. Beste era batera esanda, zero duen aplikazio bat zabaltzea hutsartea.
BG Deploy eskema klasikoak beheko irudian agertzen denaren itxura du.
- Hasieran 2 zerbitzari fisiko daude kode, aplikazio, proiektu guztiz berdinarekin eta bideratzaile bat dago (orekatzailea).
- Bideratzaileak hasieran zerbitzarietako batera bideratzen ditu eskaera guztiak (berdea).
- Berriro kaleratu behar duzun unean, proiektu osoa beste zerbitzari batean eguneratzen da (urdinak), une honetan ez du inolako eskaerarik prozesatzen.
- Kodea piztu ondoren urdina zerbitzaria guztiz eguneratuta dago, bideratzaileari komando bat ematen zaio aldatzeko berdea on urdinak zerbitzaria.
- Orain bezero guztiek ikusten dute exekutatzen den kodearen emaitza urdinak zerbitzaria.
- Denbora batez, berdea zerbitzariak babeskopia gisa balio du arrakastarik gabeko hedapenean urdinak zerbitzaria eta hutsegite eta akatsen kasuan, bideratzaileak erabiltzailearen fluxua berriro aldatzen du berdea bertsio egonkor zaharra duen zerbitzaria, eta kode berria berrikusteko eta probatzeko bidaltzen da.
- Eta prozesuaren amaieran, modu berean eguneratzen da berdea zerbitzaria. Eta eguneratu ondoren, bideratzaileak eskaeraren fluxua berriro aldatzen du berdea zerbitzaria.
Oso ona dirudi eta lehen begiratuan ez luke arazorik izan behar.
Baina mundu modernoan bizi garenez, eskema klasikoan adierazitako aldaketa fisikoaren aukera ez datorkigu. Grabatu informazioa oraingoz, beranduago itzuliko gara.
Aholku txarra eta ona
Lege-oharra: Beheko adibideek erabiltzen ditudan utilitate/metodologiak erakusten dituzte, antzeko funtzioak dituzten edozein alternatiba erabil dezakezu.
Adibide gehienak era batera edo bestera web garapenarekin gurutzatuko dira (sorpresa bat da), PHP eta Dockerrekin.
Beheko paragrafoek faktoreen erabileraren deskribapen praktiko sinplea eskaintzen dute adibide zehatzak erabiliz; gai honi buruzko teoria gehiago lortu nahi baduzu, jarraitu goiko estekak jatorrizko iturrira.
1. Kode-oinarria
Erabili FTP eta FileZilla fitxategiak zerbitzarietara kargatzeko banan-banan, ez gorde kodea produkzio zerbitzarian ez beste inon.
Proiektuak kode-oinarri bakarra izan behar du beti, hau da, kode guztia batetik dator Git biltegia. Zerbitzariek (ekoizpena, eszenaratzea, test1, test2...) biltegi komun bateko adarretako kodea erabiltzen dute. Horrela, kodearen koherentzia lortzen dugu.
2. Mendekotasunak
Deskargatu karpetako liburutegi guztiak zuzenean proiektuaren errora. Egin eguneratzeak, besterik gabe, kode berria liburutegiaren uneko bertsioa duen karpetara transferituz. Instalatu beharrezko utilitate guztiak zuzenean ostalari zerbitzarian, non beste 20 zerbitzu exekutatzen ari diren.
Proiektu batek beti izan behar du argi uler daitekeen menpekotasunen zerrenda (menpekotasunekin ingurumena ere esan nahi dut). Mendekotasun guztiak esplizituki definitu eta isolatu behar dira.
Har dezagun adibide gisa Composer ΠΈ Docker.
Composer β PHPn liburutegiak instalatzeko aukera ematen duen pakete-kudeatzailea. Composer-ek bertsioak zehatz-mehatz edo modu askean zehaztea eta esplizituki definitzea ahalbidetzen du. Zerbitzarian 20 proiektu ezberdin egon daitezke eta bakoitzak paketeen eta liburutegien zerrenda pertsonala izango du bestetik independentea.
Docker β aplikazioa abiaraziko den ingurunea definitzeko eta isolatzeko aukera ematen duen utilitate bat. Horren arabera, konpositorearekin bezala, baina zehatzago, aplikazioak zertan funtzionatzen duen zehaztu dezakegu. Hautatu PHP bertsio zehatz bat, instalatu proiektuak funtziona dezan beharrezkoak diren paketeak soilik, ezer gehigarririk gehitu gabe. Eta garrantzitsuena, ostalari makina eta beste proiektu batzuen paketeak eta ingurunea oztopatu gabe. Hau da, Docker bidez exekutatzen diren zerbitzariko proiektu guztiek edozein pakete eta ingurune guztiz desberdina erabil ditzakete.
3. Konfigurazioa
Gorde konfigurazioak konstante gisa zuzenean kodean. Proba zerbitzarirako konstante bereiziak, ekoizpenerako bereiziak. Lotu aplikazioaren funtzionamendua ingurunearen arabera zuzenean proiektuaren negozio-logikan if else eraikitzen erabiliz.
Konfigurazioak - Hau da proiektuen hedapenak desberdinak izan behar dituen modu bakarra. Egokiena, konfigurazioak ingurune-aldagaietatik pasatu behar dira (env vars).
Hau da, .config.prod .config.local hainbat konfigurazio-fitxategi gordetzen badituzu eta inplementatzean .config-era (aplikazioak datuak irakurtzen dituen konfigurazio nagusia) izena aldatuko badizu ere - hori ez da planteamendu egokia izango, izan ere. kasu honetan konfigurazioetako informazioa publikoki eskuragarri egongo da aplikazioen garatzaile guztientzat eta ekoizpen-zerbitzariaren datuak arriskuan jarriko dira. Konfigurazio guztiak zuzenean biltegiratu behar dira inplementazio-sisteman (CI/CD) eta ingurune desberdinetarako sortu behar dira inplementazioaren unean ingurune zehatz baterako beharrezkoak diren balio desberdinekin.
4. Hirugarrenen Zerbitzuak
Inguruneari hertsiki lotuta egon, zerbitzu berberetarako konexio desberdinak erabili ingurune jakin batzuetan.
Izan ere, puntu hau konfigurazioei buruzko puntuarekin guztiz gainjartzen da, puntu hori gabe ezin baita konfigurazio-datu normalak egin eta, oro har, konfiguratzeko gaitasuna ezerezean geratuko da.
Kanpoko zerbitzuetarako konexio guztiak, hala nola ilara-zerbitzariak, datu-baseak, cache-zerbitzuak, berdinak izan behar dira bai tokiko ingurunerako, bai hirugarrenen/ekoizpeneko ingurunerako. Beste era batera esanda, edozein unetan, konexio-katea aldatuz, #1 oinarrirako deiak ordezkatu ditzaket #2 oinarriarekin aplikazioaren kodea aldatu gabe. Edo, aurrera begira, adibide gisa, zerbitzua eskalatzerakoan, ez duzu konexioa modu berezi batean zehaztu beharko cache zerbitzari gehigarri baterako.
5. Eraiki, askatu, exekutatu
Zerbitzarian kodearen azken bertsioa bakarrik eduki, bertsioa atzera botatzeko aukerarik gabe. Ez da diskoko tokia bete behar. Errore batekin kodea ekoizpenera askatu dezakeela uste duen edonor programatzaile txarra da!
Hedapenaren fase guztiak elkarrengandik bereizi behar dira.
Izan atzera egiteko aukera. Egin bertsioak aplikazioaren kopia zaharrekin (dagoeneko muntatuta eta borrokarako prest) sarbide azkarrean gordeta, akatsen kasuan bertsio zaharra berreskuratu ahal izateko. Hau da, baldintzapean karpeta bat dago oharrak eta karpeta egungo, eta karpeta arrakastaz zabaldu eta muntatu ondoren egungo barnean dagoen estreinaldi berriarekin lotura sinboliko batek lotuta oharrak kaleratze-zenbakiaren ohiko izenarekin.
Hemen gogoratzen dugu Blue-Green inplementazioa, kode batetik bestera aldatzeaz gain, baliabide guztien artean eta baita ingurune batetik bestera ere aldatzeko aukera ematen baitu dena atzera egiteko gaitasunarekin.
6. Prozesuak
Gorde aplikazioaren egoera datuak zuzenean aplikazioan bertan. Erabili saioak aplikazioaren beraren RAMan. Erabili ahalik eta partekatzea hirugarrenen zerbitzuen artean. Kontuan izan aplikazioak prozesu bakarra izan dezakeela eta ez duela eskalatzeko aukera ematen.
Saioei dagokienez, gorde datuak hirugarrenen zerbitzuek kontrolatutako cache batean (memcached, redis), beraz, 20 aplikazio-prozesu exekutatzen badituzu ere, horietako edozeinek, cachean sartuta, bezeroarekin lanean jarraitu ahal izango du. erabiltzaileak beste prozesu batean aplikazioarekin lan egiten zuen egoera bera. Planteamendu honekin, ikusten da hirugarrenen zerbitzuen zenbat kopia erabiltzen dituzun, dena normaltasunez eta datuetara sartzeko arazorik gabe funtzionatuko duela.
7. Portuko lotzea
Web zerbitzariak bakarrik jakin beharko luke hirugarrenen zerbitzuekin lan egiten. Edo hobeto esanda, instalatu hirugarrenen zerbitzuak zuzenean web zerbitzariaren barruan. Adibidez, Apache-n PHP modulu gisa.
Zure zerbitzu guztiak elkarren artean eskuragarri egon behar dira helbide eta ataka batzuetarako sarbidearen bidez (localgost:5432, localhost:3000, nginx:80, php-fpm:9000), hau da, nginx-etik php-fpm-ra eta php-fpm-ra sar naiteke. postgres, eta php-fpm-tik postgres eta nginx-era eta benetan zerbitzu bakoitzetik beste zerbitzu batera sar naiteke. Horrela, zerbitzu baten bideragarritasuna ez dago beste zerbitzu baten bideragarritasunarekin lotuta.
8. Paralelismoa
Prozesu batekin lan egin, bestela hainbat prozesu ezin izango dira elkarrekin ondo moldatu!
Utzi lekua eskalatzeko. Docker swarm bikaina da horretarako.
Docker Swarm makina ezberdinen artean eta makina berean edukiontzi multzo bat sortu eta kudeatzeko tresna da.
Swarm erabiliz, prozesu bakoitzari zenbat baliabide banatuko ditudan eta zerbitzu bereko zenbat prozesu abiaraziko ditudan zehaztu dezaket, eta barne-balantzaileak, ataka jakin batean datuak jasoz, automatikoki proxy egingo ditu prozesuetara. Horrela, zerbitzariaren karga handitu egin dela ikusita, prozesu gehiago gehi ditzaket, horrela prozesu jakin batzuen karga murriztuz.
9. Erabilera
Ez erabili ilarak prozesuekin eta datuekin lan egiteko. Prozesu bat hiltzeak aplikazio osoan eragin beharko luke. Zerbitzu bat jaisten bada, dena jaisten da.
Prozesu eta zerbitzu bakoitza edozein unetan desaktibatu daiteke eta horrek ez du eragin behar beste zerbitzu batzuetan (noski, horrek ez du esan nahi zerbitzua beste zerbitzu baterako erabilgarri egongo ez denik, baina honen ondoren beste zerbitzu bat itzaliko ez denik). Prozesu guztiak dotore amaitu behar dira, amaitzen direnean ez dadin daturik kaltetuko eta sistemak ondo funtzionatuko du hurrengoan pizten duzunean. Hau da, larrialdiko bajaren bat gertatuz gero ere, datuak ez dira kaltetu behar (transakzio-mekanismoa egokia da hemen, datu-baseko kontsultak taldeka bakarrik funtzionatzen dute, eta taldeko kontsulta batek gutxienez huts egiten badu edo batekin exekutatzen bada). errorea, orduan taldeko beste kontsultarik ez du huts egiten).
10. Aplikazioen garapena/eragiketa parekotasuna
Produkzioa, eszenaratzea eta aplikazioaren tokiko bertsioak desberdinak izan behar dute. Produkzioan Yii Lite markoa erabiltzen dugu, eta lokalean Yii, ekoizpenean azkarrago funtziona dezan!
Egia esan, inplementazio guztiak eta kodearekin lan egin behar dira ia ingurune berdin batean (ez gara hardware fisikoaz ari). Gainera, garapen-langile orok behar izanez gero, kodea ekoizpenera zabaldu ahal izan beharko luke, eta ez bereziki prestatutako devops sail batzuk, indar bereziari esker soilik aplikazioa produkziora igotzeko.
Docker-ek ere horretan laguntzen digu. Aurreko puntu guztiak betetzen badira, docker erabiltzeak ingurunea ekoizpenean zein tokiko makinan inplementatzeko prozesua ekarriko du komando bat edo bi sartzera.
11. Erregistroak
Fitxategietan eta datu-baseetan erregistroak idazten ditugu! Ez ditugu fitxategiak eta datu-baseak erregistroetatik garbitzen. Eros dezagun 9000 Peta byte dituen disko gogor bat eta ondo dago.
Erregistro guztiak gertaeren korronte gisa hartu behar dira. Aplikazioak berak ez luke erregistroak prozesatzen parte hartu behar. Erregistroak stdout-era atera behar dira edo udp bezalako protokolo baten bidez bidali behar dira, erregistroekin lan egiteak aplikazioan arazorik sortu ez dezan. Graylog ona da horretarako. Graylog-ek erregistro guztiak udp bidez jasotzeak (protokolo honek ez du paketearen harrera arrakastatsuari buruzko erantzun baten zain egon behar) ez du aplikazioa inola ere oztopatzen eta erregistroak egituratzea eta prozesatzeaz soilik arduratzen da. Aplikazio-logika ez da aldatzen horrelako planteamenduekin lan egiteko.
12. Administrazio egitekoak
Datuak, datu-baseak eta abar eguneratzeko, erabili bereizita sortutako amaierako puntu bat APIan, 2 aldiz jarraian exekutatzen dena bikoiztuko da. Baina ez zara ergela, ez duzu bi aldiz klik egingo eta ez dugu migraziorik behar.
Administrazio-zeregin guztiak kode guztien ingurune berean egin behar dira, kaleratze mailan. Hau da, datu-basearen egitura aldatu behar badugu, orduan ez dugu eskuz egingo zutabeen izenak aldatuz eta berriak gehituz datu-base bisualak kudeatzeko tresna batzuen bidez. Gauzak horrela, script bereiziak sortzen ditugu - migrazioak, nonahi eta ingurune guztietan gauzatzen direnak, emaitza komun eta ulergarri batekin. Beste zeregin guztietarako, proiektua datuez betetzeko adibidez, antzeko metodologiak erabili behar dira.
PHP, Laravel, Laradock, Docker-Compose inplementazio adibidea
PS Adibide guztiak MacOS-en egin ziren. Gehienak Linuxerako ere egokiak dira. Windows erabiltzaileak, barkatu, baina aspaldi ez dut Windows-ekin lan egin.
Imajina dezagun egoera bat non ez dugun PHP bertsiorik instalatuta gure ordenagailuan eta ezer ez.
Instalatu docker eta docker-compose-ren azken bertsioak. (Interneten aurki daiteke)
docker -v &&
docker-compose -v
1. Jarri dugu
git clone https://github.com/Laradock/laradock.git &&
ls
Laradock-i buruz, esango dut oso gauza polita dela, edukiontzi eta gauza osagarri asko dituena. Baina ez nuke Laradock gisa erabiltzea gomendatuko ekoizpenean aldaketarik gabe, bere erredundantzia dela eta. Hobe da Laradocken adibideetan oinarrituta zure edukiontziak sortzea, hau askoz ere optimizatuagoa izango da, inork ez duelako behar aldi berean dagoen guztia.
2. Konfiguratu Laradock gure aplikazioa exekutatzeko.
cd laradock &&
cp env-example .env
2.1. Ireki habr direktorioa (laradock klonatu den karpeta nagusia) editore batean. (Nire PHPStorm kasuan)
Fase honetan proiektuari izena baino ez diogu ematen.
2.2. Abiarazi lan-eremuaren irudia. (Zure kasuan, irudiak denbora pixka bat beharko dute eraikitzeko)
Workspace garatzailearen izenean markoarekin lan egiteko bereziki prestatutako irudia da.
Edukiontzi barrura sartzen gara erabiliz
docker-compose up -d workspace &&
docker-compose exec workspace bash
2.3. Laravel instalatzen
composer create-project --prefer-dist laravel/laravel application
2.4. Instalatu ondoren, proiektua duen direktorioa sortu den egiaztatzen dugu eta kill compose.
ls
exit
docker-compose down
2.5. Itzuli PHPStorm-era eta ezarri gure laravel aplikaziorako bide zuzena .env fitxategian.
3. Gehitu kode guztia Git-era.
Horretarako, biltegi bat sortuko dugu Github-en (edo beste edozein lekutan). Goazen terminaleko habr direktoriora eta exekutatu hurrengo kodea.
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
Egiazta dezagun dena ondo dagoen.
Erosotasunerako, Git-erako ikusizko interfazeren bat erabiltzea gomendatzen dut, nire kasuan hala da . (hemen erreferentzia esteka bat)
4. Abian dezagun!
Hasi aurretik, ziurtatu ez dagoela ezer zintzilik 80 eta 443 ataketan.
docker-compose up -d nginx php-fpm
Horrela, gure proiektuak 3 zerbitzu bereizi ditu:
- nginx - web zerbitzaria
- php-fpm - php web zerbitzari batetik eskaerak jasotzeko
- lan-eremua - php garatzaileentzako
Momentuz, 4tik 12 puntu betetzen dituen aplikazio bat sortzea lortu dugu, hau da:
1. Kode-oinarria β kode guztia biltegi batean dago (ohar txikia: zuzena izan liteke laravel proiektuaren barruan docker gehitzea, baina hori ez da garrantzitsua).
2. Mendekotasunak - Gure mendekotasun guztiak espresuki idatzita daude application/composer.json-en eta edukiontzi bakoitzeko Dockerfile bakoitzean.
3. Laguntza Zerbitzuak β Zerbitzu bakoitzak (php-fom, nignx, workspace) bere bizitza du eta kanpotik konektatuta dago eta zerbitzu batekin lan egitean, besteari ez zaio eragingo.
4. Prozesuak β Zerbitzu bakoitza prozesu bat da. Zerbitzu bakoitzak ez du barne egoera mantentzen.
5. Portua lotzea
docker ps
Ikus dezakegunez, zerbitzu bakoitza bere portuan exekutatzen da eta gainerako zerbitzu guztietarako eskuragarri dago.
6. Paralelismoa
Docker-ek zerbitzu bereko hainbat prozesu sortu ditzakegu haien arteko karga oreka automatikoarekin.
Gelditu ditzagun edukiontziak eta pasa ditzagun banderatik --eskala
docker-compose down &&
docker-compose up -d --scale php-fpm=3 nginx php-fpm
Ikus dezakegunez, php-fpm edukiontziaren kopiak sortu dira. Edukiontzi honekin lan egitean ez dugu ezer aldatu behar. 9000 portuan ere sartzen jarraitzen dugu, eta Docker-ek edukiontzien arteko karga arautzen digu.
7. Erabileragarritasuna - ontzi bakoitza besteari kalterik egin gabe hil daiteke. Edukiontzia gelditzeak edo berrabiarazteak ez du aplikazioaren funtzionamenduan eragingo ondorengo abiarazteko garaian. Edukiontzi bakoitza edozein unetan ere altxa daiteke.
8. Aplikazioen garapena/eragiketa parekotasuna - Gure ingurune guztiak berdinak dira. Sistema ekoizpenean zerbitzari batean exekutatzen baduzu, ez duzu ezer aldatu beharko zure komandoetan. Dena Docker-en oinarrituko da modu berean.
9. Erregistratzea β Edukiontzi horietako erregistro guztiak korrontean doaz eta Docker kontsolan ikusgai daude. (kasu honetan, hain zuzen ere, etxeko beste ontzi batzuekin, baliteke hori ez izatea zaintzen ez baduzu)
docker-compose logs -f
Baina PHP eta Nginx-en balio lehenetsiek fitxategi batean erregistroak idazten dituzte. 12 faktoreak betetzeko, beharrezkoa da itxi off fitxategi batean erregistroak idaztea edukiontzi bakoitzaren konfigurazioetan bereizita.
Docker-ek erregistroak stdout-era ez ezik, goian aipatu ditudan graylog bezalako gauzetara ere bidaltzeko aukera eskaintzen du. Eta graylog barruan, erregistroak nahi bezala funtziona ditzakegu eta gure aplikazioak ez du inola ere ohartuko.
10. Administrazio zereginak β Laravel-ek administrazio-zeregin guztiak konpontzen ditu artisau-tresnari esker, 12 faktore aplikazioaren sortzaileek nahi luketen moduan.
Adibide gisa, komando batzuk nola exekutatzen diren erakutsiko dut.
Edukiontzira sartzen gara.
docker-compose exec workspace bash
php artisan list
Orain edozein komando erabil dezakegu. (kontuan izan datu-basea eta cachea ez dugula konfiguratu, beraz, komandoen erdia ez da behar bezala exekutatuko, cachearekin eta datu-basearekin lan egiteko diseinatuta daudelako).
11. Konfigurazioak eta 12. Eraiki, askatu, exekutatu
Zati hau Blue-Green Deploymentari eskaini nahi nion, baina oso zabala izan da artikulu honetarako. Aparteko artikulu bat idatziko dut honi buruz.
Laburbilduz, kontzeptua CI/CD sistemetan oinarritzen da Jenkins ΠΈ Gitlab CI. Bietan, ingurune zehatz bati lotutako ingurune-aldagaiak ezar ditzakezu. Horren arabera, egoera horretan, c puntua beteko da Konfigurazioak.
Eta buruz kontua Eraiki, askatu, exekutatu izenarekin bateratutako funtzioen bidez konpontzen da Pipeline.
Pipeline inplementazio-prozesua fase askotan banatzeko aukera ematen du, muntaketa, askapen eta exekuzio faseak nabarmenduz. Pipeline-n ere, babeskopiak sor ditzakezu, eta edozer gauza. Potentzial mugagabea duen tresna da hau.
Aplikazioaren kodea helbidean dago .
Ez ahaztu azpimodulua hasieratzea biltegi hau klonatzean.
PS: Ikuspegi hauek guztiak beste edozein utilitate eta programazio lengoairekin erabil daitezke. Gauza nagusia da esentzia ez dela desberdina.
Iturria: www.habr.com