Ehdotan, että luet Inventoksen Alexander Sigachevin raportin "Kehitys- ja testausprosessi Docker + Gitlab CI:n kanssa"
Ne, jotka ovat vasta aloittamassa Docker + Gitlab CI -pohjaisen kehitys- ja testausprosessin käyttöönottoa, kysyvät usein peruskysymyksiä. Mistä aloittaa? Kuinka järjestää? Kuinka testata?
Tämä raportti on hyvä, koska siinä puhutaan jäsennellysti kehitys- ja testausprosessista Dockerin ja Gitlab CI:n avulla. Itse raportti on vuodelta 2017. Uskon, että tästä raportista voit oppia perusteet, metodologian, idean, käyttökokemuksen.
Ketä kiinnostaa, ota kissan alle.
Nimeni on Alexander Sigachev. Työskentelen Inventoksella. Kerron kokemuksestani Dockerin käytöstä ja siitä, kuinka otamme sitä vähitellen käyttöön projekteissa yrityksessä.
Esityksen aihe: Kehitysprosessi Dockerin ja Gitlab CI:n avulla.
Tämä on toinen puheeni Dockerista. Ensimmäisen raportin ajankohtana käytimme vain Docker in Development -kehittäjäkoneissa. Dockeria käyttäneiden työntekijöiden määrä oli noin 2-3 henkilöä. Vähitellen kokemusta kertyi ja siirryimme vähän pidemmälle. Linkki meidän .
Mitä tässä raportissa tulee olemaan? Kerromme kokemuksemme siitä, mitä rakea olemme keränneet, mitä ongelmia olemme ratkaisseet. Ei kaikkialla ollut kaunista, mutta sai jatkaa eteenpäin.
Mottomme on: telakkaa kaikki, mikä on käsiimme.
Mitä ongelmia ratkaisemme?
Kun yrityksessä on useita ryhmiä, ohjelmoija on yhteinen resurssi. On vaiheita, jolloin ohjelmoija vedetään pois yhdestä projektista ja annetaan jonkin aikaa toiseen projektiin.
Jotta ohjelmoija ymmärtää nopeasti, hänen on ladattava projektin lähdekoodi ja käynnistettävä ympäristö mahdollisimman pian, mikä antaa hänelle mahdollisuuden siirtyä eteenpäin tämän projektin ongelmien ratkaisemiseksi.
Yleensä, jos aloitat tyhjästä, projektissa on vähän dokumentaatiota. Tietoja määrittämisestä on saatavilla vain vanhoille käyttäjille. Työntekijät perustavat työpaikkansa omatoimisesti yhdessä tai kahdessa päivässä. Tämän nopeuttamiseksi käytimme Dockeria.
Seuraava syy on asetusten standardointi kehitystyössä. Kokemukseni mukaan kehittäjät tekevät aina aloitteen. Joka viidennessä tapauksessa syötetään mukautettu verkkotunnus, esimerkiksi vasya.dev. Hänen vieressään istuu hänen naapurinsa Petya, jonka verkkotunnus on petya.dev. He kehittävät verkkosivuston tai jonkin järjestelmän osan käyttämällä tätä verkkotunnusta.
Kun järjestelmä kasvaa ja nämä verkkotunnukset alkavat päästä kokoonpanoihin, syntyy kehitysympäristöristiriita ja sivuston polku kirjoitetaan uudelleen.
Sama tapahtuu tietokannan asetuksissa. Joku ei välitä turvallisuudesta ja työskentelee tyhjällä root-salasanalla. Asennusvaiheessa MySQL kysyi joltakin salasanaa ja salasanaksi osoittautui 123. Usein käy niin, että tietokannan konfiguraatio muuttuu jatkuvasti kehittäjän sitoutumisesta riippuen. Joku korjasi, joku ei korjannut asetusta. Oli temppuja, kun otimme jonkinlaisen testikonfiguraation sisään .gitignore ja jokaisen kehittäjän oli asennettava tietokanta. Tämä vaikeutti aloittamista. On tarpeen muistaa muun muassa tietokannasta. Tietokanta on alustettava, salasana on syötettävä, käyttäjä on rekisteröitävä, taulukko on luotava ja niin edelleen.
Toinen ongelma ovat kirjastojen erilaiset versiot. Usein käy niin, että kehittäjä työskentelee erilaisten projektien parissa. On olemassa Legacy-projekti, joka alkoi viisi vuotta sitten (vuodesta 2017 - toim. huomautus). Käynnistyshetkellä aloitimme MySQL 5.5:llä. On myös nykyaikaisia projekteja, joissa yritämme ottaa käyttöön nykyaikaisempia MySQL-versioita, esimerkiksi 5.7 tai vanhempi (vuonna 2017 - toim. huomautus)
Jokainen, joka työskentelee MySQL:n kanssa, tietää, että nämä kirjastot tuovat mukanaan riippuvuuksia. On melko ongelmallista ajaa kahta kantaa yhdessä. Ainakin vanhoilla asiakkailla on ongelmia muodostaa yhteys uuteen tietokantaan. Tämä puolestaan aiheuttaa useita ongelmia.
Seuraava ongelma on, kun kehittäjä työskentelee paikallisella koneella, hän käyttää paikallisia resursseja, paikallisia tiedostoja ja paikallista RAM-muistia. Kaikki vuorovaikutus ongelmiin ratkaisun kehittämisen aikana tapahtuu sen tosiasian puitteissa, että se toimii yhdessä koneessa. Esimerkki on, kun meillä on taustapalvelimet Production 3:ssa, ja kehittäjä tallentaa tiedostot juurihakemistoon ja sieltä nginx ottaa tiedostoja vastatakseen pyyntöön. Kun tällainen koodi joutuu tuotantoon, käy ilmi, että tiedosto on jollakin kolmesta palvelimesta.
Mikropalveluiden suunta on nyt kehittymässä. Kun jaamme suuret sovelluksemme pieniin komponentteihin, jotka ovat vuorovaikutuksessa toistensa kanssa. Tämän avulla voit valita tekniikoita tiettyä tehtäväpinoa varten. Sen avulla voit myös jakaa työt ja vastuut kehittäjien kesken.
Frondend-kehittäjä, joka kehittää JS:ää, ei juurikaan vaikuta Backendiin. Taustakehittäjä puolestaan kehittää meidän tapauksessamme Ruby on Railsia, eikä sekaannu Frondendin toimintaan. Vuorovaikutus suoritetaan API:n avulla.
Bonuksena pystyimme Dockerin avulla kierrättämään Stagingin resursseja. Jokainen projekti vaati sen erityispiirteiden vuoksi tiettyjä asetuksia. Fyysisesti oli tarpeen varata joko virtuaalipalvelin ja konfiguroida ne erikseen tai jakaa jonkinlainen muuttuva ympäristö ja projektit saattoivat kirjastojen versiosta riippuen vaikuttaa toisiinsa.
Työkalut. Mitä käytämme?
- Docker itse. Docker-tiedosto kuvaa yksittäisen sovelluksen riippuvuuksia.
- Docker-compose on paketti, joka yhdistää muutamia Docker-sovelluksiamme.
- Käytämme GitLabia lähdekoodin tallentamiseen.
- Käytämme GitLab-CI:tä järjestelmäintegraatioon.
Raportti koostuu kahdesta osasta.
Ensimmäinen osa kertoo siitä, kuinka Dockeria ajettiin kehittäjien koneilla.
Toisessa osassa puhutaan siitä, kuinka ollaan vuorovaikutuksessa GitLabin kanssa, kuinka suoritamme testejä ja kuinka otamme käyttöön Stagingin.
Docker on tekniikka, jonka avulla (käyttäen deklaratiivista lähestymistapaa) voidaan kuvata tarvittavat komponentit. Tämä on esimerkki Dockerfile-tiedostosta. Tässä ilmoitamme, että perimme virallisen Ruby:2.3.0 Docker -kuvan. Se sisältää Rubyn version 2.3 asennettuna. Asennamme tarvittavat rakennuskirjastot ja NodeJS. Kuvaamme, että luomme hakemiston /app. Aseta sovellushakemisto työhakemistoksi. Tähän hakemistoon sijoitamme vaaditut minimaaliset Gemfile ja Gemfile.lock. Rakennamme sitten projektit, jotka asentavat tämän riippuvuuskuvan. Ilmoitamme, että kontti on valmis kuuntelemaan ulkoisessa portissa 3000. Viimeinen komento on komento, joka käynnistää sovelluksemme suoraan. Jos suoritamme projektin aloituskomennon, sovellus yrittää suorittaa määritetyn komennon.
Tämä on minimaalinen esimerkki telakointiaseman kirjoitustiedostosta. Tässä tapauksessa osoitamme, että kahden kontin välillä on yhteys. Tämä on suoraan tietokantapalveluun ja verkkopalveluun. Verkkosovelluksemme vaativat useimmiten jonkinlaisen tietokannan taustana tietojen tallentamiseen. Koska käytämme MySQL, esimerkki on MySQL - mutta mikään ei estä meitä käyttämästä jotain muuta tietokantaa (PostgreSQL, Redis).
Otamme virallisesta lähteestä Docker-keskittimestä kuvan MySQL 5.7.14:stä ilman muutoksia. Keräämme verkkosovelluksestamme vastaavan kuvan nykyisestä hakemistosta. Se kerää meille kuvan ensimmäisen käynnistyksen aikana. Sitten se suorittaa komennon, jonka suoritamme täällä. Jos palaamme takaisin, näemme, että käynnistyskomento Puman kautta on määritetty. Puma on Ruby-kielellä kirjoitettu palvelu. Toisessa tapauksessa ohitamme. Tämä komento voi olla mielivaltainen tarpeidemme tai tehtäviemme mukaan.
Kuvaamme myös, että meidän on välitettävä portti kehittäjäisäntäkoneellamme 3000:sta 3000:een konttiportissa. Tämä tapahtuu automaattisesti käyttämällä iptablesia ja sen mekanismia, joka on suoraan upotettu Dockeriin.
Kehittäjä voi myös, kuten ennenkin, käyttää mitä tahansa saatavilla olevaa IP-osoitetta, esimerkiksi 127.0.0.1 on koneen paikallinen tai ulkoinen IP-osoite.
Viimeisellä rivillä sanotaan, että verkkosäilö riippuu db-säilöstä. Kun kutsumme verkkosäilön alkua, docker-compose käynnistää ensin tietokannan puolestamme. Jo tietokannan alussa (itse asiassa kontin käynnistämisen jälkeen! Tämä ei takaa tietokannan valmiutta) käynnistää sovelluksen, taustamme.
Tämä välttää virheet, kun tietokantaa ei tuoda esiin, ja säästää resursseja, kun pysäytämme tietokantasäiliön, mikä vapauttaa resursseja muille projekteille.
Mikä antaa meille mahdollisuuden käyttää tietokannan telakointia projektissa. Korjaamme MySQL-version kaikille kehittäjille. Näin vältetään jotkin virheet, joita saattaa ilmetä, kun versiot eroavat toisistaan, kun syntaksi, kokoonpano ja oletusasetukset muuttuvat. Tämän avulla voit määrittää tietokannalle yhteisen isäntänimen, kirjautumistunnuksen ja salasanan. Olemme siirtymässä pois nimien ja ristiriitojen eläintarhasta konfigurointitiedostoissa, jotka meillä oli aiemmin.
Meillä on mahdollisuus käyttää kehitysympäristölle optimaalista konfiguraatiota, joka poikkeaa oletusarvosta. MySQL on oletusarvoisesti määritetty heikkoja koneita varten ja sen suorituskyky on erittäin huono.
Dockerin avulla voit käyttää halutun version Python-, Ruby-, NodeJS-, PHP-tulkkia. Pääsemme eroon tarpeesta käyttää jonkinlaista versionhallintaa. Aiemmin Ruby käytti rpm-pakettia, jonka avulla voit muuttaa versiota projektista riippuen. Docker-säilön ansiosta se mahdollistaa myös koodin sujuvan siirtämisen ja versioinnin yhdessä riippuvuuksien kanssa. Meillä ei ole ongelmaa ymmärtää sekä tulkin että koodin versiota. Päivitä versio laskemalla vanha säilö ja nostamalla uutta säilöä. Jos jokin meni pieleen, voimme laskea uuden kontin, nostaa vanhaa konttia.
Kuvan rakentamisen jälkeen sekä kehityksen että tuotannon kontit ovat samat. Tämä pätee erityisesti suuriin asennuksiin.
Käyttöliittymässä käytämme JavaSciptiä ja NodeJS:ää.
Nyt meillä on viimeinen projekti ReacJS:ssä. Kehittäjä ajoi kaiken säiliössä ja kehitti käyttämällä hot-reloadia.
Seuraavaksi käynnistetään JavaScipt-kokoonpanotehtävä ja statiikkaan koottu koodi annetaan nginx-säästöresurssien kautta.
Tässä olen antanut viimeisimmän projektimme kaavion.
Mitä tehtäviä ratkaistiin? Meillä oli tarve rakentaa järjestelmä, jonka kanssa mobiililaitteet ovat vuorovaikutuksessa. He vastaanottavat dataa. Yksi mahdollisuus on lähettää push-ilmoituksia tähän laitteeseen.
Mitä olemme tehneet tämän eteen?
Jaoimme sovellukseen sellaiset komponentit kuin: JS:n järjestelmänvalvojan osa, backend, joka toimii REST-rajapinnan kautta Ruby on Railsin alla. Taustaohjelma on vuorovaikutuksessa tietokannan kanssa. Syntynyt tulos annetaan asiakkaalle. Hallintapaneeli on vuorovaikutuksessa taustajärjestelmän ja tietokannan kanssa REST-liitännän kautta.
Meillä oli myös tarve lähettää push-ilmoituksia. Sitä ennen meillä oli projekti, jossa toteutettiin mekanismi, joka vastaa ilmoitusten toimittamisesta mobiilialustoille.
Olemme kehittäneet seuraavan kaavan: selaimen operaattori on vuorovaikutuksessa hallintapaneelin kanssa, hallintapaneeli vuorovaikutuksessa taustajärjestelmän kanssa, tehtävänä on lähettää Push-ilmoituksia.
Push-ilmoitukset ovat vuorovaikutuksessa toisen komponentin kanssa, joka on toteutettu NodeJS:ssä.
Jonot rakennetaan ja ilmoitukset lähetetään niiden mekanismin mukaisesti.
Tässä on piirretty kaksi tietokantaa. Tällä hetkellä käytämme Dockerin avulla kahta itsenäistä tietokantaa, jotka eivät liity toisiinsa millään tavalla. Lisäksi niillä on yhteinen virtuaalinen verkko, ja fyysiset tiedot on tallennettu eri hakemistoihin kehittäjän koneella.
Sama, mutta numeroina. Tässä koodin uudelleenkäyttö on tärkeää.
Jos aiemmin puhuimme koodin uudelleenkäytöstä kirjastojen muodossa, niin tässä esimerkissä Push-ilmoituksiin reagoivaa palveluamme käytetään uudelleen kokonaisena palvelimena. Se tarjoaa API:n. Ja uusi kehitystyömme on jo vuorovaikutuksessa sen kanssa.
Tuolloin käytimme NodeJS:n versiota 4. Nyt (vuonna 2017 - toim. huomautus) käytämme viimeaikaisessa kehityksessä NodeJS:n versiota 7. Uusissa komponenteissa ei ole ongelmaa sisällyttää kirjastojen uusia versioita.
Tarvittaessa voit muuttaa ja nostaa NodeJS-version Push-ilmoituspalvelusta.
Ja jos voimme ylläpitää API-yhteensopivuutta, se on mahdollista korvata muilla aiemmin käytetyillä projekteilla.
Mitä tarvitset Dockerin lisäämiseen? Lisäämme arkistoon Docker-tiedoston, joka kuvaa tarvittavat riippuvuudet. Tässä esimerkissä komponentit on jaettu loogisesti. Tämä on taustakehittäjän vähimmäisjoukko.
Kun luomme uutta projektia, luomme Docker-tiedoston, kuvaamme halutun ekosysteemin (Python, Ruby, NodeJS). Docker-composessa se kuvaa tarvittavan riippuvuuden - tietokannan. Kuvaamme, että tarvitsemme tietokannan sellaisesta ja sellaisesta versiosta, tallennamme tietoja sinne tänne.
Käytämme erillistä kolmatta säiliötä nginxillä palvelemaan staattista. On mahdollista ladata kuvia. Backend laittaa ne valmiiksi valmistettuun tilavuuteen, joka on myös asennettu säiliöön, jossa on nginx, mikä antaa staattista.
Nginx-, mysql-kokoonpanon tallentamiseksi lisäsimme Docker-kansion, johon tallennamme tarvittavat asetukset. Kun kehittäjä tekee arkiston git-kloonin koneellaan, hänellä on jo valmiina projekti paikallista kehittämistä varten. Ei ole epäilystäkään, mitä porttia tai mitä asetuksia käytetään.
Seuraavaksi meillä on useita komponentteja: admin, inform-API, push-ilmoitukset.
Tämän kaiken aloittamiseksi loimme toisen arkiston, jota kutsuimme dockerized-appiksi. Tällä hetkellä käytämme useita arkistoja ennen jokaista komponenttia. Ne ovat vain loogisesti erilaisia - GitLabissa se näyttää kansiolta, mutta kehittäjän koneella tietyn projektin kansiolta. Yksi taso alempana ovat komponentit, jotka yhdistetään.
Tämä on esimerkki vain dockerized-appin sisällöstä. Tuomme tänne myös Docker-hakemiston, johon täytämme kaikkien komponenttien vuorovaikutukseen tarvittavat konfiguraatiot. On olemassa README.md, joka kuvaa lyhyesti, kuinka projekti suoritetaan.
Tässä olemme käyttäneet kahta Docker-kirjoitustiedostoa. Tämä tehdään, jotta pystytään juoksemaan vaiheittain. Kun kehittäjä työskentelee ytimen kanssa, hän ei tarvitse push-ilmoituksia, hän yksinkertaisesti käynnistää telakointitiedoston ja vastaavasti resurssi tallennetaan.
Jos on tarvetta integroida push-ilmoituksiin, docker-compose.yaml ja docker-compose-push.yaml käynnistetään.
Koska docker-compose.yaml ja docker-compose-push.yaml ovat kansiossa, yksi virtuaalinen verkko luodaan automaattisesti.
Komponenttien kuvaus. Tämä on edistyneempi tiedosto, joka vastaa komponenttien keräämisestä. Mitä ihmeellistä tässä on? Tässä esittelemme tasapainotuskomponentin.
Tämä on valmis Docker-kuva, joka käyttää nginxiä ja sovellusta, joka kuuntelee Docker-liitäntää. Dynaaminen, kun säiliöt kytketään päälle ja pois päältä, se luo nginx-kokoonpanon uudelleen. Jaamme komponenttien käsittelyn kolmannen tason verkkotunnuksilla.
Kehitysympäristössä käytämme .dev-aluetta - api.informer.dev. Sovellukset, joissa on .dev-verkkotunnus, ovat saatavilla kehittäjän paikallisella koneella.
Lisäksi konfiguraatiot siirretään jokaiseen projektiin ja kaikki projektit käynnistetään yhdessä samanaikaisesti.
Graafisesti käy ilmi, että asiakas on selaimemme tai jokin työkalu, jolla teemme pyyntöjä tasapainottajalle.
Verkkotunnustasapainotin määrittää, mihin säilöön ottaa yhteyttä.
Se voi olla nginx, joka antaa järjestelmänvalvojalle JS:n. Tämä voi olla nginx, joka antaa API:n, tai staattiset tiedostot, jotka annetaan nginxille kuvien latausten muodossa.
Kaavio osoittaa, että kontit on yhdistetty virtuaaliverkolla ja piilotettu välityspalvelimen taakse.
Kehittäjän koneella pääset käsiksi konttiin tietäen IP, mutta periaatteessa emme käytä tätä. Suoraa pääsyä ei käytännössä tarvita.
Mitä esimerkkiä kannattaa tarkastella sovelluksesi telakointiin? Mielestäni hyvä esimerkki on MySQL:n virallinen docker-kuva.
Se on aika haastavaa. Versioita on monia. Mutta sen toiminnallisuuden avulla voit kattaa monia tarpeita, joita voi syntyä jatkokehitysprosessissa. Jos käytät aikaa ja selvität, miten se kaikki on vuorovaikutuksessa, niin uskon, että sinulla ei ole ongelmia itsensä toteuttamisessa.
Hub.docker.com sisältää yleensä linkkejä github.com-sivustoon, joka sisältää raakadataa, josta voit rakentaa kuvan itse.
Lisäksi tässä arkistossa on docker-endpoint.sh-skripti, joka vastaa alustavasta alustuksesta ja sovelluksen käynnistämisen jatkokäsittelystä.
Myös tässä esimerkissä on mahdollisuus konfiguroida käyttämällä ympäristömuuttujia. Määrittämällä ympäristömuuttujan yksittäistä säilöä suoritettaessa tai docker-compose-sovelluksen kautta, voimme sanoa, että meidän on asetettava tyhjä salasana, jotta docker pääsee juurruttamaan MySQL:ään tai mihin tahansa haluamaamme.
On mahdollisuus luoda satunnainen salasana. Sanomme, että tarvitsemme käyttäjän, meidän on asetettava käyttäjälle salasana ja meidän on luotava tietokanta.
Projekteissamme yhtenäistimme hieman Docker-tiedostoa, joka vastaa alustuksesta. Siellä korjasimme sen tarpeidemme mukaan, jotta se olisi vain laajennus sovelluksen käyttämille käyttöoikeuksille. Tämän ansiosta pystyimme yksinkertaisesti luomaan tietokannan sovelluskonsolista myöhemmin. Ruby-sovelluksissa on komento tietokantojen luomiseen, muokkaamiseen ja poistamiseen.
Tämä on esimerkki siitä, miltä tietty MySQL-versio näyttää osoitteessa github.com. Voit avata Docker-tiedoston ja nähdä, kuinka asennus sujuu siellä.
docker-endpoint.sh on aloituspisteestä vastaava komentosarja. Alkualustuksen aikana vaaditaan joitain valmisteluvaiheita, ja kaikki nämä toimet suoritetaan vain alustusskriptissä.
Siirrytään toiseen osaan.
Lähdekoodien tallentamiseksi siirryimme Gitlabiin. Tämä on melko tehokas järjestelmä, jolla on visuaalinen käyttöliittymä.
Yksi Gitlabin komponenteista on Gitlab CI. Sen avulla voit kuvata komentosarjan, jota käytetään myöhemmin koodinjakelujärjestelmän järjestämiseen tai automaattisen testauksen suorittamiseen.
Gitlab CI 2 keskustelu - raportti Ruby Russia -klubilta - melko yksityiskohtainen ja ehkä se kiinnostaa sinua.
Nyt tarkastelemme, mitä tarvitaan Gitlab CI:n aktivoimiseen. Gitlab CI:n käynnistämiseksi meidän on vain asetettava .gitlab-ci.yml-tiedosto projektin juureen.
Tässä kuvataan, että haluamme suorittaa tilasarjan, kuten testin, käyttöönotto.
Suoritamme skriptejä, jotka kutsuvat suoraan docker-composea sovelluksemme rakentamiseksi. Tämä on vain taustaesimerkki.
Seuraavaksi sanomme, että on tarpeen suorittaa siirrot tietokannan muuttamiseksi ja testien suorittamiseksi.
Jos komentosarjat suoritetaan oikein eivätkä palauta virhekoodia, järjestelmä siirtyy käyttöönoton toiseen vaiheeseen.
Käyttöönottovaihe on tällä hetkellä toteutettu vaiheittaiseksi. Emme järjestäneet nollakatkosaikaista uudelleenkäynnistystä.
Sammutamme kaikki säiliöt väkisin, ja sitten nostamme kaikki säiliöt uudelleen, jotka kerättiin ensimmäisessä vaiheessa testauksen aikana.
Käytämme nykyisen ympäristömuuttujan tietokannan siirtoja, jotka kehittäjät ovat kirjoittaneet.
Huomaa, että tämä koskee vain päähaaraa.
Muita haaroja vaihdettaessa ei suoriteta.
Käyttöönotto on mahdollista järjestää sivukonttoreiden mukaan.
Jotta voimme järjestää tämän edelleen, meidän on asennettava Gitlab Runner.
Tämä apuohjelma on kirjoitettu golangilla. Se on yksi tiedosto, kuten on yleistä Golang-maailmassa, joka ei vaadi riippuvuuksia.
Käynnistettäessä rekisteröimme Gitlab Runnerin.
Saamme avaimen Gitlabin verkkokäyttöliittymässä.
Sitten kutsumme alustuskomentoa komentorivillä.
Gitlab Runnerin käyttöönotto interaktiivisesti (Shell, Docker, VirtualBox, SSH)
Gitlab Runnerin koodi suoritetaan jokaisen toimituksen yhteydessä .gitlab-ci.yml-asetuksesta riippuen.
Miltä se näyttää visuaalisesti Gitlabissa verkkokäyttöliittymässä. Kun olemme yhdistäneet GItlab CI:n, meillä on lippu, joka näyttää koontiversion tilan tällä hetkellä.
Näemme, että 4 minuuttia sitten tehtiin sitoumus, joka läpäisi kaikki testit eikä aiheuttanut ongelmia.
Voimme tarkastella rakennuksia tarkemmin. Tässä näemme, että kaksi osavaltiota on jo ohitettu. Testaustilan ja käyttöönoton tilan välivaiheessa.
Jos napsautamme tiettyä koontiversiota, prosessissa suoritetuista komennoista tulee konsolitulosteena .gitlab-ci.yml-tiedoston mukaisesti.
Tuotehistoriamme näyttää tältä. Näemme, että onnistuneita yrityksiä oli. Kun testit on lähetetty, se ei siirry seuraavaan vaiheeseen eikä vaihekoodia päivitetä.
Mitä tehtäviä ratkaisimme lavastusvaiheessa, kun otimme käyttöön dockerin? Järjestelmämme koostuu komponenteista ja meidän oli käynnistettävä uudelleen, vain osa arkistoon päivitetyistä komponenteista, ei koko järjestelmää.
Tätä varten meidän piti murskata kaikki erillisiin kansioihin.
Kun teimme tämän, meillä oli ongelma, että Docker-compose luo oman verkkotilan jokaiselle isälle eikä näe naapurin komponentteja.
Pyörittääksemme loimme verkon Dockerissa manuaalisesti. Docker-composessa kirjoitettiin, että käytät tällaista verkkoa tähän projektiin.
Siten jokainen komponentti, joka alkaa tällä verkolla, näkee komponentit järjestelmän muissa osissa.
Seuraava ongelma on lavastuksen jakaminen useisiin projekteihin.
Koska jotta tämä kaikki näyttäisi kauniilta ja mahdollisimman läheltä tuotantoa, on hyvä käyttää porttia 80 tai 443, jota käytetään kaikkialla WEB:ssä.
Miten ratkaisimme sen? Olemme määrittäneet yhden Gitlab Runnerin kaikkiin suuriin projekteihin.
Gitlab antaa sinun ajaa useita hajautettuja Gitlab Runnereita, jotka yksinkertaisesti ottavat kaikki tehtävät vuorotellen kaoottisella tavalla ja suorittavat ne.
Jotta meillä ei olisi taloa, rajoitimme projektiemme ryhmän yhteen Gitlab Runneriin, joka selviää volyymiemme kanssa ongelmitta.
Siirsimme nginx-proxyn erilliseen käynnistysskriptiin ja lisäsimme ruudukot kaikille siinä oleville projekteille.
Projektissamme on yksi ruudukko ja tasapainottimessa useita ruudukoita projektinimien mukaan. Se voi välittää edelleen verkkotunnuksia.
Pyyntömme tulevat toimialueen kautta portissa 80 ja ne ratkaistaan konttiryhmäksi, joka palvelee tätä toimialuetta.
Mitä muita ongelmia oli? Tämä on se, mitä kaikki säilöt toimivat oletuksena pääkäyttäjänä. Tämä on juuri erilainen kuin järjestelmän juuriisäntä.
Jos kuitenkin syötät säilöön, siitä tulee pääkäyttäjän oikeudet ja tiedosto, jonka luomme tähän säilöön, saa pääkäyttäjän oikeudet.
Jos kehittäjä meni säilöön ja teki siellä komentoja, jotka luovat tiedostoja, ja poistui sitten säilystä, hänen työhakemistossaan on tiedosto, johon hänellä ei ole pääsyä.
Miten se voidaan ratkaista? Voit lisätä säilössä olevia käyttäjiä.
Mitä ongelmia ilmeni, kun lisäsimme käyttäjän?
Käyttäjää luotaessa meillä ei usein ole samaa ryhmätunnusta (UID) ja käyttäjätunnusta (GID).
Säilön ongelman ratkaisemiseksi käytämme käyttäjiä, joiden tunnus on 1000.
Meidän tapauksessamme tämä osui yhteen sen kanssa, että melkein kaikki kehittäjät käyttävät Ubuntu-käyttöjärjestelmää. Ja Ubuntussa ensimmäisen käyttäjän tunnus on 1000.
Onko meillä suunnitelmia?
Lue Dockerin dokumentaatio. Projekti kehittyy aktiivisesti, dokumentaatio muuttuu. Pari-kolme kuukautta sitten saadut tiedot ovat jo pikkuhiljaa vanhentumassa.
Jotkut ratkaisemistamme ongelmista on hyvin todennäköisesti jo ratkaistu normaalein keinoin.
Haluan siis mennä pidemmälle mennäkseni suoraan orkestraatioon.
Yksi esimerkki on Dockerin sisäänrakennettu mekanismi nimeltä Docker Swarm, joka tulee ulos laatikosta. Haluan ajaa jotain Docker Swarm -teknologiaan perustuvaa tuotannossa.
Kutusäiliöt tekevät tukkien kanssa työskentelystä hankalaa. Nyt lokit on eristetty. Ne ovat hajallaan konteissa. Yksi tehtävistä on mahdollistaa kätevä pääsy lokeihin web-käyttöliittymän kautta.
Lähde: will.com