Docker, Container & Kubernetes

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.
AWS tarjoaa myös ECS (Elastic Container Service), joka on yksinkertaisempi käyttää kuin AWS:n EKS (Elastic Kubernetes Service). ECS:n kanssa on myös mahdollista käyttää Fargate-palvelua, jossa kontti ajetaan täysin serverless-ympäristössä. Tämä sopii erityisesti tehtäville, joita suoritetaan vain rajatun ajan, ja laskutus tapahtuu suoritusajan mukaan.

(Ainoa?) huono puoli ECS+Fargate combossa on harrasteprojektille, että nuo ovat varsin AWS-keskeisiä työkaluja, eikä siirry sellaisenaan esim. Googlen palvelimille.
 
AWS tarjoaa myös ECS (Elastic Container Service), joka on yksinkertaisempi käyttää kuin AWS:n EKS (Elastic Kubernetes Service). ECS:n kanssa on myös mahdollista käyttää Fargate-palvelua, jossa kontti ajetaan täysin serverless-ympäristössä. Tämä sopii erityisesti tehtäville, joita suoritetaan vain rajatun ajan, ja laskutus tapahtuu suoritusajan mukaan.

(Ainoa?) huono puoli ECS+Fargate combossa on harrasteprojektille, että nuo ovat varsin AWS-keskeisiä työkaluja, eikä siirry sellaisenaan esim. Googlen palvelimille.
AWS ECS Fargate on jokseenkin tuttu. Tein sinne aiemmin harraste mielessä pari Flask microserviceä.
Nykyisin näyttää olevan myös EKS Fargate tarjolla, mutta se nyt ei ainakaan homelab rakenteluun kiinnosta clusterin kuukausimaksun vuoksi.

Podman suurempi tutustuminen jäi sitten omalta kohdalta väliin ja sen sijaan pystytin vmware Debianiin yhden noden kubeadm k8s clusterin. Toistaiseksi olen saanut sinne Prometheuksen pod:n keräämään clusterin metriikat ja RPi docker-compose ympäristössä vielä pyörivästä gitlab ce:stä integraation ja runner podin. Seuraavina suunnitelmina grafana pod ja kokeeksi appi siirtoja docker-composesta. Ehkä tämä setup toimisi raspberryssäkin, mutta luultavasti siirrän tämän virtuaaliympäristön jossain vaiheessa johonkin parempaan rautaan (nyt työsasemassa/pelikoneessa). Raspberryjä voisi varmaan hyödyntää worker nodeina. Tämän nyt pitäisi olla sellainen setup, jonka voisi myös siirtää EKS tai GKE kohtuullisella vaivalla.
 
Viimeksi muokattu:
Hei, simppeli kysymys: Jos kotilinuxilla saan pystyyn halutun docker kontin/kontit, onko se helppo siirtää vaikka omalle serverille avaraan weppiin avautuvaksi?
Huono kysymys.
 
Viimeksi muokattu:
Seuraavanlainen probleema. Mulla on nyt serverillä paljaaltaan mysql serveri eli ei dockeroituna. Haluaisin kuitenkin dockeroida phpmyadminin että sen voisi aina sammuttaa kun ei käytä yms. ei php:t sotke serveriä. Koitin nyt pöytälinuxilla yhdistää docerissa olevan phpmyadminin erilliseen ei-cdocker mysql:iin (mariadb), mutta en runsaasta goolailusta huolimatta ole löytänyt oikeita komentoija. Mites tätä lähestyttäis? Tuntuis melkein jo helpommalta että kaikki olisi dokkeroituna niin kuin oikeasti pitäisi, mutta en halua lähteä veivaamaan nyt tätä toimivaa comboa. Myöhemmin sitten jatkan docereilla.

Eli : miiten yhdistää dockeroitu phpmyadmin ei-dockeroituun mysql-serveriin.
 
