Telepítés

Ugyanúgy docker-compose-t használunk.

docker-compose.yml

version: '2'
services:
  nextcloud:
    image: 'nextcloud:20.0.2'
    network_mode: bridge
    ports:
      - '127.0.0.1:18083:80'
    volumes:
      - ./volumes/nextcloud:/var/www/html
    extra_hosts:
      - 'docker:172.17.42.1'
    environment:
      - MYSQL_DATABASE=nextcloud
      - MYSQL_USER=nextcloud
      - MYSQL_PASSWORD=password
      - MYSQL_HOST=172.17.42.1
      - NEXTCLOUD_ADMIN_USER=root
      - NEXTCLOUD_ADMIN_PASSWORD=password
      - NEXTCLOUD_TRUSTED_DOMAINS=cloud.domain.hu
      - SMTP_HOST=172.17.42.1
      - SMTP_PORT=25
      - MAIL_FROM_ADDRESS=cloud@domain.hu

Megjegyzések

• Az image értéknél fontos a pontos verzió megadása, hogy az ismételt docker-compose up hívásokkor még véletlenül se frissüljön automatikusan az image, mint ahogy a latest tag esetén tenné.
• A network_mode: bridge szükséges, hogy a konténer a megadott ip címen elérje a docker host-on futó adatbázis szervert. Szép, ha a teljes szolgáltatás saját alhálózaton helyezkedik el, saját adatbázis szerverrel, azaz microservices, de futtasson és backup-oljon külön mysql konténert minden projekthez az, akinek ahhoz van kedve.
• Az extra_hosts alatti elemek hostname / ip cím párok. Az így definiált hostnevek ugyanúgy használhatóak a konténerben, mintha az /etc/hosts fájlban lennének megadva.

Konténer indítása

# indítás
docker-compose up
# vagy
# indítás a háttérben
docker-compose up -d

Nginx vhost - reverse proxy

server {
    listen 80;
    listen 443 ssl;
    server_name cloud.domain.hu;

    ssl_certificate /etc/letsencrypt/live/cloud.domain.hu/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/cloud.domain.hu/privkey.pem;

    if ($scheme = http) {
        return 301 https://$host$request_uri;
    }

    include includes/letsencrypt;

    location = /.well-known/carddav {
        return 301 $scheme://$host:$server_port/remote.php/dav;
    }
    location = /.well-known/caldav {
        return 301 $scheme://$host:$server_port/remote.php/dav;
    }

    location / {
        proxy_pass http://127.0.0.1:18083;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $remote_addr;
        proxy_set_header X-Forwarded-Proto $http_x_forwarded_proto;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_redirect off;
        proxy_buffering off;
        add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
    }
}

Megjegyzések

• A location = /.well-known/carddav és location = /.well-known/caldav bejegyzések teszik lehetővé, hogy carddav és caldav protokollon keresztül elérjük a konténerben futó Nextcloud címtárát és naptárát.
• A proxy_set_header Upgrade $http_upgrade; és  proxy_set_header Connection "upgrade"; sorok a websocket kapcsolatok működéséhez szükségesek. Lsd: http://nginx.org/en/docs/http/websocket.html .
• @TODO: Utánanézni, hogy a proxy_redirect off; és proxy_buffering off; miért kellenek.

Konfiguráció: volumes/nextcloud/config/config.php

'trusted_domains' =>
  array (
      0 => 'localhost',
      1 => 'cloud.domain.hu'
  ),
  'overwrite.cli.url' => 'https://cloud.domain.hu',
  'overwriteprotocol' => 'https',

Telepítés

Mindenek előtt adjunk hálát a Dockernek, mert nélküle nemigen telepítenénk ilyen összetett cuccokat, inkább megírnánk magunk - mint ahogy azt még pár nappal ezelőtt is terveztük. Áldott legyen.

Miben is van a Moodle megírva? Nem mindegy? Hát ezért adunk hálát a Dockernek. Még az is lehet, hogy Ruby-ban, mint a GitLab, de az se baj.

Mondjuk ki érti, miért kell egy webalkalmazást Ruby-ban csinálni, mikor ott a jó öreg PHP, meg van már Python, ami ennek a honlapnak is az alapja, ha meg igazán durvát akarunk, programozhatjuk C++(cémegmeg)-ben is. ... Egyesek nem tudják jódolgukban micsinálnak. Jó, hogy nem mindjárt Scratch-ben, vagy Perl-ben ...

A lényegre térve

