Docker, Container & Kubernetes

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

Tabulaattoritäydennys unix-tyylisessä komentotulkissa on jokaisen komentotulkin oma asia.
Varsinaisen komennon (esim. vanhan version "docker-compose") täydennys tulee automaattisesti, koska komentotulkki tutkii etukäteen PATH-ympäristömuuttujassa listatut hakemistot ja kerää itselleen listan niistä löytyvistä ajokelpoisista ohjelmista.

Kun komento on muotoa "docker compose jotain", varsinainen ajettava komento on "docker" ja seuraavat sanat kuten "compose" ovat komentoriviparametreja sille. Komentotulkki "tietää" automaattisesti ainoastaan komentotulkkiin itseensä sisäänrakennettujen komentojen parametrien syntaksin, joten se ei ilman lisätietoja pysty arvaamaan että "docker co" pitäisi olla "docker compose".

Se voiko tuollaisia lisätietoja tarjota täydennysmekanismille ja jos voi niin miten se tehdään, riippuu siitä mitä komentotulkkia käytät. Linuxissa yleisin oletuskomentotulkki on bash, ja sille voi tarjota ylimääräisiä komentorivin täydennyssääntöjä tiputtamalla määrittelytiedostoja hakemistoon /etc/bash_completion.d/. Vanhan version "docker-compose"-komennolle oli tällainen säännöstö dokumentoidusti tarjolla: Command-line completion

Jotta kakkosversion tyyli toimisi, pitää varsinaisen "docker"-komennon täydennyssäännöstö päivittää versioon joka sisältää compose-pluginin tunnistuksen ja täydennyssäännöt myös pluginille. Tästä saattaa olla apua: https://raw.githubusercontent.com/docker/cli/master/contrib/completion/bash/docker

Jos tarvitset Docker-komentojen täydennysratkaisua jollekin muulle komentotulkille, tästä linkistä pääsee suoraan Dockerin github-repositorion siihen osaan jossa näitä löytyy: cli/contrib/completion at master · docker/cli

Tällä hetkellä on nähtävästi tarjolla Docker-komentojen täydennysratkaisu bashin lisäksi zsh-komentotulkille (= oletus uusissa Maceissa), fish-komentotulkille ja PowerShellille.
 
(Ja täältä pikainen suosittelu fishille. Ei ole tarvinnut katua kun olen siihen siirtynyt Macissä. Kaikki vaan toimii suoraan pakasta.)
 
Windows 11, Docker Desktop ja kontti. Mikä on oikea tapa tuoda yhteys kontin ja hostin perässä olevaan verkkoon? Kai tämä mahdollista on?

Tarkoitus saada kontti kommunikoimaan verkon laitteiden kanssa, jotta saan haettua dataa.

Transparent verkko löytyi mutta tämä on ilmeisesti poistettu ja ei enää käytössä.

Käytössä WSL2.

Linuxilla ei mitään ongelmaa ajaa ja kommunikoida ulkoiseen verkkoon. Kyseessä Linux-container.

Edit. Ongelma oli dockerin vakioverkko. Tämän kun vaihtoi niin johan toimii.
 
Viimeksi muokattu:
Ubuntu palvelimella pyörii dockerissa Jellyfin ja sille Nginx reverse proxynä. Conffi toimii, mutta Jellyfiniin pääsee myös suoraan sen omalla portilla Nginx ohi. Voiko tuon 8096 portin jotenkin muuttaa sellaiseksi että vain nginx kontti pääsee siihen tai tarviiko vaan torjua se hostin iptablesilla?

Koodi:
 version: '3.5'
services:
  nginx:
    image: nginx:latest
    container_name: nginx_container
    ports:
      - 80:80
      - 443:443
    volumes:
      - /data/docker/letsencrypt:/etc/letsencrypt
      - /data/docker/nginx/nginx.conf:/etc/nginx/nginx.conf
  jellyfin:
    image: jellyfin/jellyfin
    container_name: jellyfin
    ports:
      - 8096:8096
    volumes:
      - /data/docker/jellyfin/config:/config
      - /data/docker/jellyfin/cache:/cache
      - /data/shares/music:/music
    restart: 'unless-stopped'
    environment:
      - PUID=117
      - PGID=1002
      - TZ=Europe/Helsinki
  dnsrobocert:
    image: adferrand/dnsrobocert
    container_name: dnsrobocert
    volumes:
    - /data/docker/letsencrypt:/etc/letsencrypt
    - /data/docker/dnsrobocert:/etc/dnsrobocert
    restart: 'unless-stopped'
 
Ubuntu palvelimella pyörii dockerissa Jellyfin ja sille Nginx reverse proxynä. Conffi toimii, mutta Jellyfiniin pääsee myös suoraan sen omalla portilla Nginx ohi. Voiko tuon 8096 portin jotenkin muuttaa sellaiseksi että vain nginx kontti pääsee siihen tai tarviiko vaan torjua se hostin iptablesilla?