Seuraavanlainen probleema. Mulla on nyt serverillä paljaaltaan mysql serveri eli ei dockeroituna. Haluaisin kuitenkin dockeroida phpmyadminin että sen voisi aina sammuttaa kun ei käytä yms. ei php:t sotke serveriä. Koitin nyt pöytälinuxilla yhdistää docerissa olevan phpmyadminin erilliseen ei-cdocker mysql:iin (mariadb), mutta en runsaasta goolailusta huolimatta ole löytänyt oikeita komentoija. Mites tätä lähestyttäis? Tuntuis melkein jo helpommalta että kaikki olisi dokkeroituna niin kuin oikeasti pitäisi, mutta en halua lähteä veivaamaan nyt tätä toimivaa comboa. Myöhemmin sitten jatkan docereilla.

Eli : miiten yhdistää dockeroitu phpmyadmin ei-dockeroituun mysql-serveriin.

Minkä virheen sait?
Tuossa tapauksessa mysqln mielestä phpmyadmin pyörii eri koneella eli ainakin pitää phpmyadminin puolella kertoa oikea mysql host ja mysqln puolella sallia kirjautuminen & käyttö docker- "koneesta".

Oletettavasti törmäät samaan jos mysql ja admin pyörivät eri konteissa.
 
No siihen löysin jo ohjeet miten eri konttien väliin tehdään networkki. Mutta siis virhe oli oletettu eli: mysqli::real_connect(): php_network_getaddresses: getaddrinfo failed: Name or service not known

Eli pistetäänkö hostiksi localhostia ja porttia 3306 jne käynnistysrimpsuun vai mitä? ja mikä on arbitary connct, tarviinko sitä.
 
Aukase portit mysql serveriltä niin pitäis kontin ja serverin väliset yhteydet onnistua. Jos haluat sofistukoitunempaa nettikonfiguraatiota konttien ja hostien välillä niin tutustu Traefikiin.
 
No, eipä eilen onnistunut. Laitoin mariadb:ssä bindauksen 0.0.0.0 (vai laitoinko sen kokonaan pois). Pitäisikö mun käyttää dockerin sisäistä ip:tä jotenkin? Ai kun olisi joku komentorivi esimerkki jolla ton pitäisi toimia.
 
Itsekin olen toisinaan jotain tällaisia kuvioita pyöritellyt jossa mariadb pyörii lokaalisti ja sitä käyttäviä sovelluksia toisaalta konteissa - minusta helpoin on vaan katsoa ifconfigista host-koneelle myönnetyt ip-osoitteet ja pingailla niitä läpi (tai tarkastaa nc:lla portin aukiolo) sieltä kontin sisältä kunnes löytyy se joka vastaa. Tuo toimiva on sitten myös se sama host josta sen sun tietokannan pitäisi vastata.
 
Okei. Siis docker0 käyttää 172.17.0.1 ja vastaa pingiin. Mihin tuon laitan?
 
ootko koittanut tehdä uuden docker networkin ja laittamaan kontin käyttämään sitä?
 
Koodi:
version: '3'

services:
  db:
    image: mysql:5.7
    container_name: db
    environment:
      MYSQL_ROOT_PASSWORD: my_secret_password
      MYSQL_DATABASE: app_db
      MYSQL_USER: db_user
      MYSQL_PASSWORD: db_user_pass
    ports:
      - "6033:3306"
    volumes:
      - dbdata:/var/lib/mysql
  phpmyadmin:
    image: phpmyadmin/phpmyadmin
    container_name: pma
    links:
      - db
    environment:
      PMA_HOST: db
      PMA_PORT: 3306
      PMA_ARBITRARY: 1
    restart: always
    ports:
      - 8081:80
volumes:
  dbdata:

No, tällä sain että asentui mysql ja phpmyadmin. En saanut siis ilman. Puuttuu jotain pieniä, mutta oleellisia paloja tietämyksestä niin ei ole helppoa. Ehkä tätä tutkimalla valkenee. Tietenkin mielenkiintoista vielä, miten yhdistän nyt siihen ulkopuoliseen mariadb:hen.
 
Koodi:
version: '3'

services:
  db:
    image: mysql:5.7
    container_name: db
    environment:
      MYSQL_ROOT_PASSWORD: my_secret_password
      MYSQL_DATABASE: app_db
      MYSQL_USER: db_user
      MYSQL_PASSWORD: db_user_pass
    ports:
      - "6033:3306"
    volumes:
      - dbdata:/var/lib/mysql
  phpmyadmin:
    image: phpmyadmin/phpmyadmin
    container_name: pma
    links:
      - db
    environment:
      PMA_HOST: db
      PMA_PORT: 3306
      PMA_ARBITRARY: 1
    restart: always
    ports:
      - 8081:80