Először használtam docker-compose -t a saját feljesztésű szkriptjeim és konfigurációs fájljaim helyett. Nem esett rosszul. A docker-compose hátránya, hogy a docker-compose.yml -ből nem lehet shell parancsokat hívni. Előnye, hogy a docker összes funkciója elérhető rajta keresztül és nem kell évekkel ezelőtt írott szkripteket túrni, hogy lássuk, hogy egy adott beállítást hogyan kell megvalósítani. Elég a docker-compose dokumentációját túrni, ami talán rendesen meg van írva. Mert azok ott ráérnek arra is.

Tanulság : ne próbáljunk meg egy kész eszközt saját megoldásokkal kiváltani csak azért, mert nem akarjuk elolvasni a dokumentációját.

Feladat : a régi docker kezelő szkriptjeim lecserélése docker-compose-ra.

docker-compose.yml

version: '2'
services:
  nextcloud:
    image: 'nextcloud:20.0.2'
    network_mode: bridge
    ports:
      - '127.0.0.1:18083:80'
    volumes:
      - ./volumes/nextcloud:/var/www/html
    extra_hosts:
      - 'docker:172.17.42.1'
    environment:
      - MYSQL_DATABASE=nextcloud
      - MYSQL_USER=nextcloud
      - MYSQL_PASSWORD=password
      - MYSQL_HOST=172.17.42.1
      - NEXTCLOUD_ADMIN_USER=root
      - NEXTCLOUD_ADMIN_PASSWORD=password
      - NEXTCLOUD_TRUSTED_DOMAINS=cloud.domain.hu
      - SMTP_HOST=172.17.42.1
      - SMTP_PORT=25
      - MAIL_FROM_ADDRESS=cloud@domain.hu
  moodle:
    image: 'docker.io/bitnami/moodle:3.10.0'
    network_mode: bridge
    ports:
      - '127.0.0.1:18082:8080'
    volumes:
      - ./volumes/moodle_data:/bitnami/moodle
      - ./volumes/moodledata_data:/bitnami/moodledata
    extra_hosts:
      - 'docker:172.17.42.1'
    environment:
      - MOODLE_USERNAME=root
      - MOODLE_PASSWORD=password
      - MOODLE_EMAIL=moodle@domain.hu
      - MOODLE_SITE_NAME=moodle
      - MOODLE_DATABASE_HOST=172.17.42.1
      - MOODLE_DATABASE_PORT_NUMBER=3306
      - MOODLE_DATABASE_NAME=moodle
      - MOODLE_DATABASE_USER=moodle
      - MOODLE_DATABASE_PASSWORD=password
      - ALLOW_EMPTY_PASSWORD=yes

Megjegyzések

• Az image értéknél fontos a pontos verzió megadása, hogy az ismételt docker-compose up hívásokkor még véletlenül se frissüljön automatikusan az image, mint ahogy a latest tag esetén tenné.
• A network_mode: bridge szükséges, hogy a konténer a megadott ip címen elérje a docker host-on futó adatbázis szervert. Szép, ha a teljes szolgáltatás saját alhálózaton helyezkedik el, saját adatbázis szerverrel, azaz microservices, de futtasson és backup-oljon külön mysql konténert minden projekthez az, akinek ahhoz van kedve.
• Az extra_hosts alatti elemek hostname / ip cím párok. Az így definiált hostnevek ugyanúgy használhatóak a konténerben, mintha az /etc/hosts fájlban lennének megadva.

Konténerek indítása

# indítás
docker-compose up
# vagy
# indítás a háttérben
docker-compose up -d

Nginx vhost - reverse proxy

server { 
    listen 80;
    listen 443 ssl;
    server_name moodle.domain.hu;

    ssl_certificate /etc/letsencrypt/live/moodle.domain.hu/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/moodle.domain.hu/privkey.pem;

    if ($scheme = http) {
        return 301 https://$host$request_uri;
    }

    include includes/letsencrypt;

    location / {
        proxy_pass http://127.0.0.1:18082;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $remote_addr;
        proxy_set_header X-Forwarded-Proto $http_x_forwarded_proto;
        proxy_set_header X-Real-IP $remote_addr;
        add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
    }
}

Megjegyzések

A titkosítást szokás szerint a docker host-on futó nginx reverse proxy intézi, a konténerben levő Moodle meg persze, hogy nem viseli ezt olyan jól. A konfiguráció így némi módosításra szorul.

Konfiguráció: volumes/moodle_data/config.php

$CFG->wwwroot = 'https://moodle.domain.hu';
$CFG->reverseproxy = true;
$CFG->sslproxy = true;

Nextcloud integráció

