Mites tuolla Traefikilla tarjotaan staattista sisältöä kuten html ja js jos ei halua bäkkärillä noita renderöidä ja tarjoilla? Pitää varmaan pyörittää esim. 80 portissa omaa nginx containeria joka tarjoaa filut ja sitten jossain toisessa portissa oma container jossa api/web app? Traefik sitten tarjoaa noita molempia (web app ja nginx) containereita?
Tänne kaikki kysymykset ja keskustelut Dockerista, containereista ja Kuberneteksesta.
Container eli kontti on paketoitu yksikkö jossa voidaan pyörittää virtuaalisesti lähes mitä tahansa sovellusta omassa eristetyssä ympäristössä. Kontti on huomattavasti kevyempi kuin kokonainen virtuaalikone. Yhdellä virtuaalikoneella voidaan ajaa useita eri kontteja, jotka voivat kaikki pohjautua eri pohjakuviin (base image). Yleensä kannattaa valita mahdollisimman kevyt ja pieni pohjaimage jonka päälle alkaa rakentamaan omaa konttia. Yksi suosittu image on Alpine Linux jonka koko voi olla vain muutamia megatavuja.
Docker on kaikista suosituin konttien pyörittämiseen tarkoitettu sovellusalusta, lähes jopa siinä määrin että Docker == container. Dockerista löytyy kaksi eri versiota josta toinen on ilmainen (CE) ja toinen maksullinen (EE). Dockerista on myös desktop-versiot niin Macille kuin Windowsille joiden mukana tulee myös nykyään Kubernetes.
Docker Hub on Docker-imagejen säilömiseen tarkoitettu säilytyspaikka (repository) johon kuka tahansa voi tehdä tilin ja alkaa säilömään sinne omia kontti-imageja. Säilötty image voi olla joko julkinen tai yksityinen. Monet suuret sovellusvalmistajat tarjoavat omia virallisia ja julkisia imageja täältä. Container repositoryja voi olla myös pilvipalveluissa kuten GCP (Googlen pilvi), Azure, AWS, jne.
Docker Compose on useista konteista koostuvien sovellusten hallinta-, määritys- ja ajoalusta ja työkalu.
Kubernetes on konttien ajoon tarkoitettu orkestrointialusta. Monet pilvipalvelut kuten Google (GKE) tarjoavat oman hallinnoidun Kubernetes-palvelun (managed Kubernetes engine). Omaa Kubernetes-ympäristöä/klusteria voi pyörittää myös omalla koneella joko minikubella tai Docker desktopilla jonka mukana tulee myös Kubernetes.
Docker Swarm on myös konttien orkestrointialusta kuten Kubernetes.
Helm on Kubernetekselle tarkoitettu pakettihallintajärjestelmä jolla voidaan hallita monimutkaisia mikropalvelusovelluksia jotka perustuvat Kubernetekseen.
Tuli mieleen, että jos haluaa tosiaan jonkun vaikka LAMP-alustan, niin pistääkö Dockeriin jonkun ubuntun johon asentaa kaikki, vai pistääkö vaikka tietokannat eri dockeriin - jos haluaa käyttää/testailla vaikka MariaDb ja Mongoa ja serverit eri dockeriin vai vai kaikki erit erikseen esim apache ja Nfginx ja sitten yhdistelee jollain tiedonkulun?
Tuli mieleen, että jos haluaa tosiaan jonkun vaikka LAMP-alustan, niin pistääkö Dockeriin jonkun ubuntun johon asentaa kaikki, vai pistääkö vaikka tietokannat eri dockeriin - jos haluaa käyttää/testailla vaikka MariaDb ja Mongoa ja serverit eri dockeriin vai vai kaikki erit erikseen esim apache ja Nfginx ja sitten yhdistelee jollain tiedonkulun?
Yrityksessä ainakin loppupeleissä päädytään siihen, että pistetään kaikki erikseen. Ja kannatkin kannattaa suunnitella siten, että tuore tieto on jossakin nopeammin saavutettavissa ja historian penkojat sitten joutuvat odottelemaan kun kelanauhuri rupeaa kaivamaan dataa.
Mutta tietysti opettelu mielessä ehkä voi myös pistää kaikki samaan, niin osaa tehdä myös tuollaisen konffin tai huomaa mitä ongelmia siinä tulee vastaan. Näissä aina törmää ihmeellisyyksiin, jolloin tilanne muuttuu tapauskohtaiseksi.
Omiin kontteihin vaan, sehän tässä koko hommassa on jujuna.
Teet ensiksi oman verkon komennolla:
Koodi:
docker network create --driver bridge nimi
ja sitten vaan --network nimi vivulla kontit pystyyn:
Koodi:
docker run --name apache --network nimi -p 80:80 -d httpd
docker run --name mysql --network nimi -e MYSQL_ROOT_PASSWORD=my-secret-pw -d mysql
Kun kontit ovat kaikki samassa verkossa niin pingi (mikäli ping on asennettu) kulkee ihan kontin nimellä perille: ping apache
Tässä heti tosiaan kannattaa alkaa käyttämään docker composea kun on useista komponenteista kyse.
Miten näiden julkisten docker imagien kanssa on luottaminen, ettei niihin ole lisätty mitään haitallista? Julkaistaanko yleensä skripti tai dokumentaatio miten image luotiin, että sen voi itse koota samalla tavalla ja verrata, että itse tehty on bitilleen sama mitä julkinen versio, tavallaan sama siis kuin esim. Debianin reproducible builds?
Dockerin kanssa tulee leikittyä käytännössä iso osa työajasta (ylläpidän/kehitän kontitettua CI/CD-järjestelmää). Lähinnä Swarm on se minkä kanssa touhunnut pari vuotta. Kubernetesta pelkästään perusteiden verran, tarkoitus olisi ottaa sekin haltuun tässä kunhan löytyy aikaa. Swarm on edelleen melko buginen ja alkaa olemaan vähän alakynnessä kun kaikki tekee nykyään Kuberneteksella. Windowsin kanssa Docker edelleen melko "beta", toki tilanne parantunut huomattavasti viimeisen n. vuoden aikana mutta edelleen melkoista säätämistä välillä. Eteenkin jos Swarmissa on sekä Linux että Windows nodeja niin tilanne on välillä mennyt mielenkiitoiseksi. Nykyään Kuberneteskin tuetaan Wintoosassa natiivina (tai Hyper-V jos Windows konttien kanssa leikitään).
Miten näiden julkisten docker imagien kanssa on luottaminen, ettei niihin ole lisätty mitään haitallista? Julkaistaanko yleensä skripti tai dokumentaatio miten image luotiin, että sen voi itse koota samalla tavalla ja verrata, että itse tehty on bitilleen sama mitä julkinen versio, tavallaan sama siis kuin esim. Debianin reproducible builds?
Jokaisesta imagesta saa ulos kyllä jokaisen layerin mitä siihen on asetettu. Kun tekee omia imageja niin kannattaa olla tarkkana ettei sinne laita esim. salasanoja plainina, koska ne näkyvät suoraan imagen layereissa.
Mites tuolla Traefikilla tarjotaan staattista sisältöä kuten html ja js jos ei halua bäkkärillä noita renderöidä ja tarjoilla? Pitää varmaan pyörittää esim. 80 portissa omaa nginx containeria joka tarjoaa filut ja sitten jossain toisessa portissa oma container jossa api/web app? Traefik sitten tarjoaa noita molempia (web app ja nginx) containereita?
Vastaan nyt tähän lankaan koska sopii tänne paremmin!
En oo ihan varma nyt mitä usecase haet mutta yritän parhaani.
Eli siis traefikin kanssa voit juurikin esim. luoda bäkkäri kontin ja sille kaveriksi erillisen fronttikontin, joka hostaa staattisen osuuden (tällekin tulee oma bäkkäri ja se kulkee traefikin luoman "frontin" läpi julkiseksi) ja apin julkaiset traefikin kautta julkiseksi.
Parhaan ymmärrykseni mukaan traefik on vai helvetin helppo työkalu pystyttää kontti orkesteri. Mitää taikoja se ei siis tee!
Ihan omaksi huvikseni opettelen Dockeria ja sen käyttöä koodiprojektini automaattisessa testailussa. Asensin Docker-composen ja melkein saanutkin jo kaiken rullaamaan. Ongelmaksi tuli kuitenkin /var/lib/docker/-kansion täyttyminen. Ilmeisesti jokaisella docker-compose build -käskyllä se varaa satoja megatavuja lisää käyttöönsä.
Docker system prune oli ainut ohje, minkä tähän löysin, mutta se jyrääkin sitten aivan kaiken pois.
Teenkö jotain väärin, kun tuota buildia ajan toistuvasti? Ympäristö toki luodaan sen avulla, mutta miten ihan muutokset koodissa olisi tarkoitus testata containerissa?
Ihan omaksi huvikseni opettelen Dockeria ja sen käyttöä koodiprojektini automaattisessa testailussa. Asensin Docker-composen ja melkein saanutkin jo kaiken rullaamaan. Ongelmaksi tuli kuitenkin /var/lib/docker/-kansion täyttyminen. Ilmeisesti jokaisella docker-compose build -käskyllä se varaa satoja megatavuja lisää käyttöönsä.
Docker system prune oli ainut ohje, minkä tähän löysin, mutta se jyrääkin sitten aivan kaiken pois.
Teenkö jotain väärin, kun tuota buildia ajan toistuvasti? Ympäristö toki luodaan sen avulla, mutta miten ihan muutokset koodissa olisi tarkoitus testata containerissa?
Docker compose yaml filessä määrittelet volume mountin jossa mounttaat sen sun lokaalin sovelluksen sinne kontaineriin niin voit livenä tehdä muutoksia sinne konttiin. Tässä hyvä artikkeli: "Docker-composing" a Python 3 Flask App Line-by-Line
vs code myös nykyään tukee remote yhteyttä suoraan konttiin.
Ihan omaksi huvikseni opettelen Dockeria ja sen käyttöä koodiprojektini automaattisessa testailussa. Asensin Docker-composen ja melkein saanutkin jo kaiken rullaamaan. Ongelmaksi tuli kuitenkin /var/lib/docker/-kansion täyttyminen. Ilmeisesti jokaisella docker-compose build -käskyllä se varaa satoja megatavuja lisää käyttöönsä.
Docker system prune oli ainut ohje, minkä tähän löysin, mutta se jyrääkin sitten aivan kaiken pois.
Teenkö jotain väärin, kun tuota buildia ajan toistuvasti? Ympäristö toki luodaan sen avulla, mutta miten ihan muutokset koodissa olisi tarkoitus testata containerissa?
Docker tekee joka kerta uuden imagen ja layerit kun ajat buildia. Kannattaa tehdä jonkilainen image-cleaneri joka ajaa automaattisesti tietyin väliajoin jos tuntuu että kiintolevy ei riitä. Oletko laittanut tagia imagellesi compose filessä?
Ihan omaksi huvikseni opettelen Dockeria ja sen käyttöä koodiprojektini automaattisessa testailussa. Asensin Docker-composen ja melkein saanutkin jo kaiken rullaamaan. Ongelmaksi tuli kuitenkin /var/lib/docker/-kansion täyttyminen. Ilmeisesti jokaisella docker-compose build -käskyllä se varaa satoja megatavuja lisää käyttöönsä.
Docker system prune oli ainut ohje, minkä tähän löysin, mutta se jyrääkin sitten aivan kaiken pois.
Teenkö jotain väärin, kun tuota buildia ajan toistuvasti? Ympäristö toki luodaan sen avulla, mutta miten ihan muutokset koodissa olisi tarkoitus testata containerissa?
It is very important to not run these commands when your containers are deleted. Running docker-compose down - for example - will delete your containers. Your volumes are now in a dangling state! Running the commands shown below, will remove your volumes and therefore your data.
Jos kontteihin ei tallenneta mitään kriittistä dataa, sehän ei haittaa vaikka koko systeemin vetää tyhjäksi. Sehän on koko kontituksen idea, tehdä toistettavia, kevyitä ympäristöjä jotka voi luoda milloin vain, mihin vain joka kerta toistettavasti. Jos käytät säilytettävää dataa niin silloin siitä kannattaa tehdä mountti esimerkiksi verkkolevylle tai minne tahansa missä haluat datasi säilyvän. Tällöinkään kaiken docker datan häviäminen ei ole katastrofi sillä tallenetut tiedot ovat mountissa turvassa.
Alkuperäiseen kysymykseen: "Ympäristö toki luodaan sen avulla, mutta miten ihan muutokset koodissa olisi tarkoitus testata containerissa?"
Itse lähtisin tekemällä Jenkins slaven konttina johon on asennettu kaikki mitä koodisi kääntäminen/ajaminen vaatii. Konttiin haetaan aina uusin koodisi joka ajossa ja ajetaan esim. unittestit sille.
Softa tarvitsee lähdemateriaalia, minkä mounttaan sille docker-compse.yamlissa. Muuten kontin vetäminen sileäksi ei haittaa. Mietin vain onko siihen jotain automaattista tapaa esim. "jyrää kaikki vanha samanniminen"-vipua. Prune käy kyllä sinänsä muuten niin kauan kuin en dockerilla muuta tee.
Jenkinsiäkin katsoin ja mulla se olikin yhdessä kontissa olemassa (jonka sitten tuolla prunella vahingossa tuhosin ja siitä tämä mieleen tulikin ). Vaikutti turhan raskaalta tässä alkuvaiheessa, kun automaattisia testejä vasta opettelen. Oppimiskäyrä vaikutti ainakin käyttämäni tutorialin kanssa turhan jyrkältä.
Tämänhetkiset ongelmani saisin toki ratkaistua sillä, että laitan aina kaiken gittiin ja ne haetaan sieltä konttiin. Vähän turhan raskas prosessi vain pikkumuutoksille, kun monta minuuttia kestää kontin luomiset, enkä gittiinkään tykkäisi laittaa kuin toimivaa koodia, mutta mistäs sen tiedän ilman testejä.
Ohjelmasta olisi tarkoitus tulla sellainen, minkä voi pip install tai python setup.py install asentaa mihin Linuxiin tahansa. Itse ohjelma ei kuitenkaan ole riippuvainen tuosta kyseisestä kirjastoversiosta vaan sille kelpaavat muutkin. Tapauksessani riippuvuus tulee jotenkin siitä, että samassa kansiossa olen ajanut setupin hostilla ja containerissa ja siksi container haluaa tuota samaa versiota kuin hostilla on. En usko, että tämä liittyy niinkään dockeriin ja containeriin kuin setuputilsin käännösjätteisiin, joita en osaa kunnolla putsata. Siksi kysyinkin tuolla Python ketjussa.
Sinänsä imagen vaihto voisi olla hyvä idea. Ubuntua valtaosa taitaa kuitenkin ajella työpöydälläänkin. Ja vscodella koodaan muutenkin, niin tuohon linkkiin pitääkin tutustua.
Softa tarvitsee lähdemateriaalia, minkä mounttaan sille docker-compse.yamlissa. Muuten kontin vetäminen sileäksi ei haittaa. Mietin vain onko siihen jotain automaattista tapaa esim. "jyrää kaikki vanha samanniminen"-vipua. Prune käy kyllä sinänsä muuten niin kauan kuin en dockerilla muuta tee.
docker prunelle voi laittaa esimerkiksi filterinä ajan, esimerkiksi että kaikki yli 24h vanhat tavarat tuhotaan. TJEU: docker system prune
Jenkinsiäkin katsoin ja mulla se olikin yhdessä kontissa olemassa (jonka sitten tuolla prunella vahingossa tuhosin ja siitä tämä mieleen tulikin ). Vaikutti turhan raskaalta tässä alkuvaiheessa, kun automaattisia testejä vasta opettelen. Oppimiskäyrä vaikutti ainakin käyttämäni tutorialin kanssa turhan jyrkältä.
Suosittelen kuitenkin Jenkinsiin tutustumista, mahdolliset tulevat työnantajaehdokkaasi varmasti arvostavat jos omaat jotakin kokemusta siitä. Voit tehdä Jenkins masterille oman kontin ja Slavelle(se kontti joka buildaa kamasi) oman kontin.
Tämänhetkiset ongelmani saisin toki ratkaistua sillä, että laitan aina kaiken gittiin ja ne haetaan sieltä konttiin. Vähän turhan raskas prosessi vain pikkumuutoksille, kun monta minuuttia kestää kontin luomiset, enkä gittiinkään tykkäisi laittaa kuin toimivaa koodia, mutta mistäs sen tiedän ilman testejä.
Muutokset kannattaa tehdä omissa brancheissa. Jenkinssissä voit sitten konffata jobit käyttämään feature brancheja. Teet kaksi jobia, toisen testaamaan jokaisen commitin feature branchissa ja toisen verifioimaan master branchia, jossa siis tulisi olla aina toimiva kama.
Kokeilin ja tämähän tuntuu olevan juuri sitä, mitä haluankin. Enää ongelmana saada yksi kansio mountattua konttiin. Jostain syystä ei toimi tuolla neuvottu docker-composen käyttö lisäämällä devcontainer.jsoniin dockerComposeFile. Mitä kontin luomisen outputtia katsoin, niin sitä ei taideta lukea ollenkaan. Jotain mulla vielä konffeissa pielessä.
Täältäkin ääni Jenkinsiin tutustumiselle. Varsinkin pipelinet on hyviä tuntea. Lisäksi jahka konttien kanssa enemmän touhuaa voi olla hyödyllistä tutustua välineisiin kuten Okd (ex openshift origin) ja s2i kontteihin. Noita s2i pohjaimageja on useammalle yleiselle kielelle olemassakin, kuitenkin hyvä on tuntea perusteet ja osata myös tehdä custom image mikäli ei ole olemassa. Orkestrointivälineet kuten okd vähentävät tarvetta noille manuaalisille ylläpitotoimille, mutta toki vaativat oman opettelunsa. Kuitenkin kohtalaisen pienellä työllä saa tehtyä ympäristön jossa konstissa (tai k8s termein podissa) pyörii versionhallinta (voi toki käyttää vaikka githubia jos oman palvelimen saa ulkomaailmaan näkösälle) ja okd buildaa s2i:n avulla suoraan pushista uuden version ja tekee rolling updaten jonka jälkeen uusi versio softasta on saatavilla.
Onko Docker Raspberryllä hidas/liian raskas? Mietin kun tuo Rpi 4 tuli, josko vaihtaisi siihen ja kun Busterin myötä kaiken joutunee asentamaan alusta, niin myös siirtyisi kontitettuihin sovelluksiin (HA, Zigbee2MQTT, Mosquitto, Nginx, Unifi Controller). Aikaisempaa Docker kokemusta ei ole, joten ihan harjoittelu mielessäkin kiinnostaisi, mutta onko millainen suorituskyky vaikutus.
Onko Docker Raspberryllä hidas/liian raskas? Mietin kun tuo Rpi 4 tuli, josko vaihtaisi siihen ja kun Busterin myötä kaiken joutunee asentamaan alusta, niin myös siirtyisi kontitettuihin sovelluksiin (HA, Zigbee2MQTT, Mosquitto, Nginx, Unifi Controller). Aikaisempaa Docker kokemusta ei ole, joten ihan harjoittelu mielessäkin kiinnostaisi, mutta onko millainen suorituskyky vaikutus.
Mistäs kannattaa alkaa katsomaan jotain itseopiskelu materiaalia kube klusterin askarteluun? olis kiinnostusta värkä/treenata joku mikropalvelu härpäke ja sille apigetaway/reverse proxy (traefik). devaus ympäristö ja pipelinet olis kiinnostavaa myös käydä läpi.
Pilvialusta suosituksia azure aws goole ja mitä näitä nyt on ?
Mistäs kannattaa alkaa katsomaan jotain itseopiskelu materiaalia kube klusterin askarteluun? olis kiinnostusta värkä/treenata joku mikropalvelu härpäke ja sille apigetaway/reverse proxy (traefik). devaus ympäristö ja pipelinet olis kiinnostavaa myös käydä läpi.
Pilvialusta suosituksia azure aws goole ja mitä näitä nyt on ?
Docker desktopissa on Kubernetes nykyään, sillä varmaan alkuun tai sitten minikube omalle työasemalle. GCP:ssä saa ajettua myös kubeklusteria preemptible VM:llä jolloin hinta on murto-osa.
Jos haluaa vaan keskittyä mikropalveluiden pyörittämiseen niin GCP:n cloud run on hyvä vaihtoehto: Cloud Run | Google Cloud
Dockerissa ajetaan spark- ajo joka lukee csv- tiedoston, tekee muutaman yksinkertaisen datamuunnoksen ja kirjoittaa ulos parquetin.
Sama ajo host- koneessa kestää kirjoituksen osalta ~10sek ja dockerissa ~80sek.
Dockerissa käytetyt datahakemistot ja kaikki tempit on mäpätty hostiin eli ei pitäisi juurikaan kirjoittaa kontin levylle.
Muistaakseni docker perustuu python-3.6 päälle, debian 10.
Host aws ec2 8vcpu, 16G ram ja riittävästi ebs gp2 ssd levyä, centos en muista versiota.
Molemmissa sparkeissa on samat asetukset, samat lisäkirjastot jne.
Muut ajot toimivat mielestäni nopeasti ja vain sparkin kirjoitus hidastelee.
Jos on tarvetta lisätiedoille niin pitää kaivella.
Dockerissa ajetaan spark- ajo joka lukee csv- tiedoston, tekee muutaman yksinkertaisen datamuunnoksen ja kirjoittaa ulos parquetin.
Sama ajo host- koneessa kestää kirjoituksen osalta ~10sek ja dockerissa ~80sek.
Dockerissa käytetyt datahakemistot ja kaikki tempit on mäpätty hostiin eli ei pitäisi juurikaan kirjoittaa kontin levylle.
Muistaakseni docker perustuu python-3.6 päälle, debian 10.
Host aws ec2 8vcpu, 16G ram ja riittävästi ebs gp2 ssd levyä, centos en muista versiota.
Molemmissa sparkeissa on samat asetukset, samat lisäkirjastot jne.
Muut ajot toimivat mielestäni nopeasti ja vain sparkin kirjoitus hidastelee.
Jos on tarvetta lisätiedoille niin pitää kaivella.
Ootko varmistanut että molemmissa tapauksissa sulla on siellä oikeasti käynnissä sama määrä Sparkin executoreita ja että kaikki oikeasti saa taskeja suoritetuksi?
Itse olen lähinnä Docker käyttäjä, viime aikoina antanut muiden hoitaa isommat konffailut. Kommentoidaan kuitenkin
Näin spesifinen kysymys saanee parhaan vastauksen Stackoverflow:lla. Mutta
- oletko tuon host-kirjoitusnopeudet kokeillut juuri tuolla samalla hostilla ?
- kokeillut että tästä dockerista kirjoittaminen tuonne hostile on muuten nopeaa, mutta hidasta vain sparkille?
- kokeillut erilaista hostia, centos kuulostaa vähän tuskaiselta
1. hostin itsensä kirjoitusnopeudet on ok esim tiedostokopiona/jdbc->csv yms.
2. kaikki ajot ajetaan samassa dockerissa, vain sparkin kirjoitus hidastelee
3. sama ilmiö toistuu esim kehityskoneena käytettävässä virtuaalikoneessa (debian 9), vmware hostina w10.
Ootko varmistanut että molemmissa tapauksissa sulla on siellä oikeasti käynnissä sama määrä Sparkin executoreita ja että kaikki oikeasti saa taskeja suoritetuksi?
Molemmissa tapauksissa lähteenä oli sama data, jakauma näytti mielestäni samalta.
Molemmissa sparkeissa on samat asetukset ja kirjastot, testien aikana tuetysti vain toinen käynnissä.
Molemmissa tapauksissa lähteenä oli sama data, jakauma näytti mielestäni samalta.
Molemmissa sparkeissa on samat asetukset ja kirjastot, testien aikana tuetysti vain toinen käynnissä.
Sparkin asetukset voi olla täsmälleen samat, mutta se ei takaa sitä että siellä oikeasti pääsee käynnistymään sama määrä executoreita, jos kontin sisällä muisti tai coret rajoittaa sitä.
Sparkin asetukset voi olla täsmälleen samat, mutta se ei takaa sitä että siellä oikeasti pääsee käynnistymään sama määrä executoreita, jos kontin sisällä muisti tai coret rajoittaa sitä.
Tietysti pitää tarkastaa, tästä jatkuu huomenna kun on taas koneen ääressä...
Aika mitataan softassa dataframen write ennen ja jälkeen ajoista. Helppo muttei ehkä ihan optimi...
Tietysti pitää tarkastaa, tästä jatkuu huomenna kun on taas koneen ääressä...
Aika mitataan softassa dataframen write ennen ja jälkeen ajoista. Helppo muttei ehkä ihan optimi...
Ja varmistetaan vielä, eli molemmissa täsmälleen sama koodi, ja ajetaan puhtaasta juuri pystytetystä SparkSessionista? Eli ei esimerkiksi mitään ylimääräistä .show():ta tai mitään muutakaan mikä voisi aiheuttaa sen että kirjoitettavat tavarat löytyisikin cachesta jolloin niiden kirjoittaminen on luonnollisesti aika paljon nopeampaa?
Kannattaa myös verrata sieltä SparkUI:sta sitä kirjoitus-stagen ilmoittamaa aikaa siihen mitä oot mitannut "ulkopuolelta". Jos se stageen kuluva aika on kovin lyhyt verrattuna siihen toiseen, niin silloin lähtisin epäilemään jotain io-pullonkaulaa.
Ja varmistetaan vielä, eli molemmissa täsmälleen sama koodi, ja ajetaan puhtaasta juuri pystytetystä SparkSessionista? Eli ei esimerkiksi mitään ylimääräistä .show():ta tai mitään muutakaan mikä voisi aiheuttaa sen että kirjoitettavat tavarat löytyisikin cachesta jolloin niiden kirjoittaminen on luonnollisesti aika paljon nopeampaa?
Kannattaa myös verrata sieltä SparkUI:sta sitä kirjoitus-stagen ilmoittamaa aikaa siihen mitä oot mitannut "ulkopuolelta". Jos se stageen kuluva aika on kovin lyhyt verrattuna siihen toiseen, niin silloin lähtisin epäilemään jotain io-pullonkaulaa.
Juu, en ole testaamassa ihan ensimmäistä kertaa.
Sama koodi (= sama jar), sama data, sama käynnistysskripti, sama jdk molemmissa.
Tuota on ajettu useampaan kertaa molemmilla ja aina host on ollut nopeampi. Lähdetiedosto aina samassa paikassa ja kohteen poisto käsin ennen ajoja.
Onhan se mahdollista että jotain on jäänyt näkemättä, sekään ei olisi ensimmäinen kerta. Tämä on nyt vähän kuin pelissä kun kilauta kaverille on käytetty niin kysytään yleisöltä...
docker diff komennolla voisi tarkastaa, ettei osa kirjoituksista mene johonkin muualle COW imagessa, esimerkisi sparkin logit tai temp-tiedostot. Tai testata tempfs volumella kirjoitusnopeutta suoraan muistiin.
Onko merkitystä ajetaanko dockereita host vai bridged verkolla? Vissiin tuo bridge eristää paremmin, mut onko muuten merkitystä jos pitää huolen, että portit eivät mene päällekäin?
Onko merkitystä ajetaanko dockereita host vai bridged verkolla? Vissiin tuo bridge eristää paremmin, mut onko muuten merkitystä jos pitää huolen, että portit eivät mene päällekäin?
Eristys kai tuossa se pointti. Jos niitä portteja tarvitaan paljon, niin bridged taisi vähän jäätyä, jos muistan oikein, ja host ainoa käytännön mahdollisuus(?)
Docker aloittelija kyselee taas mahdollisesti hieman tyhmiä. Olen siis rpi3:ssa onnistuneesti saanut käyntiin docker run komennolla esim piholen. Nyt kun yritän samaa docker-compose.yml tiedostolla, niin saan virheilmoituksen
Koodi:
standard_init_linux.go:211: exec user process caused "exec format error"
Kovan googlailun tuloksena, ymmärsin, että kyseinen virhe johtuu mahdollisesti ns. väärästä arkitehduurista. Eli docker-compose yrittäisi ehkä käyttää x86 imagea arm alustalla. Mutta osaisko joku nyt auttaa hieman eteenpäin tässä asiassa?
Koodi:
version: "3"
services:
pihole:
container_name: pihole
image: pihole/pihole:latest
hostname: Pihole2
ports:
- "53:53/tcp"
- "53:53/udp"
# - "67:67/udp"
- "80:80/tcp"
- "443:443/tcp"
environment:
TZ: "Europe/Helsinki"
DNS1: "9.9.9.9"
DNS2: "149.112.112.112"
# WEBPASSWORD: 'set a secure password here or it will be random'
# Volumes store your data between container upgrades
volumes:
- /home/pi/docker/pihole/pihole:/etc/pihole/
- /home/pi/docker/pihole/dnsmasq.d:/etc/dnsmasq.d/
# Recommended but not required (DHCP needs NET_ADMIN)
# https://github.com/pi-hole/docker-pi-hole#note-on-capabilities
#cap_add:
# - NET_ADMIN
restart: unless-stopped
Mainitaan vielä, että docker-compose on asennettu näillä ohjeilla: Install Docker Compose
Kuten paapaa sanoi, sulla on varmaan se image vielä olemassa jolla käynnistit sen kontin alunperin. docker images -a saat kaikki imaget mitä sun hostiin on ladattu.
jokin siis kusi tuossa alternate installissa, missä compose asenetaan containerina. Asensin normaalisti pythonin palikat ja pip3 installilla docker-composen ja kaikki toimii oikein.
Reilun vuoden pyörittänyt kotiympäristössä docker kontteja/palveluja docker-composella.
Kiinnostusta on ollut kubernetekseen. Testailin aikaa sitten k3s:ää, mutta rpi3 tukehtui yhtään vaativamman sovelluksen kanssa, joten homma jäi lähinnä "hello world" tasolle. Toki Kubernetes on overkill koti virityksiin.
Tänään löysin podmanin, jota aikomus kokeilla. Onko tästä kokemuksia? Onko tämä next gen steppi docker-composesta vai kannattaisiko kenties kokeilla jotain muuta?
Reilun vuoden pyörittänyt kotiympäristössä docker kontteja/palveluja docker-composella.
Kiinnostusta on ollut kubernetekseen. Testailin aikaa sitten k3s:ää, mutta rpi3 tukehtui yhtään vaativamman sovelluksen kanssa, joten homma jäi lähinnä "hello world" tasolle. Toki Kubernetes on overkill koti virityksiin.
Tänään löysin podmanin, jota aikomus kokeilla. Onko tästä kokemuksia? Onko tämä next gen steppi docker-composesta vai kannattaisiko kenties kokeilla jotain muuta?
Docker Swarmia kannattaa kans testata jos clusterointi on tavoitteena. Helpompi käyttää ja ottaa käyttöön kun K8s. Ei kai clusteroinnin pitäis vaikuttaa suorituskykyyn juurikaan, vaan siihen vaikuttaa tietysti instanssi jossa ne kontit pyörivät. Kannattaa myös tsekata AWS:n Kubernetes palvelut ja konttipalvelut. Free tierilläkin päässee (en ole ihan varma) alkuun.
). Vaikutti turhan raskaalta tässä alkuvaiheessa, kun automaattisia testejä vasta opettelen. Oppimiskäyrä vaikutti ainakin käyttämäni tutorialin kanssa turhan jyrkältä.