volumes:
  dbdata:

No, tällä sain että asentui mysql ja phpmyadmin. En saanut siis ilman. Puuttuu jotain pieniä, mutta oleellisia paloja tietämyksestä niin ei ole helppoa. Ehkä tätä tutkimalla valkenee. Tietenkin mielenkiintoista vielä, miten yhdistän nyt siihen ulkopuoliseen mariadb:hen.

Eikös se tuon perusteella pitäisi onnistua jos laitat vaan konffin osoittamaan siihen omaan koneeseesi jolla se db pyörii, eli jotakuinkin näin:

Koodi:
  phpmyadmin:
    image: phpmyadmin/phpmyadmin
    container_name: pma
    links:
      - db
    environment:
      PMA_HOST: 172.17.0.1
      PMA_PORT: 3306
      PMA_ARBITRARY: 1
    restart: always
    ports:
      - 8081:80
 
No joo ja ei. Täytyy nyt keskittyä miten mariadb:ssä saisi tcp:n päälle. Tuossa kontti+kontti ratkaisussa yhteys meni tcp:n kautta, nyt edelleen ilman konttia pyörivässä unix-sokettien. Niin pal tietoa interneetissä. Tai sitten keskityn vaikka arangodb:hen jossa adminit itsessään.
 
No joo ja ei. Täytyy nyt keskittyä miten mariadb:ssä saisi tcp:n päälle. Tuossa kontti+kontti ratkaisussa yhteys meni tcp:n kautta, nyt edelleen ilman konttia pyörivässä unix-sokettien. Niin pal tietoa interneetissä. Tai sitten keskityn vaikka arangodb:hen jossa adminit itsessään.

Configuring MariaDB for Remote Client Access ?

Missä tahansa valitussa kannassa pitää ensin perehtyä asennukseen, ylläpitoon ja tietoturvaan.
Kaikissa ne on vaan vähän erilaisia löytää/asettaa/jne.

Lyhyesti: Mariadbn konffista skip-networking pois (jos bind-address pois niin kuuntelee kaikkialla) ja tietysti tunnuksille kunnon salasanat ja vain tarvittaville tunnuksille oikeudet kirjautua ulkoa tarvittaviin kantoihin.
 
Koodi:
phpmyadmin:
    image: phpmyadmin/phpmyadmin
    container_name: pma
    environment:
      PMA_ARBITRARY: 1
    restart: always
    ports:
      - 8081:80
No vihdoin. Eli kun tuo arbitary antaa laittaa osoitteen, niin tuolla pullautuksella ja laittamalla siihen 172.17.0.1 niin meni läpi. Eihän siihen mennytkään kuin pari päivää. Mutta kiitoksia johdatuksesta oikeeseen suuntaan. Nuo skipit ja bindit olikin pois. Ja ei-dokkeroidulla phpmyadminilla käyttää socettia.
Edit: Nyt siis toimii myös kun lisää tuon PMA_HOST: 172.17.0.1
Ja toimii myös kun siinä on tuo PORT kuten ehdotettu.

Eli vois olla niin, että tosiaan käyttäjät alkoi olla solmussa ja auttoi kun niitä rukkasin. Nyt siis vähän vielä turvallisempaa käyttäjähallintaa ennen kuin uskaltaa oikealle serverille laittaa.

p.s vscode on aika kätevä näiden dockkereiden ja composerien viilailuun.
 
Viimeksi muokattu:
Yksi dokker-kysymys vielä. Jos tuo dockerin ip oli 172.17.0.1, niin jos laittaa sen userin hostiksi, niin ei pääse sisään, vaan pitää laittaa 172.17.0.2. Olikos jossain, että tuo oli vaihtuva ip? vai mistä tuo johtuukaan.
 
En nyt yhtään muista mihin liittyi mutta täällä piti laittaa /etc/hostsiin Mac OS ympäristössä:

127.0.0.1 kubernetes.docker.internal
 