HTTPS nélkül nem fog működni. Nem úgy megy az manapság, hogy webes szolgáltatásokat csinálunk külső fél, legalább a letsencrypt igénybevétele nélkül.

Nextcloud

Az Administration / Security / OAuth 2.0 clients menüpontban felveszünk egy új klienst mondjuk Moodle néven. A Redirection URI https://moodle.domain.hu/admin/oauth2callback.php lesz. Mentés után láthatóvá válik a Client Identifier és a Secret , amiket a kliens beállításánál használhatunk.

Moodle

A Site administration / Server / OAuth 2 services / Create new Nextcloud service menüpontban beállítjuk a Nextcloud OAuth 2 szolgáltatót. A Name lehet Nextcloud, a Client id és a Client secret az előző bekezdésben említett értékek. A  Service base URL a Nextcloud szolgáltatásunk címe, azaz https://cloud.domain.hu.

A következő lépés: Site administration / Plugins / Repositories / Manage repositories , ahol engedélyezzük a Nextcloud-ot, majd a Settings menüpontban létrehozunk egy repository-t.

A dolog elméletileg készen van. A felhaszálók felhasználhatnak a Nextcloudban tárolt fájlokat a Moodle tartalmainak szerkesztéséhez.

Telepítés

Szükség van a certbot-auto eszközre. Ha lehet, akkor csomagkezelőből telepítve. Ha nem lehet, akkor az alábbi címről letöltve: https://certbot.eff.org

Ha az utóbbi megoldás marad, annak nem örülünk, mivel a szkript gátlástalanul telepít python csomagokat és frissítgeti magát.

Nginx beállítások

Lehetővé kell tenni, hogy a Letsencryt végrehajtsa a domainek tulajdonjogának ellenőrzését, ami annyiból áll, hogy elhelyez teszt fájlokat a megadott helyen, aztán megpróbálja elérni azokat az összes domainen, amikre a tanúsítványt kérjük.

Az alábbi sorok bekerülnek az /etc/nginx/includes/common fájlba, amit minden vhost fájl beolvas, így minden vhost alatt létezni fog a /.well-known/acme-challenge/ cím. Pl: http://www.morknat.hu/.well-known/acme-challenge/.

location ^~ /.well-known/acme-challenge/ {
     # /etc/letsencrypt/webroot/.well-known/acme-challenge/
     root /etc/letsencrypt/webroot;
}

Tanúsítványok létrehozása

A teendő annyi, mint rootként kiadni egyetlen parancsot.

certbot certonly --webroot -w /etc/letsencrypt/webroot -d morknat.hu,www.morknat.hu,mork.morknat.hu

A válasz jó esetben valami ilyesmi lesz:

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator webroot, Installer None
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for savariaforum.hu
http-01 challenge for www.savariaforum.hu
http-01 challenge for mork.savariaforum.hu
Using the webroot path /var/www/letsencrypt for all unmatched domains.
Waiting for verification...
Cleaning up challenges
Unable to clean up challenge directory /var/www/letsencrypt/.well-known/acme-challenge
IMPORTANT NOTES:
- Congratulations! Your certificate and chain have been saved at:
/etc/letsencrypt/live/savariaforum.hu/fullchain.pem
Your key file has been saved at:
/etc/letsencrypt/live/savariaforum.hu/privkey.pem
Your cert will expire on 2017-12-19. To obtain a new or tweaked
version of this certificate in the future, simply run certbot-auto
again. To non-interactively renew *all* of your certificates, run
"certbot-auto renew"
- If you like Certbot, please consider supporting our work by:
Donating to ISRG / Let's Encrypt: https://letsencrypt.org/donate
Donating to EFF: https://eff.org/donate-le

Tanúsítványok megújítása

Cronból futtaható. Érdemes néha kézzel is végrehajtani, hogy kiderüljön, ha valami hiba történik. Mert ha például módosul a webszerver konfiguráció és bizonyos domainek tanúsítványai nem frissülnek, az kellemetlen lehet.

certbot renew --no-self-upgrade

Nginx vhost beállítások

A megfelelő vhost fájlok valahogy így fognak kinézni:

server {
    listen 80;
    listen 443 ssl http2;
    server_name morknat.hu;
    root /home/dark/projects/morknat.hu/;

    ssl_certificate /home/dark/Devel/ca/certs/morknat.hu.crt.pem;
    ssl_certificate_key /home/dark/Devel/ca/private/morknat.hu.key.pem;

    if ($scheme = http) {
        return 301 https://$host$request_uri;
    }

    include includes/common;
}