Knowledge Base Guide

Docker per PrestaShop: Configurazione ambiente di sviluppo

Configura Docker per lo sviluppo PrestaShop — test multi-versione, workflow moduli, gestione database, debug con Xdebug e considerazioni per la produzione.

Perché Docker per lo sviluppo PrestaShop?

Se avete mai provato a eseguire PrestaShop 1.6, 1.7, 8.x e 9.x sulla stessa macchina, conoscete bene il problema. Ogni versione richiede una diversa versione di PHP, una diversa versione di MySQL e una configurazione differente. Installare tutto nativamente è una ricetta sicura per ore di debugging.

Docker risolve questo problema. Ogni versione di PrestaShop viene eseguita nel proprio container isolato con esattamente le dipendenze di cui ha bisogno. Nessun conflitto. Nessun malfunzionamento.

  • Test multi-versione: Eseguite PS 1.7, 8.x e 9.x contemporaneamente. Testate un modulo su tutte le versioni in un solo pomeriggio.
  • Isolamento: Ogni container ha il proprio runtime PHP, il proprio database MySQL e il proprio file system.
  • Riproducibilità: L’intero ambiente è definito in un singolo file docker-compose.yml. Condividetelo con il vostro team e tutti otterranno una configurazione identica.
  • Pulizia semplice: Eseguite docker compose down -v e tutto viene rimosso. Ricreate l’ambiente da zero in due minuti.
Noi gestiamo oltre 25 container PrestaShop su un singolo server — da PS 1.6 fino a PS 9.1 — per lo sviluppo e il testing dei moduli. Docker è l’unico modo pratico per gestire tutto ciò. Questa guida condivide i pattern che abbiamo perfezionato nel corso di anni di utilizzo reale.

Prerequisiti

Installazione di Docker

Ubuntu/Debian: curl -fsSL https://get.docker.com | sh — poi sudo usermod -aG docker $USER per eseguire Docker senza sudo.

macOS: Scaricate Docker Desktop per Mac (supportati sia Intel che Apple Silicon).

Windows: Installate prima WSL2, poi Docker Desktop con il backend WSL2 abilitato.

Concetti chiave di Docker

  • Image: Un template di sola lettura contenente un sistema operativo, PHP, Apache e PrestaShop. Immagini ufficiali: prestashop/prestashop su Docker Hub.
  • Container: Un’istanza in esecuzione di un’immagine. Potete eseguire più container dalla stessa immagine.
  • Volume: Storage persistente che sopravvive ai riavvii del container. Senza volume, i dati vengono persi quando il container viene rimosso.
  • Network: Una rete virtuale che permette ai container di comunicare tra loro — PrestaShop ha bisogno di raggiungere il proprio container MySQL.

Requisiti hardware

Prevedete 1,5–2 GB di RAM per ogni istanza PrestaShop (applicazione + database). Per 2–3 versioni, 8 GB di RAM e un SSD sono sufficienti. Per 10+ container, sono consigliati 32 GB+ e SSD veloci.

Configurazione base: singolo container PrestaShop

Create una directory e aggiungete questo file docker-compose.yml:

version: '3.8'
services:
  prestashop:
    image: prestashop/prestashop:8.2
    container_name: my-ps-shop
    ports:
      - "8080:80"
    environment:
      - DB_SERVER=db
      - DB_USER=prestashop
      - DB_PASSWD=prestashop_password
      - DB_NAME=prestashop
      - PS_DOMAIN=localhost:8080
      - PS_FOLDER_ADMIN=admin-dev
      - PS_FOLDER_INSTALL=disabled
      - ADMIN_MAIL=admin@yourshop.com
      - ADMIN_PASSWD=admin_password_123
    volumes:
      - ps-data:/var/www/html
    depends_on:
      - db

  db:
    image: mysql:8.0
    container_name: my-ps-shop-db
    environment:
      - MYSQL_ROOT_PASSWORD=root_password
      - MYSQL_DATABASE=prestashop
      - MYSQL_USER=prestashop
      - MYSQL_PASSWORD=prestashop_password
    volumes:
      - db-data:/var/lib/mysql

volumes:
  ps-data:
  db-data:

DB_SERVER deve corrispondere al nome del servizio (db). PS_DOMAIN indica a PrestaShop dove è accessibile. PS_FOLDER_INSTALL=disabled salta il wizard di installazione ai riavvii successivi. Avviate con docker compose up -d e monitorate la prima installazione con docker compose logs -f prestashop (richiede 1-2 minuti).