Täytyisi tehdä pieni tietokannan ja sen dataa visualisoivan PHP-sivun sisältävä kokonaisuus. Se pitäisi myös olla mahdollista helposti myöhemmin siirtää uudelle palvelimelle. Eikö tällainen kontti ole ideaali sen totetukseen?
 
Riippuu vähän mistä roikkuu. Ei välttämättä.

Konteissa on oma hommansa säätää portti ohjaukset ja muu konfiguraatio. Lisäksi yleensä sitä tietokantaa ei kannata sinne konttiin tunkea, tai storagea yleensäkään.

Toki jos palvelimilla on jo kontit muutenkin käytössä, niin sitten. Mutta muutoin veikkaisin että helpoin vain kopsata php softan tiedostot ja kanta dumpilla siirtää kanta.

Jos softien installaatiot ei ole selkärangassa niin suosittelen ottamaan loitsut ylös sitä ensimmäistä serveriasennusta tehdessä.

Ja tehdä jonkinlainen tarkistuslista ettei käy niinkuin Vastaamolla.
 
Tietokanta kannattaa nykypäivänä työntää suoraan AWS:ään tai Azureen. Palvelun voi sitten kontittaa. Tietokanta konttina on suht turha kun se pitää mountata kuitenki persistent storageen ts. jonnekin levylle.
 
Täytyisi tehdä pieni tietokannan ja sen dataa visualisoivan PHP-sivun sisältävä kokonaisuus. Se pitäisi myös olla mahdollista helposti myöhemmin siirtää uudelle palvelimelle. Eikö tällainen kontti ole ideaali sen totetukseen?
Itse taas sitä mieltä, että todellakin kontteihin vaan kaikki. Myös se kanta, jos kerta joku puuhasteluprojekti kyseessä. Paljon helpompi pistää koko pakka pystyyn konteilla ja docker composella. Sen kannan voi sieltä sitten eriyttää jos siltä joskus tuntuu.
 
Itse taas sitä mieltä, että todellakin kontteihin vaan kaikki. Myös se kanta, jos kerta joku puuhasteluprojekti kyseessä. Paljon helpompi pistää koko pakka pystyyn konteilla ja docker composella. Sen kannan voi sieltä sitten eriyttää jos siltä joskus tuntuu.

Tässä on vaan se klassinen virhemahis jos ei tiedä täysin miten kontitus toimii. Jos sä työnnät sen db:n sinne konttiin ilman mounttia tai persistent storagea, kontin kuollessa häviää myös data, viimeistään silloin kun sun image ja kontti tuhotaan.
 
Tässä on vaan se klassinen virhemahis jos ei tiedä täysin miten kontitus toimii. Jos sä työnnät sen db:n sinne konttiin ilman mounttia tai persistent storagea, kontin kuollessa häviää myös data, viimeistään silloin kun sun image ja kontti tuhotaan.
Juu, näinhän se on, puuhastellessa oppii.
 
Moi!

Iso Noob varoitus!! Täällä varmaan osataan auttaa... Olen saanut Intel Nucin päälle pörräämään Home Assistantin dockerilla kuten myös Zonealarmin dockerilla... Nyt kuitenkin haluaisin kokeilla machine.learning pakettia jonka yleiset ohjeet ovat:


mutta tuollahan se ei onnistu... Sain tällaisen viestin:

"Use the Docker template and change the repository to zoneminder.machine.learning."

Joten kuis tuo onnistuisi ihan stepbystep jos joku viitsisi auttaa... Ja siis Ubuntu 20.04 pyörii kaikki.
 
Toimiko imagen fetchaus tuolla docker pull komennolla? Ts. hakiko se imagen sulle? Tsekkaa docker image ls.

Koitas sitten ajaa tuo docker run komento ja vaihda viimeinen rivi pelkästään dlandon/zoneminder:latest

Otapa tosin huomioon että: Zoneminder 1.34 Docker (Deprecated - no longer supported)

 
Kiitoksia vastauksesta... Kommentoin tätä niin kuin olen ymmärtänyt.... Tuo dlandonin zonealarm.machine.learning ei ikäänkuin suoraan ole saatavilla vaan vain niin, että "repository" muutetaan tuohon machine.learning repositoryyn. Normaali dlandon/zoneminder:latest toki toimii mutta se ei ole minkä sieltä haluan asentaa...

