1 20/05/2026 8 min

Se devi provare Docker senza toccare il tuo laptop, Play with Docker è la scorciatoia più pulita: apri il browser, ottieni un host Linux temporaneo e lavori con Docker già pronto. Non è un sostituto di un ambiente stabile, ma per verifiche rapide, laboratori e demo è molto più pratico di una VM locale configurata al volo.

Il punto non è solo “usare Docker online gratis”. Il vantaggio vero è un altro: puoi riprodurre in pochi minuti un contesto pulito, mostrare un flusso a un team, verificare un Dockerfile, testare compose piccoli e fare esercizi senza sporcare la macchina di sviluppo. L’ambiente è effimero, quindi va trattato come un banco prova, non come un repository di lavoro.

Quando ha senso usarlo davvero

Play with Docker ha senso quando vuoi ridurre attrito operativo. È utile per onboarding, esercizi di base, prove di networking tra container, test di immagini pubbliche e dimostrazioni durante call o workshop. Se invece devi tenere dati persistenti, fare debug complesso o integrare tool esterni in modo continuativo, conviene passare a una macchina tua o a un ambiente cloud più controllato.

In pratica: se il risultato che cerchi è “capisco come funziona”, “verifico se il container parte” o “mostro un esempio”, PWD va bene. Se il risultato richiesto è “mantengo stato”, “carico segreti”, “simulo produzione” o “faccio benchmark seri”, no: lì l’effimerità diventa un limite, non un vantaggio.

Accesso e avvio: il flusso minimo

L’accesso avviene dal sito del servizio: scegli l’opzione di avvio, autentichi la sessione e ottieni un host remoto con Docker già disponibile. In genere il flusso è lineare: apri la console web, avvii l’ambiente e lavori da terminale nel browser. Il primo controllo da fare è sempre banale ma fondamentale: verificare che Docker risponda davvero prima di lanciare qualunque test.

Subito dopo l’apertura della shell, controlla lo stato base:

docker version
docker info

Se questi comandi falliscono, il problema non è il tuo Dockerfile. È l’ambiente o la sessione. In un contesto temporaneo conviene ripartire da zero prima di perdere tempo in debug inutile.

Primo container: verifica che tutto giri davvero

Per un test rapido, usa un’immagine minimale e un comando evidente. L’obiettivo non è fare qualcosa di utile, ma controllare che la catena base sia sana: pull, run, log e cleanup.

docker run --rm hello-world

Se vedi il messaggio di benvenuto, hai conferma che il runtime funziona, che il download delle immagini è operativo e che la sessione ha accesso alla rete necessaria. Se invece il pull si blocca, il collo di bottiglia è quasi sempre connettività o disponibilità temporanea del servizio upstream.

Per una prova un po’ più concreta, avvia un web server e pubblica una porta:

docker run -d --name web -p 8080:80 nginx:alpine
curl -I http://localhost:8080

Con un output corretto, ti aspetti una risposta HTTP valida, tipicamente 200 OK o comunque un header coerente con il server. Se non risponde, controlla subito i log e lo stato del container:

docker ps
docker logs web

Networking tra container: la parte che chiarisce molti dubbi

Uno degli usi migliori di Play with Docker è vedere come i container si parlano sulla stessa rete. In locale spesso questi concetti vengono letti nei tutorial senza essere davvero osservati; qui puoi toccarli in pochi minuti.

Crea una rete dedicata e lancia due container che si vedono per nome:

docker network create labnet
docker run -d --name app --network labnet nginx:alpine
docker run --rm --network labnet curlimages/curl:8.5.0 http://app

Qui la verifica è semplice: il container di test deve risolvere app via DNS interno del bridge network e ottenere una risposta HTTP dal servizio Nginx. Se fallisce, i punti da controllare sono tre: rete assegnata, nome container e stato del servizio di destinazione.

Questo è il tipo di esercizio che chiarisce un errore comune: confondere il networking del container con quello dell’host. Dentro una rete Docker, il nome del container è spesso più utile di un IP, perché l’indirizzamento può cambiare e il DNS interno fa il resto.

Docker Compose online: utile, ma con disciplina

Se devi provare stack piccoli, Compose è il passaggio naturale. Non aspettarti un ambiente perfetto per tutto: in un contesto online temporaneo devi tenere il file essenziale, evitare dipendenze inutili e limitare i volumi ai casi in cui servono davvero.

Un esempio minimale con applicazione e database può essere questo:

services:
  web:
    image: nginx:alpine
    ports:
      - "8080:80"
  db:
    image: postgres:16-alpine
    environment:
      POSTGRES_PASSWORD: example

Prima di avviare, controlla sempre la sintassi e la coerenza del file:

docker compose config
docker compose up -d

Il comando docker compose config è il tuo filtro più economico: intercetta errori di indentazione, variabili mancanti e chiavi sbagliate prima di partire con un runtime che poi ti restituisce messaggi meno leggibili. In un ambiente temporaneo, ogni minuto risparmiato sul parsing vale doppio.

Persistenza: il limite pratico dell’ambiente gratuito