Koodi:
 version: '3.5'
services:
  nginx:
    image: nginx:latest
    container_name: nginx_container
    ports:
      - 80:80
      - 443:443
    volumes:
      - /data/docker/letsencrypt:/etc/letsencrypt
      - /data/docker/nginx/nginx.conf:/etc/nginx/nginx.conf
  jellyfin:
    image: jellyfin/jellyfin
    container_name: jellyfin
    ports:
      - 8096:8096
    volumes:
      - /data/docker/jellyfin/config:/config
      - /data/docker/jellyfin/cache:/cache
      - /data/shares/music:/music
    restart: 'unless-stopped'
    environment:
      - PUID=117
      - PGID=1002
      - TZ=Europe/Helsinki
  dnsrobocert:
    image: adferrand/dnsrobocert
    container_name: dnsrobocert
    volumes:
    - /data/docker/letsencrypt:/etc/letsencrypt
    - /data/docker/dnsrobocert:/etc/dnsrobocert
    restart: 'unless-stopped'

nginx:n konffi ei tässä näy mutta oletettavasti proxytät osoitteeseen http://jellyfin:8096? Jos näin niin ota docker-compose.yml:ssä jellyfinin kohdalta tuo ports kokonaan pois tai vaihda siihen 127.0.0.1:8096:8096 (vain hostikoneen localhostista saa yhteyden). Jellyfin kontti exposaa 8096 portin kyllä konttien sisäiseen verkkoon ja tuo ports parametri vain mappaa halutun portin hostikoneelta konttiin eli et tarvitse sitä ollenkaan.
 
Ubuntu palvelimella pyörii dockerissa Jellyfin ja sille Nginx reverse proxynä. Conffi toimii, mutta Jellyfiniin pääsee myös suoraan sen omalla portilla Nginx ohi. Voiko tuon 8096 portin jotenkin muuttaa sellaiseksi että vain nginx kontti pääsee siihen tai tarviiko vaan torjua se hostin iptablesilla?

Koodi:
 version: '3.5'
services:
  nginx:
    image: nginx:latest
    container_name: nginx_container
    ports:
      - 80:80
      - 443:443
    volumes:
      - /data/docker/letsencrypt:/etc/letsencrypt
      - /data/docker/nginx/nginx.conf:/etc/nginx/nginx.conf
  jellyfin:
    image: jellyfin/jellyfin
    container_name: jellyfin
    ports:
      - 8096:8096
    volumes:
      - /data/docker/jellyfin/config:/config
      - /data/docker/jellyfin/cache:/cache
      - /data/shares/music:/music
    restart: 'unless-stopped'
    environment:
      - PUID=117
      - PGID=1002
      - TZ=Europe/Helsinki
  dnsrobocert:
    image: adferrand/dnsrobocert
    container_name: dnsrobocert
    volumes:
    - /data/docker/letsencrypt:/etc/letsencrypt
    - /data/docker/dnsrobocert:/etc/dnsrobocert
    restart: 'unless-stopped'

Sen saa auki vain tuohon (automaatti) networkkiin exposella.

YAML:
  jellyfin:
    image: jellyfin/jellyfin
    container_name: jellyfin
    ports:
      - 8096:8096
-->
    expose:
    - 8096

Jos haluat, että tosiaan vain nginx kontti listatuista (t.s. ei jellyfin) pääsee siihen, niin voit asettaa networkit käsin, s.e. ne jotka yhteydessä toisiinsa on samassa (esim. nginxillä ja jellyfinillä jellynet). Yksi kontti voi olla kiinni useammassa.

YAML:
    networks:
      - jellynet
      - someothernet
 
Löytyykö hyvää suomenkielistä opasta, jonka avulla pääsisi alkuun konttien kanssa?
 
Löytyykö hyvää suomenkielistä opasta, jonka avulla pääsisi alkuun konttien kanssa?

En kyllä osaa neuvoa mitään suomenkielistä. Mutta suomalainen mutta englanninkielinen todella hyvä ilmainen kurssi on tämä:

 
nginx:n konffi ei tässä näy mutta oletettavasti proxytät osoitteeseen http://jellyfin:8096? Jos näin niin ota docker-compose.yml:ssä jellyfinin kohdalta tuo ports kokonaan pois tai vaihda siihen 127.0.0.1:8096:8096 (vain hostikoneen localhostista saa yhteyden). Jellyfin kontti exposaa 8096 portin kyllä konttien sisäiseen verkkoon ja tuo ports parametri vain mappaa halutun portin hostikoneelta konttiin eli et tarvitse sitä ollenkaan.