ja tätä machine.learning dockeria tuo kaveri vie eteenpäin... hakee vaan fundia sinne...
 
Haluaisin saada Dokkun ja code-servering toimimaan hyvin yhteen. Yritin saada aluksi homman toimimaan niin että asennan dokkun ja sen jälkeen code-serverin nginx:llä eri ali domaineille, mutta en vaan mitenkään onnistunut siinä, vaan aina dokkun nginx asetukset laittoivat kaikki ali domainit ensimmäiseen appiin joka dokkuun oli asennettu. Vaikka minun ymmärrys näistä asioista onkin hyvin pieni niin mietin olisko mahdollista laittaa homma toimimaan niin että asentaisin dockerilla kaksi ubuntu konttia ja niihin erikseen code-serverin toiseen ja dokkun toiseen. Onko tässä mitään järkeä vai olisiko joku muu tapa parempi? Molemmista löytyy myös kontit valmiina, mutta en oikein tiedä miten ne saa toimimaan hyvin yhteen.

E. Sain tuon toimimaan jotenkin noilla konteilla.
 
Viimeksi muokattu:
Mulla on joitakin GPU:ta käyttäviä ohjelmia, jotka toimivat dockerissa ilman mitään ongelmia, kunhan hostissa on Nvidian ajurit ja nvidia-docker asennettu. Nyt kuitenkin yksi ohjelma ei toimi ihan suoraan, koska se vaatii kirjaston nimeltä libnvcuvid.so.1 jota ei löydy containerista. Hostista tuo löytyy symbolisena linkkinä tiedostoon /usr/lib/x86_64-linux-gnu/libnvcuvid.so.XXX.YY.ZZ, missä XXX.YY.ZZ on asennetun Nvidian ajurin versio. Pystyn kyllä kopioimaan tuon tiedoston containeriin ja tekemään symbolisen linkin, jonka jälkeen kaikki toimii. Tuo lienee kuitenkin aika purkkaratkaisu, koska tiedostonimestä päätellen kirjastolla ja ajuriversiolla on jonkinlainen yhteys, eli homma voi mennä pieleen jos hostin ajurin version muuttuu.

Täällä jollakin on ollut sama ongelma, mutta en oikein ymmärrä tuota ratkaisua, jossa sanotaan vain että "Once we corrected the install of nvidia-docker2 after docker is installed things cleared up." Ilmeisesti siis nvidia-dockerin pitäisi varmistaa se, että tuo kirjasto on containerissa aina "näkyvillä", mutta mulla se ei nyt toimi noin.
 
Mulla on joitakin GPU:ta käyttäviä ohjelmia, jotka toimivat dockerissa ilman mitään ongelmia, kunhan hostissa on Nvidian ajurit ja nvidia-docker asennettu. Nyt kuitenkin yksi ohjelma ei toimi ihan suoraan, koska se vaatii kirjaston nimeltä libnvcuvid.so.1 jota ei löydy containerista. Hostista tuo löytyy symbolisena linkkinä tiedostoon /usr/lib/x86_64-linux-gnu/libnvcuvid.so.XXX.YY.ZZ, missä XXX.YY.ZZ on asennetun Nvidian ajurin versio. Pystyn kyllä kopioimaan tuon tiedoston containeriin ja tekemään symbolisen linkin, jonka jälkeen kaikki toimii. Tuo lienee kuitenkin aika purkkaratkaisu, koska tiedostonimestä päätellen kirjastolla ja ajuriversiolla on jonkinlainen yhteys, eli homma voi mennä pieleen jos hostin ajurin version muuttuu.

Täällä jollakin on ollut sama ongelma, mutta en oikein ymmärrä tuota ratkaisua, jossa sanotaan vain että "Once we corrected the install of nvidia-docker2 after docker is installed things cleared up." Ilmeisesti siis nvidia-dockerin pitäisi varmistaa se, että tuo kirjasto on containerissa aina "näkyvillä", mutta mulla se ei nyt toimi noin.
Tää olikin ihan helppo, jos olisi lukenut nvidia-docker:n ohjeet: User Guide — NVIDIA Cloud Native Technologies documentation
Eli oletuksena nvidia-docker ei paljasta kaikkia näytönohjaimen ajureiden kykyjä, vaan ne pitää erikseen sallia ympäristömuuttujilla. Esimerkiksi jos Dockerfilen loppuun laittaa
Koodi:
ENV NVIDIA_DRIVER_CAPABILITIES=compute,utility,video,graphics
niin kaikki toimii. Ilmeisesti olen aiemmin käyttänyt vain base imageja joissa tuo asia on jo hoidettu kuntoon.
 
