Kubernetes tresna bikaina da Docker edukiontziak klusteratutako ekoizpen-ingurunean exekutatzeko. Hala ere, badaude Kubernetes-ek konpondu ezin dituen arazoak. Ekoizpen maiz inplementatzeko, Blue/Green inplementazio guztiz automatizatu bat behar dugu prozesuan geldialdi-denbora saihesteko, kanpoko HTTP eskaerak kudeatu eta SSL deskargak ere egin behar dituena. Honek ha-proxy bezalako karga-orekatzaile batekin integratzea eskatzen du. Beste erronka bat Kubernetes klusterraren beraren eskalatze erdi-automatikoa da hodei-ingurunean exekutatzen denean, adibidez, gauez kluster partzialki eskalatzea.
Kubernetes-ek ezaugarri hauek kutxatik kanpo ez dituen arren, antzeko arazoak konpontzeko erabil dezakezun API bat eskaintzen du. Kubernetes kluster baten Blue/Green inplementazio automatikorako eta eskalatzeko tresnak Cloud RTI proiektuaren barruan garatu ziren, kode irekian oinarrituta sortu zena.
Artikulu honek, bideoaren transkripzioan, Kubernetes kode irekiko beste osagai batzuekin batera nola konfiguratu erakusten dizu produkziorako prest dagoen ingurune bat sortzeko, produkzioan geldialdirik gabe git commit batetik kodea onartzen duena.
Beraz, kanpoko mundutik zure aplikazioetarako sarbidea duzunean, automatizazioa guztiz konfiguratzen has zaitezke, hau da, git commit bat egin dezakezun fasera eraman dezakezu eta ziurtatu git commit hori produkzioan amaitzen dela. Jakina, urrats hauek ezartzerakoan, inplementazioa ezartzerakoan, ez dugu geldialdi denborarik topatu nahi. Beraz, Kubernetesen edozein automatizazio APIarekin hasten da.
Kubernetes ez da kutxatik kanpo produktiboki erabil daitekeen tresna. Jakina, hori egin dezakezu, kubectl erabili eta abar, baina hala ere APIa da plataforma honen gauzarik interesgarri eta erabilgarriena. APIa funtzio multzo gisa erabiliz, Kubernetes-en egin nahi duzun ia edozertara sar zaitezke. kubectl berak REST APIa ere erabiltzen du.
Hau REST da, beraz, edozein hizkuntza edo tresna erabil dezakezu API honekin lan egiteko, baina zure bizitza askoz erraztuko da liburutegi pertsonalizatuekin. Nire taldeak honelako 2 liburutegi idatzi zituen: bat Java/OSGirako eta beste bat Gorako. Bigarrena ez da sarritan erabiltzen, baina edozein kasutan erabilgarri dituzu eskura. Partzialki lizentziadun kode irekiko proiektu bat dira. Horrelako liburutegi asko daude hizkuntza ezberdinetarako, eta, beraz, hobekien egokitzen direnak aukeratu ditzakezu.
Beraz, zure inplementazioa automatizatzen hasi aurretik, ziurtatu behar duzu prozesua ez dela inolako geldialdirik izango. Esaterako, gure taldeak ekoizpen-inplementazioak egiten ditu egunaren erdialdean jendeak aplikazioak gehien erabiltzen dituenean, beraz, garrantzitsua da prozesuan atzerapenak saihestea. Gelditasuna saihesteko, 2 metodo erabiltzen dira: inplementazio urdina/berdea edo eguneraketa iraunkorra. Azken kasu honetan, aplikazioaren 5 erreplika martxan badituzu, sekuentzialki eguneratzen dira bata bestearen atzetik. Metodo honek bikain funtzionatzen du, baina ez da egokia aplikazioaren bertsio desberdinak aldi berean exekutatzen badituzu inplementazio prozesuan. Kasu honetan, erabiltzailearen interfazea egunera dezakezu backend-a bertsio zaharra exekutatzen ari den bitartean, eta aplikazioak funtzionatzeari utziko dio. Beraz, programazioaren ikuspuntutik, nahiko zaila da horrelako baldintzetan lan egitea.
Hau da gure aplikazioen hedapena automatizatzeko inplementazio urdina/berdea erabiltzea nahiago dugun arrazoietako bat. Metodo honekin, ziurtatu behar duzu aplikazioaren bertsio bakarra aktibo dagoela aldi berean.
Hedapen-mekanismo urdina/berdea itxura hau du. Gure aplikazioetarako trafikoa ha-proxy-ren bidez jasotzen dugu, zeinak bertsio bereko aplikazioaren exekutatzen ari diren errepliketara bidaltzen duena.
Inplementazio berri bat egiten denean, Deployer erabiltzen dugu, osagai berriak ematen zaizkio eta bertsio berria zabaltzen du. Aplikazio baten bertsio berri bat zabaltzeak esan nahi du erreplika-multzo berri bat "altxatzen" dela, eta, ondoren, bertsio berriaren erreplika hauek pod berri batean abiarazten dira. Hala ere, ha-proxy-k ez daki ezer haiei buruz eta ez die lan-kargarik bideratzen oraindik.
Hori dela eta, lehenik eta behin, beharrezkoa da osasun-egiaztapenaren bertsio berrien errendimendu-egiaztapena egitea, erreplikak zamari zerbitzua emateko prest daudela ziurtatzeko.
Inplementazio-osagai guztiek osasun-egiaztapen moduren bat onartu behar dute. Hau HTTP deien egiaztapen oso sinplea izan daiteke, 200 egoera duen kode bat jasotzen duzunean, edo egiaztapen sakonago bat, zeinetan errepliken konexioa datu-basearekin eta beste zerbitzu batzuekin egiaztatzen duzun, ingurune dinamikoko konexioen egonkortasuna. , eta dena behar bezala hasten den eta funtzionatzen duen. Prozesu hau nahiko konplexua izan daiteke.
Sistemak eguneratutako erreplika guztiak funtzionatzen ari direla egiaztatu ondoren, Deployer-ek konfigurazioa eguneratuko du eta konfd zuzena pasatuko du, ha-proxy birkonfiguratuko duena.
Horren ostean bakarrik bideratuko da trafikoa bertsio berriaren erreplikak dituen podra, eta pod zaharra desagertuko da.
Mekanismo hau ez da Kubernetesen ezaugarri bat. Blue/green inplementazioaren kontzeptua aspalditik dago eta beti erabili izan du karga-orekatzailea. Lehenik eta behin, trafiko guztia aplikazioaren bertsio zaharrera bideratzen duzu, eta eguneratu ondoren, bertsio berrira erabat transferitzen duzu. Printzipio hau Kubernetes-en ez ezik.
Orain inplementazio-osagai berri bat aurkeztuko dizut: Deployer, osasun-egiaztapenak egiten dituena, proxyak birkonfiguratzen dituena, etab. Kanpoko munduari aplikatzen ez zaion eta Kubernetesen barruan dagoen kontzeptua da. Zure Deployer kontzeptua nola sor dezakezun erakutsiko dizut kode irekiko tresnak erabiliz.
Beraz, Deployer-ek egiten duen lehen gauza RC erreplikazio-kontrolatzailea sortzea da Kubernetes APIa erabiliz. API honek lekak eta zerbitzuak sortzen ditu gehiago zabaltzeko, hau da, gure aplikazioetarako kluster guztiz berria sortzen du. RC-k erreplikak hasi direla konbentzitu bezain laster, haien funtzionaltasunari buruzko Osasun egiaztapena egingo du. Horretarako, Deployer-ek GET /health komandoa erabiltzen du. Eskaneatu osagai egokiak exekutatzen ditu eta klusterraren funtzionamendua onartzen duten elementu guztiak egiaztatzen ditu.
Pod guztiek beren osasunaren berri eman ostean, Deployer-ek konfigurazio-elementu berri bat sortzen du - etcd biltegiratze banatua, Kubernetes-ek barnean erabiltzen duena, karga-orekatzailearen konfigurazioa gordetzea barne. Datuak etcd-ra idazten ditugu, eta datu berrietarako confd monitors etcd izeneko tresna txiki bat.
Hasierako konfigurazioan aldaketarik hautematen badu, ezarpen-fitxategi berri bat sortzen du eta ha-proxy-ra transferitzen du. Kasu honetan, ha-proxy berrabiarazten da konexiorik galdu gabe eta gure aplikazioen bertsio berriak funtzionatzea ahalbidetzen duten zerbitzu berrietara bideratzen du karga.
Ikus dezakezunez, osagai ugari egon arren, hemen ez dago ezer konplikaturik. APIari eta etcd-ri arreta gehiago jarri behar diozu. Guk erabiltzen dugun kode irekiko hedatzaileari buruz esan nahi dizut - Amdatu Kubernetes Deployer.
Kubernetes inplementazioak orkestratzeko tresna bat da eta ezaugarri hauek ditu:
- Urdina/Berdea hedapena;
- kanpoko karga-orekatzailea konfiguratzea;
- inplementazioaren deskribatzaileen kudeaketa;
- benetako hedapena kudeatzea;
- Hedapenean Osasun egiaztapenen funtzionaltasuna egiaztatzea;
- ingurune-aldagaiak podetan ezartzea.
Deployer hau Kubernetes APIaren gainean eraikita dago eta REST API bat eskaintzen du heldulekuak eta inplementazioak kudeatzeko, baita Websocket API bat ere inplementazio prozesuan erregistroak erreproduzitzeko.
Karga-orekatzailearen konfigurazio-datuak etcd-n jartzen ditu, beraz, ez duzu ha-proxy erabili beharrik gabeko laguntzarekin, baina erraz erabili zure karga-orekatzailearen konfigurazio fitxategia. Amdatu Deployer Go-n idatzita dago, Kubernetes bera bezala, eta Apache-ren lizentzia du.
Inplementatzailearen bertsio hau erabiltzen hasi baino lehen, hurrengo inplementazioaren deskribatzailea erabili nuen, behar ditudan parametroak zehazten dituena.
Kode honen parametro garrantzitsuenetako bat "useHealthCheck" bandera gaitzea da. Zehaztu behar dugu hedapen-prozesuan buru-belarri bat egin behar dela. Ezarpen hau desgaitu egin daiteke inplementazioak egiaztatu behar ez diren hirugarrenen edukiontziak erabiltzen dituenean. Deskriptore honek ha-proxy-k behar dituen erreplika kopurua eta frontend URLa ere adierazten ditu. Bukaeran "podspec" markako pod zehaztapena dago, eta horrek Kubernetes deitzen du portuaren konfigurazioari, irudiari, etab. Hau JSON deskribatzaile nahiko sinplea da.
Kode irekiko Amdatu proiektuaren parte den beste tresna bat Deploymentctl da. Inplementazioak konfiguratzeko UI bat du, inplementazio-historia gordetzen du eta hirugarrenen erabiltzaileen eta garatzaileen deietarako webhook-ak ditu. Agian ez duzu UI-a erabili Amdatu Deployer bera REST API bat baita, baina interfaze honek inplementazioa askoz erraztu diezazuke APIrik sartu gabe. Deploymentctl OSGi/Vertx-en idazten da Angular 2 erabiliz.
Orain aurrekoa pantailan erakutsiko dut aurrez grabatutako grabaketa erabiliz, itxaron behar ez dezazun. Go aplikazio sinple bat zabalduko dugu. Ez kezkatu Go aurretik probatu ez baduzu, oso aplikazio sinplea da, beraz, asmatu beharko zenuke.
Hemen /health-i soilik erantzuten dion HTTP zerbitzari bat sortzen ari gara, beraz, aplikazio honek osasun-egiaztapena bakarrik probatzen du eta kito. Egiaztapena gainditzen bada, behean agertzen den JSON egitura erabiltzen da. Inplementatzaileak zabalduko duen aplikazioaren bertsioa, fitxategiaren goialdean ikusten duzun mezua eta datu boolearra ditu, gure aplikazioa funtzionatzen ari den ala ez.
Azken lerroarekin apur bat iruzur egin nuen, balio boolear finko bat jarri nuelako fitxategiaren goialdean, eta horrek etorkizunean aplikazio "osasuntsu" bat ere zabaltzen lagunduko dit. Honekin aurrerago jorratuko dugu.
Beraz, has gaitezen. Lehenik eta behin, exekutatzen diren podsak dauden egiaztatzen dugu ~ kubectl get pods komandoa erabiliz eta, frontend URLaren erantzunik ez dagoenean, une honetan inplementaziorik egiten ez dela ziurtatzen dugu.
Hurrengo pantailan aipatu dudan Deploymentctl interfazea ikusiko duzu, eta bertan hedapen-parametroak ezartzen dira: izen-espazioa, aplikazioaren izena, inplementazioaren bertsioa, erreplika kopurua, front-end URLa, edukiontziaren izena, irudia, baliabideen mugak, osasun-kontrolerako atakaren zenbakia, etab. Baliabideen mugak oso garrantzitsuak dira, hardware kopuru handiena erabiltzeko aukera ematen baitute. Hemen Inplementazio erregistroa ere ikus dezakezu.
Orain ~ kubectl get pods komandoa errepikatzen baduzu, sistema 20 segundoz "izozten" dela ikus dezakezu, eta ha-proxy birkonfiguratzen da. Horren ondoren, pod-a abiarazten da, eta gure erreplika inplementazio-erregistroan ikus daiteke.
Bideotik 20 segundoko itxaronaldia moztu nuen, eta orain pantailan ikus dezakezu aplikazioaren lehen bertsioa zabaldu dela. Hau guztia interfazea soilik erabiliz egin zen.
Orain proba dezagun bigarren bertsioa. Horretarako, aplikazioaren mezua aldatzen dut "Kaixo, Kubernetes!" "Kaixo, Deployer!"-en, sistemak irudi hau sortzen du eta Docker erregistroan jartzen du, eta ondoren, Deploymentctl leihoan "Inplementatu" botoian klik egin besterik ez dugu egin. Kasu honetan, inplementazio-erregistroa automatikoki abiarazten da aplikazioaren lehen bertsioa zabaltzean gertatu zen modu berean.
~ kubectl get pods komandoak erakusten du une honetan aplikazioaren 2 bertsio exekutatzen ari direla, baina frontend-ak erakusten du oraindik 1 bertsioa exekutatzen ari garela.
Karga-orekatzaileak osasun-egiaztapena amaitu arte itxarongo du trafikoa bertsio berrira birbideratu aurretik. 20 segundo igaro ondoren, kizkurra aldatu eta ikusten dugu orain aplikazioaren 2. bertsioa zabalduta dugula eta lehena ezabatu egin dela.
Hau izan zen aplikazio "osasuntsu" baten hedapena. Ea zer gertatzen den aplikazioaren bertsio berri baterako Osasunaren parametroa egiazkotik faltsura aldatzen badut, hau da, osasun-egiaztapenean huts egin duen aplikazio osasuntsu bat zabaltzen saiatzen naiz. Hau gerta daiteke garapen-fasean aplikazioan konfigurazio-errore batzuk egin badira eta inprimaki honetan produkziora bidali bada.
Ikus dezakezun bezala, inplementazioak goiko urrats guztiak betetzen ditu eta ~kubectl get pods erakusten du bi podak martxan daudela. Baina aurreko inplementazioan ez bezala, erregistroak denbora-muga egoera erakusten du. Hau da, osasun-egiaztapenak huts egin duenez, ezin da aplikazioaren bertsio berria zabaldu. Ondorioz, sistema aplikazioaren bertsio zaharra erabiltzera itzuli dela ikusten duzu eta bertsio berria desinstalatu besterik ez da egin.
Honen gauza ona da aplikaziora aldibereko eskaera ugari jasotzen badituzu ere, ez dutela geldialdi-denbora nabarituko inplementazio prozedura inplementatzen duten bitartean. Aplikazio hau ahalik eta eskaera gehien bidaltzen dion Gatling esparrua erabiliz probatzen baduzu, ez da eskaera horietako bat ere kenduko. Horrek esan nahi du gure erabiltzaileek ez dituztela bertsio-eguneratzeak denbora errealean ohartuko. Huts egiten badu, bertsio zaharrean jarraituko du lanak; arrakasta izanez gero, erabiltzaileak bertsio berrira aldatuko dira.
Huts egin dezakeen gauza bakarra dago: osasun-egiaztapena arrakastatsua bada, baina aplikazioak huts egiten badu lan-karga aplikatu bezain laster, hau da, kolapsoa inplementazioa amaitu ondoren bakarrik gertatuko da. Kasu honetan, eskuz itzuli beharko duzu bertsio zaharrera. Beraz, Kubernetes horretarako diseinatutako kode irekiko tresnekin nola erabili aztertu dugu. Inplementazio-prozesua askoz errazagoa izango da tresna hauek zure Eraiki/Inplementatu kanalizazioetan eraikitzen badituzu. Aldi berean, inplementazioari ekiteko, erabiltzailearen interfazea erabil dezakezu edo prozesu hau guztiz automatizatu dezakezu, adibidez, commit to master erabiliz.
Gure Build Server-ek Docker irudi bat sortuko du, Docker Hub-era edo erabiltzen duzun edozein erregistrora bultzatuko du. Docker Hub-ek webhook onartzen du, beraz, Deployer-en bidez urruneko inplementazioa abiarazi dezakegu goian erakusten den moduan. Horrela, zure aplikazioaren hedapena guztiz automatizatu dezakezu produkzio potentzialera.
Joan gaitezen hurrengo gaira: Kubernetes klusterra eskalatzea. Kontuan izan kubectl komandoa eskalatzeko komando bat dela. Laguntza gehiagorekin, lehendik dagoen klusterrean erreplika kopurua erraz handitu dezakegu. Hala ere, praktikan, normalean nodo kopurua handitu nahi dugu lekak baino.
Aldi berean, lanorduetan handitu egin beharko zenuke, eta gauez, Amazon zerbitzuen kostua murrizteko, exekutatzen diren aplikazio-instantzia kopurua murriztu beharko duzu. Horrek ez du esan nahi lek kopurua eskalatzea nahikoa denik, nodoetako bat inaktibo egon arren, Amazoni ordaindu beharko duzulako. Hau da, lekak eskalatzearekin batera, erabilitako makina kopurua eskalatu beharko duzu.
Hau erronka izan daiteke Amazon edo hodeiko beste zerbitzu bat erabiltzen badugu, Kubernetes-ek ez daki ezer erabiltzen ari den makina kopuruari buruz. Sistema nodo mailan eskalatzeko aukera ematen duen tresna falta du.
Beraz, bi nodoak zein lekak zaindu beharko ditugu. Nodo berrien abiarazte erraz eskala dezakegu AWS APIa eta Scaling taldeko makinak erabiliz Kuberneteseko langile-nodo kopurua konfiguratzeko. Cloud-init edo antzeko script bat ere erabil dezakezu Kubernetes klusterrean nodoak erregistratzeko.
Makina berria Eskalatze taldean hasten da, nodo gisa hasten da, maisuaren erregistroan erregistratzen da eta lanean hasten da. Horren ondoren, ondoriozko nodoetan erabiltzeko erreplika kopurua handitu dezakezu. Eskalatzeak esfortzu handiagoa eskatzen du, ziurtatu behar baituzu urrats horrek ez duela exekutatzen ari diren aplikazioak suntsitzea ekarriko "alferrikako" makinak itzali ondoren. Eszenatoki hori saihesteko, nodoak "programatu gabeko" egoeran ezarri behar dituzu. Horrek esan nahi du lehenetsitako programatzaileak nodo horiei jaramonik egingo dizkiela DaemonSet pods-ak programatzean. Antolatzaileak ez du zerbitzari hauetatik ezer ezabatuko, baina ez du edukiontzi berririk jarriko bertan. Hurrengo urratsa drainatze-nodoa kanporatzea da, hau da, exekutatzen ari diren lekak bertatik beste makina batera transferitzea, edo horretarako gaitasun nahikoa duten beste nodo batzuetara. Nodo hauetan edukiontzirik ez dagoela ziurtatu ondoren, Kubernetesetik ken ditzakezu. Horren ondoren, Kubernetesentzat existitzeari utziko diote. Ondoren, AWS APIa erabili behar duzu alferrikako nodo edo makinak desgaitzeko.
Amdatu Scalerd erabil dezakezu, AWS APIaren antzeko beste kode irekiko eskalatzeko tresna bat. CLI bat eskaintzen du kluster batean nodoak gehitzeko edo kentzeko. Bere ezaugarri interesgarria honako json fitxategia erabiliz programatzailea konfiguratzeko gaitasuna da.
Erakutsitako kodeak klusterraren edukiera erdira murrizten du gaueko aldian. Eskuragarri dauden erreplika kopurua eta Amazon klusterraren nahi den edukiera konfiguratzen ditu. Antolatzaile hau erabiltzeak automatikoki murriztuko du nodo kopurua gauez eta handitu egingo da goizean, Amazon bezalako hodeiko zerbitzu bateko nodoak erabiltzearen kostua aurreztuz. Ezaugarri hau ez dago Kubernetes-en integratuta, baina Scalerd erabiliz plataforma hau nahi duzun moduan eskala dezakezu.
Adierazi nahi nuke jende askok esaten didala: "Hori ondo dago, baina zer gertatzen da nire datu-basea, normalean estatikoa dena?" Nola egin dezakezu horrelako zerbait Kubernetes bezalako ingurune dinamiko batean? Nire ustez, ez zenuke hau egin behar, ez zenuke saiatu behar Kubernetes-en datu biltegi bat exekutatzen. Teknikoki posible da hori, eta Interneten gai honi buruzko tutorialak daude, baina zure bizitza larriki zailduko dizu.
Bai, Kubernetes-en denda iraunkorren kontzeptua dago eta Mongo edo MySQL bezalako datu-biltegiak exekutatzen saia zaitezke, baina nahiko lan handia da. Datu biltegiek ingurune dinamiko batekin elkarrekintza guztiz onartzen ez dutelako gertatzen da. Datu-base gehienek konfigurazio esanguratsua behar dute, klusterren eskuzko konfigurazioa barne, ez dute gustatzen eskalatze automatikoa eta antzeko beste gauza batzuk.
Hori dela eta, ez zenuke zure bizitza zaildu behar Kubernetes-en datu biltegi bat exekutatzen saiatuz. Antolatu beren lana modu tradizionalean zerbitzu ezagunak erabiliz eta Kubernetes-ek erabiltzeko gaitasuna eman besterik ez.
Gaia bukatzeko, nire taldea lantzen ari den Kubernetes-en oinarritutako Cloud RTI plataforma aurkeztu nahi dizut. Erregistro zentralizatua, aplikazioen eta klusterren jarraipena eskaintzen du, eta erabilgarriak izango diren beste hainbat funtzio erabilgarri eskaintzen ditu. Kode irekiko hainbat tresna erabiltzen ditu, hala nola Grafana, monitorizazioa bistaratzeko.
Galdera bat zegoen zergatik erabili ha-proxy karga-orekatzailea Kubernetesekin. Galdera ona gaur egun karga orekatzeko 2 maila daudelako. Kubernetes zerbitzuak oraindik IP helbide birtualetan bizi dira. Ezin dituzu erabili kanpoko makinetako portuetarako, Amazonek bere hodeiko ostalari gainkargatzen badu helbidea aldatuko delako. Horregatik jartzen dugu ha-proxy zerbitzuen aurrean - Kubernetes-ekin trafikoa ezin hobeto komunikatzeko egitura estatikoagoa sortzeko.
Beste galdera on bat zera da: nola zaindu ditzakezu datu-baseen eskema aldaketak inplementazio urdina/berdea egiten duzunean? Kontua da Kubernetes-en erabilera edozein dela ere, datu-basearen eskema aldatzea lan zaila dela. Eskema zaharra eta berria bateragarriak direla ziurtatu behar duzu, ondoren datu-basea eguneratu eta aplikazioak beraiek egunera ditzakezu. Datu-basea beroan trukatu eta gero aplikazioak eguneratu ditzakezu. Eskema berri batekin datu base-kluster guztiz berri bat abiarazi duten pertsonak ezagutzen ditut, hau aukera bat da Mongo bezalako datu-baserik gabeko datu-base bat baduzu, baina hala ere ez da lan erraza. Galdera gehiagorik ez baduzu, eskerrik asko zure arretagatik!
Iragarki batzuk π
Eskerrik asko gurekin geratzeagatik. Gustuko dituzu gure artikuluak? Eduki interesgarri gehiago ikusi nahi? Lagun iezaguzu eskaera bat eginez edo lagunei gomendatuz, , sarrera-mailako zerbitzarien analogo paregabea, guk zuretzat asmatu duguna: (RAID1 eta RAID10-ekin erabilgarri, 24 nukleoraino eta 40 GB DDR4 arte).
Dell R730xd 2 aldiz merkeagoa Amsterdameko Equinix Tier IV datu-zentroan? Hemen bakarrik Herbehereetan! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 99 $-tik aurrera! Irakurri buruz
Iturria: www.habr.com