Accedete al vostro negozio su http://localhost:8080 e al Back Office su http://localhost:8080/admin-dev.

Utilizzate sempre named volume per il vostro database. Senza volume, la rimozione di un container distrugge tutti i dati — prodotti, ordini, tutto. I named volume persistono finché non li eliminate esplicitamente.

Configurazione per test multi-versione

È qui che Docker dà il meglio di sé. Eseguire tre versioni di PrestaShop affiancate è semplicemente questione di definirle nel vostro file compose con porte diverse:

version: '3.8'
services:
  ps178:
    image: prestashop/prestashop:1.7.8
    ports: ["8081:80"]
    environment:
      - DB_SERVER=ps178-db
      - PS_DOMAIN=localhost:8081
      # ... stesso pattern di cui sopra
    volumes:
      - ps178-data:/var/www/html
    networks: [ps-network]

  ps178-db:
    image: mysql:5.7
    volumes: [ps178-db-data:/var/lib/mysql]
    networks: [ps-network]

  ps82:
    image: prestashop/prestashop:8.2
    ports: ["8082:80"]
    environment:
      - DB_SERVER=ps82-db
      - PS_DOMAIN=localhost:8082
    volumes:
      - ps82-data:/var/www/html
    networks: [ps-network]

  ps82-db:
    image: mysql:8.0
    command: --default-authentication-plugin=mysql_native_password
    volumes: [ps82-db-data:/var/lib/mysql]
    networks: [ps-network]

  ps9:
    image: prestashop/prestashop:9.0
    ports: ["8083:80"]
    environment:
      - DB_SERVER=ps9-db
      - PS_DOMAIN=localhost:8083
    volumes:
      - ps9-data:/var/www/html
    networks: [ps-network]

  ps9-db:
    image: mysql:8.0
    command: --default-authentication-plugin=mysql_native_password
    volumes: [ps9-db-data:/var/lib/mysql]
    networks: [ps-network]

networks:
  ps-network:
    driver: bridge

Scegliete uno schema di porte coerente: 8081 per PS 1.7, 8082 per PS 8.x, 8083 per PS 9.x. Per un’esperienza migliore, usate Nginx Proxy Manager per assegnare hostname come ps178.dev.local invece dei numeri di porta.

Utilizzate sempre database separati. Non condividete mai una singola istanza MySQL tra versioni diverse di PrestaShop — lo schema differisce tra le versioni e le migrazioni corromperebbero i dati.

Workflow di sviluppo moduli

Montate con bind-mount la directory del vostro modulo nel container, così ogni modifica è immediatamente disponibile:

volumes:
  - ps82-data:/var/www/html
  - /home/user/modules/my_module:/var/www/html/modules/my_module

Per testare su tutte le versioni, montate la stessa directory in ogni container. Modificate un file, aggiornate tre schede del browser — la vostra modifica è attiva ovunque.

Symlink vs Volume mount

Volume mount (consigliati): Le modifiche sono istantanee, funzionano su tutte le piattaforme, con una separazione pulita. Symlink: Funzionano solo se i file di PrestaShop sono sul filesystem dell’host, non funzionano bene con i Docker volume. Per la maggior parte delle configurazioni, i volume mount sono la scelta giusta.

Gestione della cache

PrestaShop utilizza una cache aggressiva per template e configurazioni. Durante lo sviluppo, svuotate la cache dopo le modifiche:

docker exec ps82 rm -rf /var/www/html/var/cache/*

Oppure disabilitate la cache dei template in Back Office → Advanced Parameters → Performance durante lo sviluppo attivo. Riattivatela quando i test sono completati — i bug legati alla cache sono reali.

Gestione del database

Connessione a MySQL

# Sessione interattiva MySQL
docker exec -it ps82-db mysql -u root -p'root' prestashop

# Esecuzione di una singola query
docker exec ps82-db mysql -u root -p'root' -e "SELECT COUNT(*) FROM ps_product;" prestashop

Container phpMyAdmin

  phpmyadmin:
    image: phpmyadmin:latest
    ports: ["9090:80"]
    environment:
      - PMA_HOSTS=ps178-db,ps82-db,ps9-db
      - PMA_USER=root
      - PMA_PASSWORD=root
    networks: [ps-network]

Import ed export

# Export
docker exec ps82-db mysqldump -u root -p'root' prestashop > backup.sql

# Import
docker exec -i ps82-db mysql -u root -p'root' prestashop < backup.sql

Persistente vs effimero

Persistente (named volume): I dati sopravvivono ai riavvii — da usare per gli ambienti di sviluppo principali. Effimero (senza volume): Installazione pulita ogni volta — utile per test del tipo “questo modulo si installa correttamente su un negozio vuoto?”.

Test delle email con Mailpit

Mailpit intercetta tutte le email in uscita e le visualizza in un’interfaccia web — essenziale per testare i flussi di checkout senza inviare email reali.

  mailpit:
    image: axllent/mailpit
    ports:
      - "8025:8025"  # Web UI
      - "1025:1025"  # SMTP
    networks: [ps-network]

Nel Back Office di PrestaShop → Advanced Parameters → E-mail: impostate il server SMTP su mailpit, porta 1025, nessuna crittografia, nessuna autenticazione. Visualizzate le email intercettate su http://localhost:8025.

Debugging con Xdebug

Configurazione di Xdebug 3

Create un Dockerfile personalizzato:

FROM prestashop/prestashop:8.2
RUN pecl install xdebug && docker-php-ext-enable xdebug
COPY xdebug.ini /usr/local/etc/php/conf.d/docker-php-ext-xdebug.ini

Il file xdebug.ini:

[xdebug]
xdebug.mode=debug
xdebug.start_with_request=yes
xdebug.client_host=host.docker.internal
xdebug.client_port=9003
xdebug.idekey=VSCODE

Su Linux, aggiungete extra_hosts: ["host.docker.internal:host-gateway"] al vostro servizio compose — host.docker.internal non esiste di default su Linux.

Configurazione di VS Code

Installate l’estensione PHP Debug e aggiungete al file .vscode/launch.json:

{
  "version": "0.2.0",
  "configurations": [{
    "name": "Listen for Xdebug (Docker)",
    "type": "php",
    "request": "launch",
    "port": 9003,
    "pathMappings": {
      "/var/www/html/modules/my_module": "${workspaceFolder}"
    }
  }]
}

I pathMappings sono fondamentali — indicano a VS Code come i percorsi del container corrispondono ai percorsi locali. Senza di essi, i breakpoint non si attiveranno.

PHPStorm

Settings → PHP → Servers: aggiungete un server con localhost e la porta del vostro container, mappando /var/www/html al vostro progetto locale. Impostate la porta Xdebug a 9003 sotto PHP → Debug e fate clic su “Start Listening”.

Comandi Docker utili

OperazioneComando
Avviare tutti i containerdocker compose up -d
Fermare tutti i containerdocker compose down
Fermare e cancellare tutti i datidocker compose down -v
Visualizzare i logdocker compose logs -f
Svuotare la cache PSdocker exec CONTAINER rm -rf /var/www/html/var/cache/*
CLI MySQLdocker exec -it CONTAINER-db mysql -u root -p'PASS' prestashop
Esportare il databasedocker exec CONTAINER-db mysqldump -u root -p'PASS' prestashop > backup.sql
Importare il databasedocker exec -i CONTAINER-db mysql -u root -p'PASS' prestashop < backup.sql
Shell nel containerdocker exec -it CONTAINER bash
Controllare l’uso delle risorsedocker stats --no-stream
Ricostruire dopo modifiche al Dockerfiledocker compose up -d --build
Eseguire la console PrestaShopdocker exec CONTAINER php bin/console cache:clear --env=prod
Eseguire Composer nel modulodocker exec -w /var/www/html/modules/my_module CONTAINER composer install

Considerazioni per la produzione

Per la maggior parte dei negozi PrestaShop, Docker è uno strumento di sviluppo. I negozi in produzione funzionano meglio su hosting tradizionale perché:

  • Un singolo stack LAMP su un server è più semplice da mantenere e monitorare
  • L’I/O nativo dei file è più veloce rispetto ai Docker volume (PrestaShop carica migliaia di file PHP per ogni richiesta)
  • La maggior parte degli hosting PrestaShop fornisce cPanel/Plesk, non Docker

Docker in produzione ha senso quando: avete un grande team di sviluppo con pipeline CI/CD, avete bisogno di auto-scaling durante gli eventi di vendita, gestite 10+ negozi, o necessitàte di deployment senza downtime (costruite una nuova immagine, sostituitela, effettuate il rollback in caso di problemi).

Docker Compose vs Kubernetes: Compose gestisce fino a 20–30 container su un singolo server ed è semplice da amministrare. Kubernetes aggiunge auto-scaling, self-healing e orchestrazione multi-nodo, ma richiede un’infrastruttura significativa. Per la maggior parte dei deployment PrestaShop, Compose su un server potente è sufficiente.

Problemi comuni e soluzioni

Problemi di permessi sui file

Sintomo: Errori “Permission denied”, impossibilità di caricare moduli o salvare immagini.

Causa: Apache viene eseguito come www-data (UID 33) all’interno del container, ma i file montati dall’host potrebbero appartenere al vostro utente (UID 1000).

docker exec my-ps-shop chown -R www-data:www-data /var/www/html/var
docker exec my-ps-shop chown -R www-data:www-data /var/www/html/img
docker exec my-ps-shop chown -R www-data:www-data /var/www/html/modules

Il container non riesce a connettersi al database

  • DB_SERVER deve corrispondere esattamente al nome del servizio MySQL nel vostro file compose
  • MySQL potrebbe non essere ancora pronto — aggiungete un healthcheck e utilizzate depends_on: condition: service_healthy
  • Entrambi i container devono trovarsi sulla stessa rete Docker
  • MySQL 8.0 utilizza caching_sha2_password di default — aggiungete command: --default-authentication-plugin=mysql_native_password al servizio MySQL

I/O lento dei file su macOS

Sintomo: Le pagine impiegano 10–30 secondi per caricarsi con i bind mount.

Soluzioni:

  • VirtioFS: Passate da gRPC FUSE a VirtioFS nelle impostazioni di Docker Desktop — il singolo miglioramento più significativo
  • Montate meno: Montate solo la directory del vostro modulo, usate named volume per il core di PrestaShop
  • Mutagen: Sincronizzazione bidirezionale veloce dei file che elimina la penalità prestazionale di macOS

SSL in ambiente di sviluppo

I moduli di pagamento e il social login spesso richiedono HTTPS. Opzioni:

  • Nginx Proxy Manager: Gestisce la terminazione SSL per tutti i container. L’approccio più pulito.
  • mkcert: Generate certificati attendibili localmente con mkcert localhost e montateli in Apache.
  • Traefik: Rileva automaticamente i container e genera i certificati.

Il container esaurisce la memoria

MySQL 8.0 è avido di memoria di default. Limitatelo:

command: >
  --innodb-buffer-pool-size=128M
  --max-connections=50

Su Docker Desktop (macOS/Windows), aumentate il limite di memoria globale in Settings → Resources ad almeno 6 GB per 3+ container. Fermate i container che non state utilizzando attivamente: docker compose stop ps178.

Loop di auto-installazione

Se PrestaShop si reinstalla ad ogni riavvio, assicuratevi che il volume /var/www/html sia persistente e che PS_FOLDER_INSTALL=disabled sia impostato nel vostro environment.

Contenuti misti dopo il cambio di porta

Aggiornate il dominio nel database quando modificate il mapping delle porte:

docker exec ps82-db mysql -u root -p'root' -e "
  UPDATE ps_configuration SET value='localhost:8082'
    WHERE name IN ('PS_SHOP_DOMAIN','PS_SHOP_DOMAIN_SSL');
  UPDATE ps_shop_url SET domain='localhost:8082', domain_ssl='localhost:8082';
" prestashop

Riepilogo

Docker trasforma lo sviluppo PrestaShop da un’esperienza fragile e limitata a una singola versione in un workflow riproducibile e multi-versione. La configurazione iniziale richiede un pomeriggio. Dopo di che, potete avviare qualsiasi versione di PrestaShop in pochi minuti, testare i moduli su tutte le versioni supportate contemporaneamente e condividere il vostro ambiente esatto con il team.

Iniziate con la configurazione base a singolo container. Una volta acquisita dimestichezza, aggiungete altre versioni, phpMyAdmin, Mailpit e Xdebug. I file compose presenti in questa guida sono pattern testati in produzione dalla nostra stessa infrastruttura. Copiateli, adattateli e costruite su di essi.

Il repository Docker di PrestaShop su GitHub è un’eccellente risorsa per restare aggiornati sugli update delle immagini ufficiali e sulle best practice.

More guides available

Browse our knowledge base for more practical PrestaShop tutorials, or reach out if you need help.

Loading...
Back to top