Windows, Docker Desktop ja Postresql.
Wsl2 backendilla kaikki toimii hyvin, että saa saatat tallennettua haluttuun kansioon. Mutta jos tarvetta on käyttää Hyper-V backendia kuten serverillä niin homma ei enää toimikaan.

Google on pullollaan erilaisia ohjeita mutta mikään ei vaan toimi. Yhdessä mainittiin että ei ole edes mahdollista saada tuolla kombinaatiolla toimimaan.

Virheenä
The files belonging to this database system will be owned by user "postgres".

Onko kukaan taistellut tämän kanssa?
 
Windows, Docker Desktop ja Postresql.
Wsl2 backendilla kaikki toimii hyvin, että saa saatat tallennettua haluttuun kansioon. Mutta jos tarvetta on käyttää Hyper-V backendia kuten serverillä niin homma ei enää toimikaan.

Google on pullollaan erilaisia ohjeita mutta mikään ei vaan toimi. Yhdessä mainittiin että ei ole edes mahdollista saada tuolla kombinaatiolla toimimaan.

Virheenä
The files belonging to this database system will be owned by user "postgres".

Onko kukaan taistellut tämän kanssa?

Jäi vähän epäselväksi, että mikä on "tämä". PG googlen perusteella toimii kyllä dockerissa Hyper-V:n kanssa (esim Benchmark PostgreSQL on all three systems: Docker versus native ), mutta en tiedä mitä haet noilla kansioilla.

edit: ehkä: käytä volumeja / luo paikallinen postgres käyttäjä?
 
Jäi vähän epäselväksi, että mikä on "tämä". PG googlen perusteella toimii kyllä dockerissa Hyper-V:n kanssa (esim Benchmark PostgreSQL on all three systems: Docker versus native ), mutta en tiedä mitä haet noilla kansioilla.

edit: ehkä: käytä volumeja / luo paikallinen postgres käyttäjä?
Eli kun lataan sen Postgresql ja käynnistän niin kun koitan "napata" sen data polun omaan volumeen niin silloin, tulee tuo herja eli ei tallenna dataa sinne Windowsin volumeen. Wsl2 kaikki toimii mutta Hyper-V backendilla ei. Se alkaa herjaa tuota permission erroria ja volumeen ei tule mitään. Jos poistaa postgresql /data niin se kaikki data jää sinne konttiin.
 
Eli kun lataan sen Postgresql ja käynnistän niin kun koitan "napata" sen data polun omaan volumeen niin silloin, tulee tuo herja eli ei tallenna dataa sinne Windowsin volumeen. Wsl2 kaikki toimii mutta Hyper-V backendilla ei. Se alkaa herjaa tuota permission erroria ja volumeen ei tule mitään. Jos poistaa postgresql /data niin se kaikki data jää sinne konttiin.

Joo, ei taida onnistua ilman volumeja:

Volumeissa tieto kyllä pysyy turvassa, ja niihin saa kyllä kopioitua ja niistä pois yhdenkin rivin loitsuilla käyttäen jotain pientä imagea.
 
Joo, ei taida onnistua ilman volumeja:

Volumeissa tieto kyllä pysyy turvassa, ja niihin saa kyllä kopioitua ja niistä pois yhdenkin rivin loitsuilla käyttäen jotain pientä imagea.
Tähän itsekin päädyin, että pitää backuppaa se data ja sitten tehdä temppuja. Muuten kun ajat vahingossa down niin kaikki menee.

Todennäköisesti jos pitää Hyper-V backendilla ajaa niin sitten asentaa postgresql suoraan Windowssiin mutta parempi vain WSL2 mennä jos voi kun se ainakin toimii.
 
Tähän itsekin päädyin, että pitää backuppaa se data ja sitten tehdä temppuja. Muuten kun ajat vahingossa down niin kaikki menee.