Itseasiassa Nginx osoittaa suoraan host koneen fyysisen verkkokortin IP osoitteeseen (192.168.100.5). En saanut tuota toimimaan viittamalla kontin nimeen, nginx herjasi ettei pysty selvittämään osoitetta. En keksinyt mitä siihen pitäisi määrittää, että se pystyisi selvittämään konttien nimet.

Nginx koko conffi, olen tunkenut tuon nyt vaan yhteen nginx.conf tiedostoon:
Koodi:
events {
}

http {
server {
    server_name jellyfin.omadomain.me;
    set $jellyfin 192.168.100.5;

    # HTTP configuration
    listen 80;
    listen [::]:80;

    # HTTP to HTTPS
    if ($scheme != "https") {
        return 301 https://$host$request_uri;
    }

    # HTTPS configuration
    listen 443 ssl;
    ssl_certificate /etc/letsencrypt/live/omadomain.me/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/omadomain.me/privkey.pem;

    add_header X-Frame-Options "SAMEORIGIN";
    add_header X-XSS-Protection "0"; # Do NOT enable. This is obsolete/dangerous
    add_header X-Content-Type-Options "nosniff";

    add_header Permissions-Policy "accelerometer=(), ambient-light-sensor=(), battery=(), bluetooth=(), camera=(), clipboard-read=(), display-capture=(), document-domain=(), encrypted-media=(), gamepad=(), geolocation=(), gyroscope=(), hid=(), idle-detection=(), interest-cohort=(), keyboard-map=(), local-fonts=(), magnetometer=(), microphone=(), payment=(), publickey-credentials-get=(), serial=(), sync-xhr=(), usb=(), xr-spatial-tracking=()" always;
    add_header Origin-Agent-Cluster "?1" always;

    location = / {
        return 302 http://$host/web/;
        #return 302 https://$host/web/;
    }

    location / {
        # Proxy main Jellyfin traffic
        proxy_pass http://$jellyfin:8096;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Forwarded-Protocol $scheme;
        proxy_set_header X-Forwarded-Host $http_host;

        # Disable buffering when the nginx proxy gets very resource heavy upon streaming
        proxy_buffering off;
    }

    # location block for /web - This is purely for aesthetics so /web/#!/ works instead of having to go to /web/index.html/#!/
    location = /web/ {
        # Proxy main Jellyfin traffic
        proxy_pass http://$jellyfin:8096/web/index.html;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Forwarded-Protocol $scheme;
        proxy_set_header X-Forwarded-Host $http_host;
   }
    location /socket {
        # Proxy Jellyfin Websockets traffic
        proxy_pass http://$jellyfin:8096;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Forwarded-Protocol $scheme;
        proxy_set_header X-Forwarded-Host $http_host;
    }
}
}
 
Itseasiassa Nginx osoittaa suoraan host koneen fyysisen verkkokortin IP osoitteeseen (192.168.100.5). En saanut tuota toimimaan viittamalla kontin nimeen, nginx herjasi ettei pysty selvittämään osoitetta. En keksinyt mitä siihen pitäisi määrittää, että se pystyisi selvittämään konttien nimet.

Nginx koko conffi, olen tunkenut tuon nyt vaan yhteen nginx.conf tiedostoon:

Ihan kirjaimellisesti noin niinkuin aiemmassa viestissä mainitsin eli http://jellyfin:8096, kontit on samassa docker composen luomassa verkossa, eli niiden tulisi resolvata toisensa ip-osoite ihan docker-compose.yml:ssä määritetyllä service nimellä.

Eihän dockerin konffissa ole määritetty mitään custom DNS resolvereita?
 
Ihan kirjaimellisesti noin niinkuin aiemmassa viestissä mainitsin eli http://jellyfin:8096, kontit on samassa docker composen luomassa verkossa, eli niiden tulisi resolvata toisensa ip-osoite ihan docker-compose.yml:ssä määritetyllä service nimellä.

Eihän dockerin konffissa ole määritetty mitään custom DNS resolvereita?

Joku tuossa mättää kun Nginx itkee ettei oo resolvereita
Koodi:
nginx_container | 2023/08/30 14:54:46 [error] 29#29: *3 no resolver defined to resolve jellyfin, client: 192.168.100.38, server: jellyfin.omadomain.me, request: "GET /web/serviceworker.js HTTP/1.1", host: "jellyfin.omadomain.me", referrer: "https://jellyfin.omadomain.me/web/serviceworker.js"


