Tag: docker

Headscale come alternativa a Tailscale

Tailscale è un ottimo modo per collegare tra loro server diversi.
I client sono open source e disponibili per una grande varietà di piattaforme, non da ultima i NAS Synology, compreso il mio vecchio DS214se.
La configurazione è rapida e di nessuna difficoltà, le prestazioni sono inferiori a quelle che pare si possano avere utilizzando un semplice tunnel Wireguard ma sono comunque all’altezza dei compiti svolti dai miei server amatoriali.
Il problema è che il server di autenticazione è l’unico componente proprietario.

Headscale è un’implementazione opensource del server Tailscale.
Al momento in cui scrivo è arrivato alla release 0.12, quindi il progetto non ancora del tutto maturo, ma dalle mie prime prove è già utilizzabile con un buon margine di tranquillità.

Per l’installazione mi sono avvalso di questo tutorial, con qualche aggiunta presa qua e là.
Questa procedura prevede che Docker e Docker Compose siano installati sulla macchina che farà da server, io ho utilizzato una VPS molto economica con Debian Buster ed installarli è facile.
E’ inoltre necessario un web proxy – io ho utilizzato Nginx con certbot che gestisce i certificati SSL e relativi redirect.
Questo è un esempio di configurazione:

# Redirect HTTP to HTTPS
server {
    if ($host = esempio.miodominio.it) {
        return 301 https://$host$request_uri;
    } # managed by Certbot


    listen 80;
    listen [::]:80;
    server_name esempio.miodominio.it;
    return 301 https://$host$request_uri;


}
server {
    listen 443 ssl;
    server_name esempio.miodominio.it;

    client_body_timeout 5m;
    client_header_timeout 5m;

    access_log            /var/log/nginx/esempio.miodominio.it.log;
    error_log            /var/log/nginx/esempio.miodominio.it.error.log info;

    # reverse proxy
    location / {
         proxy_pass http://127.0.0.1:27896;  # headscale listen_addr
         proxy_read_timeout 6m;
         proxy_ignore_client_abort off;
         proxy_request_buffering off;
         proxy_buffering off;
         proxy_no_cache "always";
         proxy_set_header Host $host;
         proxy_set_header X-Real-IP $remote_addr;
         proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }

    ssl_certificate /etc/letsencrypt/live/esempio.miodominio.it/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/esempio.miodominio.it/privkey.pem; # managed by Certbot
}

Per l’installazione dei client sulle varie piattaforme la documentazione reperibile sul sito di Tailscale o con una qualsiasi ricerca è sufficientemente esauriente e di facile esecuzione.

Come prima cosa creaiamo la cartella in cui installeremo Headscale:

sudo mkdir -p /opt/headscale

Spostiamoci nella cartella appena creata e eseguiamo i seguenti comandi:

mkdir -p ./config
touch ./config/db.sqlite
curl https://raw.githubusercontent.com/juanfont/headscale/main/config-example.yaml -o ./config/config.yaml

abbiamo così creata una cartella per le configurazioni, al cui interno abbiamo creato un file .sqlite per l’archivio e scaricato una copia dell’esempio di file di configurazione. Le modifiche a questo ultimo file saranno minime.

Ora creiamo il file docker-compose.yml:

nano docker-compose.yml

version: '3.5'
services:
  headscale:
    image: headscale/headscale:latest
    volumes:
      - ./config:/etc/headscale/
      - ./data:/var/lib/headscale
    ports:
      - 27896:8080
    command: headscale serve
    restart: unless-stopped

La porta esterna è la 27896, ma siete liberi di cambiarla come meglio preferite, impostate correttamente il proxy (cfr. la configurazione di Nginx qui sopra).

Prima di avviare Headscale editiamo il file di configurazione:

nano config/config.yml

inserendo l’URL del nostro server:

server_url: https://esempio.miodominio.it

Adesso possiamo avviare Headscale:

docker-compose up -d

Sui client, una volta installato Tailscale, basterà specificare il server di login al momento dell’avvio perchè tutto funzioni quasi magicamente:

tailscale up --login-server https://esempio.miodominio.it

Creare un veloce sito WordPress con Docker e Raspberry Pi

Mi è capitato di dover effettuare importanti modifiche ad un sito realizzato con WordPress e avere le necessità di condividere il lavoro con altre persone.
Invece di “pasticciare” sul server di produzione, ho pensato di utilizzare il Raspberry Pi 4 che ho in casa come server di sviluppo.
Siccome il Raspberry in questione svolge già una miriade di compiti, per non smanettare troppo ho deciso di usare Docker, così da avere un’istanza preconfigurata di WordPress facilmente installabile e rimovibile quando non mi servisse più.

Su Docker Hub esiste l’immagine ufficiale di WordPress, ma si appoggia ad un database MySQL che non sembra funzionare sull’architettura ARM del Raspberry Pi.
Ho quindi scelto un’immagine specifica per ARM e l’installazione è andata liscia.

Questo è il mio file docker-compose.yml:

version: '3.1'
 services:
 wordpress:
     image: wordpress:latest
     container_name: wordpress
     restart: always
     ports:
       - 8080:80 # il sito comunicherà con l'esterno attraverso la porta 8080, modificabile a piacere  
     environment:
       WORDPRESS_DB_HOST: db
       WORDPRESS_DB_USER: test
       WORDPRESS_DB_PASSWORD: password
       WORDPRESS_DB_NAME: test
     volumes:
       - /opt/docker/wordpress/data:/var/www/html #per comodità ho creato una cartella dove archiviare i file di WordPress
 db:
     image: biarms/mysql # ho modificato questa riga per utilizzare l'immagine MySQL di biarms per ARM
     restart: always
     environment:
       MYSQL_DATABASE: test
       MYSQL_USER: test
       MYSQL_PASSWORD: password
       MYSQL_RANDOM_ROOT_PASSWORD: '1'
     volumes:
       - db:/var/lib/mysql
 volumes:
   wordpress:
   db:

Non sono un esperto di Docker, quindi probabilmente tutto si potrebbe fare meglio di così, ma in questo modo nel giro di pochi minuti ho avuto un’istanza funzionante di WordPress raggiungibile all’indirizzo http://<IP_RASPBERRYPI>:8080 .

Perchè il sito fosse raggiungibile anche dall’esterno mi è bastato utilizzare il reverse proxy Nginx già presente nella mia configurazione (a voi il divertimento eventuale di configurarlo e aprire le porte del vostro router casalingo, sul web trovare migliaia di tutorial e how-to) aggiungendo queste righe al file .conf già presente in /etc/nginx/sites-enabled :

location /test/ {
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_pass http://0.0.0.0:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-Host $host;

Dopo aver riavviato Nginx

$ systemctl reload nginx.service

la mia installazione WordPress è raggiungibile digitando http://MIO_INDIRIZZO_IP/test .

Però si era detto che questo sarebbe stato un sito di prova e non è bello che sia accessibile da chiunque.
Per questo ci viene in soccorso la basic authentication di Nginx : basta creare gli utenti desiderati con il comando :

$ sudo htpasswd /etc/apache2/.htpasswd utente1

e poi editare ancora il precedente file .conf di Nginx :

...
 location /test/ {
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_pass http://0.0.0.0:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-Host $host;

        # authentication
        auth_basic           "Area di test - Accesso riservato";
        auth_basic_user_file /etc/apache2/.htpasswd;

Un altro $ systemctl reload nginx.service per caricare la nuova configurazione e voilà!

A questo punto è bastato fare una copia del sito originale con il plugin Duplicator per WordPress, cancellare il contenuto della cartella data e sostituirlo con i due file creati da Duplicator, un archivio e un installer.
Andando all’indirizzo http://MIO_INDIRIZZO_IP/test/installer.php ho avviato la procedura di migrazione e in pochi minuti ho avuto una perfetta replica del mio sito, pronta per essere modificata a piacimento.
Una volta soddisfatto delle modifiche, sempre utilizzando Duplicator, potrò compiere la migrazione in senso inverso, dal server di test a quello pubblico.