Todennäköisesti jos pitää Hyper-V backendilla ajaa niin sitten asentaa postgresql suoraan Windowssiin mutta parempi vain WSL2 mennä jos voi kun se ainakin toimii.

Niillä nimetyillä volumeilla ne tiedot pysyy kyllä (jos ei liikaa töhötä), vakkka vetää kontit alas.
 
Niin eli jos luo erikseen sen local volumen? Ja sitten conposerilla ajaa vaan niitä muita ylös ja alas?

Ei tarvitse luoda erillään. (Ellei initialisointia varten joudu säätämään jotain, ja silloinkin katsoisin onko jotain vipuja docker-composeen, että luo vain volumet)

Ks.
Compose file version 3 reference

Tsekkaa volumet docker-compose downin jälkeen.

Tai sitten multa jää joku vaatimus huomioimatta, mutta luulisin, että saat tehtyä haluamasi.
 
Miten toimitte tilanteessa, jossa on useampi Dockerfilellä varustettu projekti, jotka ovat enimmäkseen toisiinsa liittymättömiä, mutta kuitenkin jakavat joitain yksittäisiä komponentteja, joita ei ole verkosta ladattavissa? Eli jos teillä on vaikka joku lokaali datasetti tai esim. python-ohjelma, jotka haluatte sisällyttää useampaan docker imageen. COPY:llähän ei voi kopioida mitään build-kontekstin ulkopuolelta, vaikka käyttäisi symbolisia linkkejä.

Kysymys on siis oleellisesti sama kuin tässä (linkki menee suoraan kommenttiin johon ei ole vastattu): How to install local packages using pip as part of a docker build?

Mietin, että yksi ratkaisu olisi tehdä sellainen "varasto-image", jonka ainoana tarkoituksena on pitää sisällään tiedostoja, joita tarvitaan useammassa imagessa. Eli esim. näin:
Koodi:
FROM scratch
COPY /path/to/my_data /my_data
Jos tämän nimeää varastoksi, niin sieltä voi sitten kaivaa tiedostot muissa Dockerfileissä näin:
Koodi:
COPY --from=varasto /my_data /my_data

Onko tässä mitään järkeä?

Rupesin myös miettimään vähän toista asiaa, eli miten Dockerfilessä voi disabloida sen, että lokaalisti löytymätöntä imagea haetaan automaattisesti Docker Hubista (koskee sekä FROM-komentoa että yllä nähtyä COPY-komennon variaatiota)? Eli esim. yllä jälkimmäisessä tapauksessa buildin pitäisi epäonnistua, jos varasto-nimistä imagea ei löydy omalta koneelta.
 
Ei tarvitse luoda erillään. (Ellei initialisointia varten joudu säätämään jotain, ja silloinkin katsoisin onko jotain vipuja docker-composeen, että luo vain volumet)

Ks.
Compose file version 3 reference

Tsekkaa volumet docker-compose downin jälkeen.

Tai sitten multa jää joku vaatimus huomioimatta, mutta luulisin, että saat tehtyä haluamasi.
En muistanutkaan kuittailla miten kävi. Ongelma oli että kun oli jo samanniminen käytössä ja se piti poistaa. Sen jälkeen sai tehtyä local volumen ja homma toimii.
 
Tee volume niistä kamoista mitä haluat molempiin kontteihin?
No tämä toimii tietysti niin pitkään, kun sitä kamaa ei tarvitse build-vaiheessa eikä sitä kamaa tarvitse jakaa muille. Mutta jos sen haluaa sisällyttää julkaistavaan imageen ja/tai sitä tarvitsee buildissa (esim. ohjelman kääntämistä varten), niin se tavara pitäisi olla näkyvillä buildin aikana, eli käytännössä siis build-kontekstissa.
 
Mites git(oliko binääreitä vai pelkkiä python moduuleita?), pystytkö heittämään sitä kamaa suoraan repoon ja hakemaan ne sieltä kun on tarkoitus buildata?
 
Mites git(oliko binääreitä vai pelkkiä python moduuleita?), pystytkö heittämään sitä kamaa suoraan repoon ja hakemaan ne sieltä kun on tarkoitus buildata?
Tämä olisi helppo ratkaisu, jos kama olisi open source, tai jos jotenkin muuten olisi mahdollista heittää ne repoon, johon ei tarvitse kirjautua. SSH-avaimien tai salasanojen tunkeminen Dockerfileen on liian monimutkaista.