Qui sta il punto che spesso viene sottovalutato: la sessione non è pensata per durare. Se salvi qualcosa dentro il filesystem del nodo, devi assumere che possa sparire. Per questo il valore di PWD è didattico e operativo, non archivistico. Se ti serve persistenza vera, devi usare un volume esterno, un object storage o un host controllato da te.

Per capire fino a dove puoi spingerti, puoi provare un volume locale e vedere cosa resta attaccato al container durante la sessione:

docker volume create demo-data
docker run -d --name writer -v demo-data:/data alpine sh -c 'echo hello > /data/test.txt; sleep 3600'
docker exec writer cat /data/test.txt

Se il file è leggibile nel container, hai conferma che il volume funziona nel ciclo di vita della sessione. Ma non confondere questa persistenza locale con una retention affidabile nel tempo. Quando chiudi l’ambiente o scade la sessione, la continuità non è garantita.

Debug rapido: dove guardare quando qualcosa non torna

Il debug su PWD segue la stessa logica di un host normale, ma con una regola in più: prima distingui il problema del container da quello della sessione. Se il container non parte, guarda docker logs. Se il pull fallisce, verifica la rete. Se l’ambiente si comporta in modo incoerente, spesso conviene rigenerarlo.

Checklist veloce:

  • Controlla lo stato dei container con docker ps -a.
  • Leggi i log con docker logs <nome>.
  • Verifica le porte esposte con docker port <nome>.
  • Ispeziona rete e mount con docker inspect <nome>.
  • Se la sessione è instabile, riparti da un ambiente nuovo invece di inseguire sintomi intermittenti.

    • Un errore classico è pensare che l’assenza di output significhi applicazione ferma. In realtà molte immagini partono, eseguono il comando e terminano subito. Per distinguerle da un crash, confronta docker ps con docker ps -a: se il container esiste ma non è in running, il motivo è nel codice di uscita o nei log.

    Uso corretto dei file e delle immagini

    Su Play with Docker puoi caricare file, scrivere Dockerfile e costruire immagini, ma conviene mantenere il materiale leggero. Un Dockerfile ben fatto per questo contesto è corto, leggibile e con dipendenze minime. Esempio:

    FROM alpine:3.20
RUN apk add --no-cache curl
CMD ["sh", "-c", "while true; do date; sleep 5; done"]

    Costruisci e prova:

    docker build -t date-loop .
docker run --rm date-loop

    Qui stai verificando tre cose insieme: build context, esecuzione dell’immagine e comportamento del processo principale. Se il container esce subito, il problema spesso è nel CMD o nel comando shell. Se la build fallisce, il punto debole è quasi sempre il Dockerfile o la connettività verso i repository del sistema base.

    Limiti operativi da considerare prima di affidarti al servizio

    Ci sono limiti che è meglio accettare subito, invece di scoprirli nel momento sbagliato. L’ambiente è condiviso e temporaneo, quindi non va usato per segreti, dati sensibili o test che richiedono isolamento forte. Non caricare credenziali in chiaro, non usare token permanenti e non assumere che il reset sia un dettaglio secondario.

    Dal punto di vista operativo, tratta la sessione come un laboratorio pubblico: tutto ciò che metti dentro deve essere revocabile, rigenerabile o non sensibile. Se devi testare autenticazioni, usa segreti temporanei, redatti o con scadenza corta. Se devi dimostrare una pipeline, prepara un esempio minimale senza dati reali.

    Un flusso pratico da riusare ogni volta

    Se vuoi un approccio consistente, usa sempre la stessa sequenza: verifica runtime, prova un container semplice, testa rete, poi Compose. Questo evita il classico errore da laboratorio improvvisato, dove si apre un ambiente nuovo e si parte subito con uno stack complesso senza sapere se la base funziona.

  • Apri la sessione e lancia docker version.
  • Prova docker run --rm hello-world.
  • Avvia un servizio pubblicato su porta locale e verifica con curl -I.
  • Crea una rete dedicata e testa la risoluzione tra container.
  • Solo dopo, porta dentro Compose o un Dockerfile personalizzato.

    • Questo ordine riduce il rumore. Se qualcosa fallisce, sai dove intervenire senza aprire tre fronti di debug insieme. È una buona abitudine anche fuori da PWD, perché il metodo conta più dell’ambiente.

    Quando passare a un ambiente diverso

    Passa oltre Play with Docker quando ti serve continuità, auditing, integrazione con CI o risorse più stabili. Anche se il servizio è comodo, non sostituisce un host gestito per attività ripetitive, né un cluster per test di carico o orchestrazione. Il criterio è semplice: se il test deve sopravvivere alla chiusura della finestra del browser, non è il posto giusto.

    In sintesi, il valore di PWD sta nella velocità di accesso al runtime, non nella profondità dell’infrastruttura. È perfetto per imparare i fondamentali, fare prove rapide e mostrare scenari Docker senza installazioni locali. Se lo usi con questo perimetro in mente, ti evita attrito e ti fa risparmiare tempo. Se gli chiedi di essere un ambiente persistente, ti deluderà per definizione.