EDIT. Nyt kun jaksoin kertoa tarinan Bing chatille niin se ehdotti nimipalvelimen lisäämistä nginx.confiin, mikä jälkeen tuo vaikuttaisi toimivan myös kontin nimellä:
Koodi:
server {
    resolver 127.0.0.11;
    server_name jellyfin.omadomain.me;
    set $jellyfin jellyfin;

Ja otin sen jälkeen port määrityksen pois docker-composesta ja nyt toimii niin, että pääsee vain nginx läpi :thumbsup:
 
Viimeksi muokattu:
EDIT. Nyt kun jaksoin kertoa tarinan Bing chatille niin se ehdotti nimipalvelimen lisäämistä nginx.confiin, mikä jälkeen tuo vaikuttaisi toimivan myös kontin nimellä:
Koodi:
server {
    resolver 127.0.0.11;
    server_name jellyfin.omadomain.me;
    set $jellyfin jellyfin;

Ja otin sen jälkeen port määrityksen pois docker-composesta ja nyt toimii niin, että pääsee vain nginx läpi :thumbsup:

Aivan. Enpä tosiaan muistanut että nginx:lle täytyy erikseen kertoa resolveri. Hyvä että selvisi.
 
Aivan. Enpä tosiaan muistanut että nginx:lle täytyy erikseen kertoa resolveri. Hyvä että selvisi.

En ole ihan vakuuttunut, että tuo on aina välttämätöntä. Tai ainakaan en keksi mikä ero tuossa on yhteen tutkailemaani omaan. Jäi mietityttämään, joten poimin alle relevantit pätkät (tarkistin, että ei ole "resolver":ia), jos joku osaa kertoa jonkun oleellisen eron käsin määritellyn verkon lisäksi, vai onko se se ero..?

YAML:
services:
  a-server:
    container_name: a-server-${A_NAME}
    image: a-server
...
    networks:
      - anet
  webserver:
    image: nginx:mainline-alpine
    container_name: nginx-${A_NAME}
...
    networks:
      - anet
networks:
  anet:
    name: a-net-${A_NAME}

Apache config:
server {
        listen 4321 ssl ;
        server_name jotain.jotain.fi;

        location / {
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_set_header Host $host;
                proxy_pass http://a-server:4321;
 
En ole ihan vakuuttunut, että tuo on aina välttämätöntä. Tai ainakaan en keksi mikä ero tuossa on yhteen tutkailemaani omaan. Jäi mietityttämään, joten poimin alle relevantit pätkät (tarkistin, että ei ole "resolver":ia), jos joku osaa kertoa jonkun oleellisen eron käsin määritellyn verkon lisäksi, vai onko se se ero..?
Oletuksena Nginx tekee DNS selvityksen proxy_pass domainille ainoastaan käynnistyksen yhteydessä. Tämä johtaa siihen, että jos Nginx käynnistyy ennen kun verkko on kokonaan pystyssä, ei proxy_pass toimi lainkaan. Nginx:n resolver aktivoi Nginx:n oman sisäisen resolverin joka sitten toimii myös ajonaikaisesti. Ilman resolveria Nginx pitää reloadata sen jälkeen kun verkko on pystyssä tai jos proxy_pass domainin ip-osoite vaihtuu.
 
Oletuksena Nginx tekee DNS selvityksen proxy_pass domainille ainoastaan käynnistyksen yhteydessä. Tämä johtaa siihen, että jos Nginx käynnistyy ennen kun verkko on kokonaan pystyssä, ei proxy_pass toimi lainkaan. Nginx:n resolver aktivoi Nginx:n oman sisäisen resolverin joka sitten toimii myös ajonaikaisesti. Ilman resolveria Nginx pitää reloadata sen jälkeen kun verkko on pystyssä tai jos proxy_pass domainin ip-osoite vaihtuu.

Thanks. Tässä omassa tapauksessa tuo Nginx riippuukin (depends on) tuosta appiksesta (tarkoituksella), mikä selittää tuon toimivuuden.
 
Osaako joku auttaa ? Mulla on nassissa docker pyörimässä, ja siellä toimiva minecraft servu johon pääsee ulkopuolelta käsiksi. Miten saan tuonne lisäksi ympättyä modit, eli esim. tän all the mods 8:n ?
 
Määrittelet volumen kontille. Volume: modi/filujen/polku/hostissa:mine/servun/modi/polku
 
Mikähän voisi olla pielessä kun melkein aina docker compose down menee jumiin? Joutuu aina manuaalisesti poistamaan kontit dockerin ollessa kiinni.
 
Mikähän voisi olla pielessä kun melkein aina docker compose down menee jumiin? Joutuu aina manuaalisesti poistamaan kontit dockerin ollessa kiinni.

Joskus se on hidas, mutta oletan, ettei ole siitä kiinni. Tuossa alla näytti olevan asiallisisia vastauksia. Jos itse buildattu image, niin ainakin katsoisin ettei kontekstissa ole ylimääräistä.

 

Uusimmat viestit

Statistiikka

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

Hinta.fi

Back
Ylös Bottom