En edes tarkalleen muista mikä oli alkuperäinen ongelma, mutta taida päätyä siihen, että laitan kamat johonkin yksityiseen repoon tyyliin gitlab, jossa automatisoin docker imagen luonnin repoon pushatessa. Kirjautumista vaativa container registry ei ole ongelma, koska kirjautuminen tapahtuu ennen buildia (esim. docker login). Lisäksi jos muistaa käytää pull-vipua docker buildin yhteydessä, niin silloin se COPY-komento kai aina yrittää hakea tuoreen imagen, eli efektiivisesti homma toimii ikään kuten Dockerfilessä olisi "COPY /path/to/local/repo /my_data", kunhan oman koneen repo on synkassa gitlabin kanssa.
 
Tee niistä projekteista ja jaetusta datasta lokaalit git repot ja tuo jaettu kama projekteille submodulena niin se on näkyvillä build kontekstissa. Saat samalla jonkinlaista versiointia asioihin eikä lokaalia repoa tarvitse mihinkään pushata. Tämä siis toimii niin pitkään, kun kaikki tavara on siinä yhdellä koneella ja ainut ongelma on vain saada data näkyviin haluttuun paikkaan. En toki ymmärrä mikä siinä tilanteessa estää tekemästä hakemistorakennetta sellaiseksi, että jaettu tavara on vaikka hakemistossa /projects/common ja muut sitten /projects/project1, /projects/project2... jne jolloin voit toki käyttää build kontekstina /projects hakemistoa ja osoittaa tiettyyn Dockerfileen yksittäisen projektin alta sitä buildatessa. Toki Dockerfilessä pitää huomioida hakemistopolut vastaavasti jos projektikohtaisesti kopioidaan lisää asioita kontin sisään.
 
Viimeksi muokattu:
En toki ymmärrä mikä siinä tilanteessa estää tekemästä hakemistorakennetta sellaiseksi, että jaettu tavara on vaikka hakemistossa /projects/common ja muut sitten /projects/project1, /projects/project2... jne jolloin voit toki käyttää build kontekstina /projects hakemistoa ja osoittaa tiettyyn Dockerfileen yksittäisen projektin alta sitä buildatessa. Toki Dockerfilessä pitää huomioida hakemistopolut vastaavasti jos projektikohtaisesti kopioidaan lisää asioita kontin sisään.

Eikö tuossa ainakin potentiaalisesti ongelmana build kontekstin koko? Ei välttämättä (ainakaan iso) ongelma, jos noissa vain koodifiluja.
 
Eikö tuossa ainakin potentiaalisesti ongelmana build kontekstin koko? Ei välttämättä (ainakaan iso) ongelma, jos noissa vain koodifiluja.

Pitää toki huomioida joo, jos tiedostoja on enemmän ja erityisesti jos imaget on muuhun kuin omaan käyttöön. .dockerignore tiedosto jeesaa tässä. Sillä saa tiputettua tiedostoja/hakemistoja pois kontekstista tarpeen mukaan. Voi olla geneerinen tai imagekohtainen.
 
Viimeksi muokattu:
Tuli sit jostain syystä päivitettyä tuo docker-comose raspissa tuohon uudempaan versioon 2.x. Kaikki toimii muuten mallikkaasti, mutta tabilla komennon täydennys ei enää toimi. Onko tätä nyt mahdollista jotenkin saada pelittämään kuitenkin?

Eli ennen kuin kirjoitin docker-co ja painoi tabia, täydentyi mukavasti docker-compose. Nyt kun kirjoittaa docker co, ei tabi täydennä mitään. Asennus on tehty noudattaen virallisia ohjeita: Compose V2

Tämähän oli vissiin yksi suuri muutos tuossa 1.x ja 2.x versioiden välillä, että komento muuttui docker-compose:sta docker compose.ksi.
 

Statistiikka

Viestiketjuista
257 779
Viestejä
4 478 081
Jäsenet
74 011
Uusin jäsen
velle

Hinta.fi

Back
Ylös Bottom