Ensin vähän teoriaa. Mitä on tapahtunut ?
Yksinkertaisesti sanottuna tämä asiakirja on suunniteltu yksinkertaistamaan SaaS-sovellusten kehitystä, ja se auttaa kehittäjiä ja DevOps-insinöörejä informoimaan ongelmista ja käytännöistä, joita useimmiten kohdataan nykyaikaisten sovellusten kehittämisessä.
Dokumentin ovat luoneet Heroku-alustan kehittäjät.
Twelve-Factor App -sovellusta voidaan soveltaa millä tahansa ohjelmointikielellä kirjoitettuihin sovelluksiin, jotka käyttävät mitä tahansa taustapalveluiden yhdistelmää (tietokannat, viestijonot, välimuistit jne.).
Lyhyesti tekijöistä, joihin tämä menetelmä perustuu:
- Koodikanta – Yksi koodikanta, jota seurataan versionhallinnassa – useita käyttöönottoja
- Riippuvuudet – Ilmoita ja eristä riippuvuudet nimenomaisesti
- kokoonpano – Tallenna kokoonpano ajon aikana
- Tukipalvelut – Harkitse tukipalveluita laajennusresursseina
- Rakenna, vapauta, juokse – Erottele kokoonpano- ja toteutusvaiheet tiukasti
- prosessit – Suorita sovellus yhtenä tai useana tilattomana prosessina
- Porttisidonta – Palvelujen vienti porttisidonnalla
- rinnakkaisuus – Skaalaa sovelluksesi prosessien avulla
- Kertakäyttöisyys – Maksimoi luotettavuus nopealla käynnistyksellä ja puhtaalla sammutuksella
- Sovelluskehitys/käyttöpariteetti – Pidä kehitys-, lavastus- ja tuotantoympäristösi mahdollisimman samankaltaisina
- Kirjaaminen – Tarkastele lokia tapahtumien virtana
- Hallintotehtävät – Suorita hallinto-/hallintatehtävät ad hoc -prosesseja käyttäen
Saat lisätietoja 12 tekijästä seuraavista lähteistä:
- - pakko lukea
- — virallinen käännös
- - uusi katsaus 12 tekijään niiden parantamiseksi.
Mikä on sinivihreä käyttöönotto?
Sinivihreä käyttöönotto on tapa toimittaa sovellus tuotanto siten, että loppuasiakas ei näe muutoksia puoleltaan. Toisin sanoen sovelluksen käyttöönotto nollalla seisokkeja.
Klassinen BG Deploy -malli näyttää alla olevassa kuvassa esitetyltä.
- Alussa on 2 fyysistä palvelinta, joissa on täysin sama koodi, sovellus, projekti, ja siellä on reititin (balancer).
- Reititin ohjaa aluksi kaikki pyynnöt yhdelle palvelimista (vihreä).
- Sillä hetkellä, kun sinun täytyy julkaista uudelleen, koko projekti päivitetään toiselle palvelimelle (sininen), joka ei tällä hetkellä käsittele yhtään pyyntöä.
- Kun koodi on päällä sininen palvelin on täysin päivitetty, reitittimelle annetaan komento vaihtaa vihreä päälle sininen palvelin.
- Nyt kaikki asiakkaat näkevät koodin tuloksen sininen palvelin.
- Jonkin aikaa, vihreä palvelin toimii varmuuskopiona, jos käyttöönotto epäonnistuu sininen palvelimelle ja vian ja virheiden sattuessa reititin vaihtaa käyttäjävirtaan takaisin vihreä palvelimelle vanhalla vakaalla versiolla, ja uusi koodi lähetetään tarkistettavaksi ja testattavaksi.
- Ja prosessin lopussa se päivitetään samalla tavalla vihreä palvelin. Ja päivityksen jälkeen reititin vaihtaa pyyntövirran takaisin vihreä palvelin.
Kaikki näyttää erittäin hyvältä ja ensi silmäyksellä siinä ei pitäisi olla mitään ongelmia.
Mutta koska elämme modernissa maailmassa, vaihtoehto fyysisellä vaihdolla, kuten klassisessa järjestelmässä on ilmoitettu, ei sovi meille. Tallenna tiedot toistaiseksi, palaamme niihin myöhemmin.
Huono ja hyvä neuvo
Vastuun kieltäminen: Alla olevat esimerkit osoittavat käyttämäni apuohjelmat/menetelmät, voit käyttää mitä tahansa vaihtoehtoja, joilla on samanlaiset toiminnot.
Suurin osa esimerkeistä risteää tavalla tai toisella web-kehityksen kanssa (tämä on yllätys), PHP:n ja Dockerin kanssa.
Alla olevissa kappaleissa on yksinkertainen käytännön kuvaus tekijöiden käytöstä tiettyjen esimerkkien avulla. Jos haluat saada lisää teoriaa tästä aiheesta, seuraa yllä olevia linkkejä alkuperäiseen lähteeseen.
1. Koodikanta
Käytä FTP:tä ja FileZillaa tiedostojen lataamiseen palvelimille yksi kerrallaan, älä tallenna koodia muualle kuin tuotantopalvelimelle.
Projektilla tulee aina olla yksi koodikanta, eli kaikki koodi tulee yhdestä mennä arkisto. Palvelimet (tuotanto, vaiheistus, testi1, testi2...) käyttävät koodia yhden yhteisen tietovaraston haaroista. Näin saavutamme koodin johdonmukaisuuden.
2. Riippuvuudet
Lataa kaikki kansioissa olevat kirjastot suoraan projektin juureen. Tee päivitykset yksinkertaisesti siirtämällä uusi koodi kansioon, jossa on kirjaston nykyinen versio. Asenna kaikki tarvittavat apuohjelmat suoraan isäntäpalvelimelle, jossa on käynnissä 20 muuta palvelua.
Projektissa tulee aina olla selkeästi ymmärrettävä lista riippuvuuksista (riippuvuuksilla tarkoitan myös ympäristöä). Kaikki riippuvuudet on määriteltävä tarkasti ja eristettävä.
Otetaanpa esimerkkinä säveltää и Satamatyöläinen.
säveltää — paketinhallinta, jonka avulla voit asentaa kirjastoja PHP:ssä. Composerin avulla voit määrittää versiot tiukasti tai löyhästi ja määritellä ne erikseen. Palvelimella voi olla 20 erilaista projektia ja jokaisella on henkilökohtainen lista paketeista ja kirjastoista toisistaan riippumatta.
Satamatyöläinen — apuohjelma, jonka avulla voit määrittää ja eristää ympäristön, jossa sovellus toimii. Näin ollen, aivan kuten säveltäjän kanssa, mutta perusteellisemmin voimme määrittää, minkä kanssa sovellus toimii. Valitse tietty PHP-versio, asenna vain projektin toimimiseen tarvittavat paketit lisäämättä mitään ylimääräistä. Ja mikä tärkeintä, häiritsemättä isäntäkoneen ja muiden projektien paketteja ja ympäristöä. Eli kaikki Dockerin kautta käynnissä olevat palvelimen projektit voivat käyttää täysin mitä tahansa pakettijoukkoa ja täysin erilaista ympäristöä.
3. Kokoonpano
Tallenna konfiguraatiot vakioina suoraan koodiin. Erilliset vakiot testipalvelimelle, erilliset tuotannolle. Sido sovelluksen toiminta ympäristöstä riippuen suoraan projektin liiketoimintalogiikkaan käyttämällä if else -konstruktioita.
Kokoonpanot - Tämä on ainoa tapa, jolla projektien käyttöönotot voivat vaihdella. Ihannetapauksessa kokoonpanot tulisi siirtää ympäristömuuttujien (env vars) kautta.
Eli vaikka tallennat useita konfiguraatiotiedostoja .config.prod .config.local ja nimeät ne uudelleen käyttöönoton yhteydessä .config-tiedostoiksi (pääkonfiguraatio, josta sovellus lukee tietoja), tämä ei ole oikea tapa, koska tässä tapauksessa kokoonpanojen tiedot ovat julkisesti kaikkien sovelluskehittäjien saatavilla ja tuotantopalvelimen tiedot vaarantuvat. Kaikki konfiguraatiot on tallennettava suoraan käyttöönottojärjestelmään (CI/CD) ja luotava eri ympäristöille erilaisilla arvoilla, joita tietylle ympäristölle tarvitaan käyttöönottohetkellä.
4. Kolmannen osapuolen palvelut
Ole tiukasti sidottu ympäristöön, käytä eri yhteyksiä samoihin palveluihin tietyissä ympäristöissä.
Itse asiassa tämä kohta on vahvasti päällekkäinen konfiguraatioita koskevan kohdan kanssa, koska ilman tätä kohtaa ei voida tehdä normaaleja konfigurointitietoja ja yleensä konfigurointikyky putoaa tyhjään.
Kaikkien yhteyksien ulkoisiin palveluihin, kuten jonopalvelimiin, tietokantoihin, välimuistipalveluihin, on oltava samat sekä paikallisessa ympäristössä että kolmannen osapuolen/tuotantoympäristössä. Toisin sanoen milloin tahansa vaihtamalla yhteysmerkkijonoa voin korvata puhelut tukiasemaan #1 kantanumerolla 2 muuttamatta sovelluskoodia. Tai eteenpäin katsottuna esimerkiksi palvelua skaalattaessa sinun ei tarvitse määrittää yhteyttä millään erityisellä tavalla lisävälimuistipalvelimelle.
5. Rakenna, vapauta, suorita
Pidä vain koodin lopullinen versio palvelimella ilman mahdollisuutta peruuttaa julkaisua. Ei tarvitse täyttää levytilaa. Jokainen, joka luulee voivansa vapauttaa koodin tuotantoon virheellä, on huono ohjelmoija!
Kaikki käyttöönottovaiheet on erotettava toisistaan.
On mahdollisuus palata takaisin. Tee julkaisut sovelluksen vanhoilla kopioilla (jo koottuna ja valmiina taisteluun), jotka on tallennettu pikakäyttöön, jotta voit palauttaa vanhan version virhetilanteissa. Eli ehdollisesti on olemassa kansio Tiedotteet ja kansio nykyinen, ja onnistuneen käyttöönoton ja kansion kokoamisen jälkeen nykyinen yhdistää symbolisen linkin sisällä olevaan uuteen julkaisuun Tiedotteet julkaisunumeron tavanomaisella nimellä.
Tästä muistamme Blue-Green-asennuksen, jonka avulla voit vaihtaa koodin välillä, mutta myös vaihtaa kaikkien resurssien ja jopa ympäristöjen välillä ja palauttaa kaiken.
6. Prosessit
Tallenna sovelluksen tilatiedot suoraan itse sovellukseen. Käytä istuntoja itse sovelluksen RAM-muistissa. Käytä mahdollisimman paljon jakamista kolmansien osapuolten palveluiden välillä. Luota siihen, että sovelluksella voi olla vain yksi prosessi, äläkä salli skaalausta.
Istuntojen osalta tallenna tiedot vain välimuistiin, jota hallitsevat kolmannen osapuolen palvelut (memcached, redis), joten vaikka sinulla olisi käynnissä 20 sovellusprosessia, mikä tahansa niistä voi välimuistiin päästyäsi jatkaa työskentelyä asiakkaan kanssa samassa tilassa, jossa käyttäjä työskenteli sovelluksen kanssa toisessa prosessissa. Tällä lähestymistavalla käy ilmi, että riippumatta siitä, kuinka monta kopiota kolmannen osapuolen palveluista käytät, kaikki toimii normaalisti ja ilman ongelmia pääsyssä tietoihin.
7. Porttisidonta
Vain verkkopalvelimen tulisi tietää, kuinka toimia kolmannen osapuolen palveluiden kanssa. Tai vielä parempaa, asenna kolmannen osapuolen palvelut suoraan verkkopalvelimeen. Esimerkiksi PHP-moduulina Apachessa.
Kaikkien palvelujesi on oltava toistensa käytettävissä jonkin osoitteen ja portin kautta (localgost:5432, localhost:3000, nginx:80, php-fpm:9000), eli nginxistä voin käyttää sekä php- fpm- että postgres, ja php-fpm:stä postgresiin ja nginxiin ja itse asiassa jokaisesta palvelusta pääsen toiseen palveluun. Näin palvelun elinkelpoisuus ei ole sidottu toisen palvelun elinkelpoisuuteen.
8. Rinnakkaisuus
Työskentele yhden prosessin kanssa, muuten useat prosessit eivät tule toimeen keskenään!
Jätä tilaa skaalautumiseen. Docker-parvi on hyvä tähän.
Docker Swarm on työkalu konttiklustereiden luomiseen ja hallintaan sekä eri koneiden että saman koneen konttijoukon välillä.
Swarmin avulla voin määrittää, kuinka monta resurssia varaan kullekin prosessille ja kuinka monta saman palvelun prosessia käynnistän, ja sisäinen tasapainotin, joka vastaanottaa tietoja tietystä portista, välittää sen automaattisesti prosesseille. Näin ollen, kun näen palvelimen kuormituksen lisääntyneen, voin lisätä prosesseja, mikä vähentää tiettyjen prosessien kuormitusta.
9. Kertakäyttö
Älä käytä jonoja prosessien ja tietojen käsittelyyn. Yhden prosessin lopettamisen pitäisi vaikuttaa koko sovellukseen. Jos yksi palvelu kaatuu, kaikki menee alas.
Jokainen prosessi ja palvelu voidaan kytkeä pois päältä milloin tahansa, eikä tämän pitäisi vaikuttaa muihin palveluihin (tämä ei tietenkään tarkoita, että palvelu ei olisi käytettävissä toiselle palvelulle, vaan että toinen palvelu ei sammu tämän jälkeen). Kaikki prosessit on lopetettava sulavasti, jotta ne lopetettaessa tiedot eivät vaurioidu ja järjestelmä toimii oikein seuraavan kerran kun käynnistät sen. Eli tietoja ei saa vahingoittua hätäkeskeytyksessäkään (tapahtumamekanismi sopii tähän, tietokannan kyselyt toimivat vain ryhmissä ja jos vähintään yksi kysely ryhmästä epäonnistuu tai suoritetaan virhe, niin mikään muu ryhmän kysely ei lopulta epäonnistu).
10. Sovelluskehityksen/toiminnan pariteetti
Sovelluksen tuotannon, lavastuksen ja paikallisen version on oltava erilaisia. Tuotannossa käytämme Yii Lite -kehystä ja paikallisesti Yiiä, jotta se toimii nopeammin tuotannossa!
Todellisuudessa kaikkien käyttöönottojen ja koodin kanssa työskentelyn tulisi olla lähes identtisessä ympäristössä (emme puhu fyysisistä laitteistoista). Myös kenen tahansa kehitystyöntekijän pitäisi pystyä tarvittaessa ottamaan koodi käyttöön tuotantoon, ei jonkun erityisen koulutetun devops-osaston, joka vain erikoisvoimansa ansiosta pystyy nostamaan sovelluksen tuotantoon.
Docker auttaa meitä myös tässä. Jos kaikki edelliset kohdat huomioidaan, dockerin käyttö tuo ympäristön käyttöönottoprosessin sekä tuotantoon että paikalliseen koneeseen yhden tai kahden komennon syöttämiseen.
11. Lokit
Kirjoitamme lokeja tiedostoihin ja tietokantoihin! Emme puhdista tiedostoja ja tietokantoja lokeista. Ostetaan vain 9000 Peta-tavun kovalevy ja se on hyvä.
Kaikki lokit tulee pitää tapahtumavirtana. Itse sovellus ei saa olla mukana lokien käsittelyssä. Lokit tulee tulostaa joko stdoutiin tai lähettää protokollan, kuten udp:n, kautta, jotta lokien käsittely ei aiheuta ongelmia sovellukselle. graylog on hyvä tähän. Graylog, joka vastaanottaa kaikki lokit udp:n kautta (tämä protokolla ei vaadi vastausta odottamaan paketin onnistuneesta vastaanotosta) ei häiritse sovellusta millään tavalla ja käsittelee vain lokien strukturointia ja käsittelyä. Sovelluslogiikka ei muutu toimimaan tällaisten lähestymistapojen kanssa.
12. Hallintotehtävät
Päivitä tiedot, tietokannat jne. käyttämällä erikseen luotua päätepistettä API:ssa. Sen suorittaminen 2 kertaa peräkkäin johtaa kaiken päällekkäisyyteen. Mutta et ole tyhmä, et klikkaa kahdesti, emmekä tarvitse siirtoa.
Kaikki hallintatehtävät tulee suorittaa samassa ympäristössä kuin kaikki koodit, julkaisutasolla. Eli jos meidän on muutettava tietokannan rakennetta, emme tee sitä manuaalisesti muuttamalla sarakkeiden nimiä ja lisäämällä uusia visuaalisten tietokannan hallintatyökalujen kautta. Tällaisia asioita varten luomme erilliset skriptit - migraatiot, jotka suoritetaan kaikkialla ja kaikissa ympäristöissä samalla tavalla yhteisellä ja ymmärrettävällä tuloksella. Kaikissa muissa tehtävissä, kuten projektin täyttämisessä tiedoilla, tulisi käyttää samanlaisia menetelmiä.
Esimerkki toteutuksesta PHP:ssä, Laravelissa, Laradockissa, Docker-Composessa
PS Kaikki esimerkit on tehty MacOS:lla. Suurin osa niistä sopii myös Linuxille. Windows-käyttäjät, anteeksi, mutta en ole työskennellyt Windowsin kanssa pitkään aikaan.
Kuvitellaanpa tilanne, jossa meillä ei ole yhtään PHP-versiota asennettuna PC:llemme eikä yhtään mitään.
Asenna dockerin ja docker-composen uusimmat versiot. (tämä löytyy netistä)
docker -v &&
docker-compose -v
1. Laita
git clone https://github.com/Laradock/laradock.git &&
ls
Laradockista sanon, että se on erittäin siisti juttu, joka sisältää paljon kontteja ja apuvälineitä. Mutta en suosittele Laradockin käyttöä sellaisenaan ilman muutoksia tuotannossa sen redundanssin vuoksi. On parempi luoda omat kontit Laradockin esimerkkien perusteella, tämä on paljon optimoitumpaa, koska kukaan ei tarvitse kaikkea siellä olevaa yhtä aikaa.
2. Määritä Laradock suorittamaan sovelluksemme.
cd laradock &&
cp env-example .env
2.1. Avaa habr-hakemisto (emokansio, johon laradock on kloonattu) jossain editorissa. (Omassa PHPStorm-tapauksessani)
Tässä vaiheessa annamme projektille vain nimen.
2.2. Käynnistä työtilan kuva. (Sinun tapauksessa kuvien rakentaminen kestää jonkin aikaa)
Workspace on erityisesti valmistettu kuva, joka on tarkoitettu työskentelemään kehyksen kanssa kehittäjän puolesta.
Menemme säiliöön käyttämällä
docker-compose up -d workspace &&
docker-compose exec workspace bash
2.3. Laravelin asennus
composer create-project --prefer-dist laravel/laravel application
2.4. Asennuksen jälkeen tarkistamme, onko projektin hakemisto luotu ja lopetamme compose.
ls
exit
docker-compose down
2.5. Palataan PHPStormiin ja asetetaan oikea polku laravel-sovelluksellemme .env-tiedostossa.
3. Lisää kaikki koodi Gitiin.
Tätä varten luomme arkiston Githubiin (tai mihin tahansa muualle). Mennään terminaalin habr-hakemistoon ja suoritetaan seuraava koodi.
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
Katsotaan onko kaikki kunnossa.
Mukavuuden vuoksi suosittelen käyttämään jotain visuaalista käyttöliittymää Gitille, minun tapauksessani se on . (tässä viittauslinkki)
4. Aloitetaan!
Ennen kuin aloitat, varmista, että porteissa 80 ja 443 ei roiku mitään.
docker-compose up -d nginx php-fpm
Projektimme koostuu siis kolmesta erillisestä palvelusta:
- nginx - verkkopalvelin
- php-fpm - php pyyntöjen vastaanottamiseen web-palvelimelta
- työtila - php kehittäjille
Tällä hetkellä olemme saavuttaneet, että olemme luoneet sovelluksen, joka täyttää 4 pistettä 12:sta, nimittäin:
1. Koodikanta — kaikki koodi on yhdessä arkistossa (pieni huomautus: saattaa olla oikein lisätä docker laravel-projektiin, mutta tämä ei ole tärkeää).
2. Riippuvuudet - Kaikki riippuvuutemme on kirjoitettu nimenomaisesti tiedostoon application/composer.json ja kunkin säilön jokaiseen Docker-tiedostoon.
3. Tukipalvelut — Kukin palveluista (php-fom, nignx, työtila) elää omaa elämäänsä ja on yhteydessä ulkopuolelta, ja yhden palvelun kanssa työskentely ei vaikuta toiseen.
4. prosessit — Jokainen palvelu on yksi prosessi. Jokainen palvelu ei ylläpidä sisäistä tilaa.
5. Porttisidonta
docker ps
Kuten näemme, jokainen palvelu toimii omassa portissaan ja on kaikkien muiden palveluiden käytettävissä.
6. rinnakkaisuus
Dockerin avulla voimme luoda useita samojen palvelujen prosesseja automaattisen kuormituksen tasapainotuksen avulla.
Pysäytetään kontit ja ajetaan ne lipun läpi -- mittakaava
docker-compose down &&
docker-compose up -d --scale php-fpm=3 nginx php-fpm
Kuten näemme, php-fpm-säiliöstä on luotu kopioita. Meidän ei tarvitse muuttaa mitään työskennellessämme tämän kontin kanssa. Jatkamme pääsyä siihen myös portista 9000, ja Docker säätelee konttien välistä kuormaa puolestamme.
7. Kertakäyttöisyys - jokainen säiliö voidaan tappaa vahingoittamatta toista. Säilön pysäyttäminen tai uudelleenkäynnistys ei vaikuta sovelluksen toimintaan myöhempien käynnistysten aikana. Jokainen kontti voidaan myös nostaa milloin tahansa.
8. Sovelluskehitys/käyttöpariteetti - Kaikki ympäristömme ovat samanlaisia. Kun käytät järjestelmää tuotannossa olevalla palvelimella, sinun ei tarvitse muuttaa mitään komentojasi. Kaikki perustuu Dockeriin samalla tavalla.
9. Kirjaaminen — kaikki näissä säilöissä olevat lokit menevät streamiin ja näkyvät Docker-konsolissa. (tässä tapauksessa itse asiassa muiden kotitekoisten astioiden kanssa näin ei ehkä ole, jos et pidä siitä huolta)
docker-compose logs -f
Mutta siinä on saalis, että PHP:n ja Nginxin oletusarvot kirjoittavat myös lokeja tiedostoon. 12 tekijän täyttäminen on välttämätöntä sammuttaa lokien kirjoittaminen tiedostoon kunkin säilön kokoonpanoissa erikseen.
Docker tarjoaa myös mahdollisuuden lähettää lokeja ei vain stdoutiin, vaan myös sellaisiin asioihin, kuten greylog, jonka mainitsin edellä. Ja greylogin sisällä voimme käyttää lokeja haluamallamme tavalla, eikä sovelluksemme huomaa tätä millään tavalla.
10. Hallintotehtävät — Laravel ratkaisee kaikki hallintotehtävät artesaanityökalun ansiosta juuri niin kuin 12 tekijän sovelluksen tekijät haluavat.
Esimerkkinä näytän kuinka jotkut komennot suoritetaan.
Menemme konttiin.
docker-compose exec workspace bash
php artisan list
Nyt voimme käyttää mitä tahansa komentoa. (Huomaa, että emme määrittäneet tietokantaa ja välimuistia, joten puolet komennoista ei suoriteta oikein, koska ne on suunniteltu toimimaan välimuistin ja tietokannan kanssa).
11. Kokoonpanot ja 12. Rakenna, vapauta, juokse
Halusin omistaa tämän osan Blue-Green Deploymentille, mutta se osoittautui liian laajaksi tätä artikkelia varten. Kirjoitan tästä erillisen artikkelin.
Lyhyesti sanottuna konsepti perustuu CI/CD-järjestelmiin, kuten Jenkins и Gitlab CI. Molemmissa voit asettaa tiettyyn ympäristöön liittyviä ympäristömuuttujia. Näin ollen tässä tilanteessa kohta c täyttyy Kokoonpanot.
Ja pointti siitä Rakenna, vapauta, juokse on ratkaistu sisäänrakennetuilla funktioilla nimellä Putki.
Putki avulla voit jakaa käyttöönottoprosessin useisiin vaiheisiin korostaen kokoonpano-, julkaisu- ja toteutusvaiheita. Myös Pipelinessa voit luoda varmuuskopioita ja oikeastaan mitä tahansa. Tämä on työkalu, jolla on rajaton potentiaali.
Sovelluskoodi on osoitteessa .
Älä unohda alustaa alimoduulia tätä arkistoa kloonattaessa.
PS: Kaikkia näitä lähestymistapoja voidaan käyttää kaikkien muiden apuohjelmien ja ohjelmointikielien kanssa. Tärkeintä on, että olemus ei eroa.
Lähde: will.com