Automatización de despliegues PrestaShop con Docker y CI/CD
¡Excelente! Como redactor técnico experto en SysAdmin y SEO, he preparado un artículo completo para ti. Aquí tienes el contenido en Markdown puro, listo para publicar.
Introducción: El desafío del despliegue en PrestaShop
Gestionar una tienda online con PrestaShop en entornos de producción implica mucho más que subir archivos por FTP. Cada actualización de módulos, parches de seguridad o cambios en la configuración puede convertirse en una pesadilla si no se cuenta con un proceso robusto y repetible. La combinación de contenedores con Docker PrestaShop y una tubería de CI/CD ecommerce no solo resuelve estos dolores de cabeza, sino que transforma la operativa.
Este artículo está diseñado para administradores de sistemas y desarrolladores que buscan un despliegue automatizado PrestaShop. Abordaremos desde la estructura de contenedores hasta la implementación de un pipeline completo con GitHub Actions, pasando por buenas prácticas de seguridad y escalabilidad.
¿Por qué Dockerizar PrestaShop?
Antes de escribir código, es crucial entender los beneficios concretos de la contenedorización para una plataforma como PrestaShop.
Entornos consistentes y reproducibles
El clásico “en mi máquina funciona” se elimina por completo. Con Docker, el entorno de desarrollo, staging y producción es idéntico. Esto incluye la versión de PHP, las extensiones (como bcmath, gd, intl), el servidor web (Apache o Nginx) y la base de datos.
Aislamiento y escalabilidad
Cada componente de tu tienda (aplicación, base de datos, caché, colas) corre en su propio contenedor. Esto facilita el escalado horizontal. Si tu tienda recibe un pico de tráfico por Black Friday, puedes lanzar más instancias del contenedor web sin afectar a la base de datos.
Facilidad de actualización y rollback
Actualizar PrestaShop o un módulo se reduce a cambiar la imagen de Docker y desplegar una nueva versión del contenedor. Si algo sale mal, el rollback es inmediato: solo hay que volver a la imagen anterior.
Estructura del proyecto con Docker Compose
La base de nuestro despliegue automatizado PrestaShop es un archivo docker-compose.yml bien definido. Vamos a construir uno que incluya los servicios esenciales.
version: '3.8'
services:
db:
image: mysql:8.0
container_name: prestashop_db
restart: always
environment:
MYSQL_ROOT_PASSWORD: ${MYSQL_ROOT_PASSWORD}
MYSQL_DATABASE: prestashop
MYSQL_USER: prestashop_user
MYSQL_PASSWORD: ${MYSQL_USER_PASSWORD}
volumes:
- db_data:/var/lib/mysql
networks:
- prestashop_network
prestashop:
image: prestashop/prestashop:8.2
container_name: prestashop_app
restart: always
depends_on:
- db
ports:
- "8080:80"
environment:
DB_SERVER: db
DB_NAME: prestashop
DB_USER: prestashop_user
DB_PASSWD: ${MYSQL_USER_PASSWORD}
PS_INSTALL_AUTO: 0 # Deshabilitamos instalación automática para producción
volumes:
- ./themes:/var/www/html/themes
- ./modules:/var/www/html/modules
- ./override:/var/www/html/override
- ./img:/var/www/html/img
- ./config:/var/www/html/config
networks:
- prestashop_network
phpmyadmin:
image: phpmyadmin/phpmyadmin
container_name: prestashop_pma
restart: always
depends_on:
- db
ports:
- "8081:80"
environment:
PMA_HOST: db
networks:
- prestashop_network
volumes:
db_data:
networks:
prestashop_network:
driver: bridge
[TIP] Utiliza variables de entorno (.env) para gestionar contraseñas y configuraciones sensibles. Nunca hardcodees credenciales en el archivo docker-compose.yml.
Explicación de los volúmenes
Para que un CI/CD ecommerce funcione correctamente, es vital separar el código de la aplicación (imagen) de los datos personalizables (temas, módulos, imágenes). Los volúmenes montados permiten:
- Actualizar la imagen base sin perder los temas personalizados.
- Versionar los directorios
themes,modulesyoverrideen tu repositorio Git. - Persistir la base de datos en un volumen Docker separado.
El Pipeline CI/CD: De Git a Producción
Ahora que tenemos nuestra infraestructura definida, vamos a construir el pipeline que automatizará las pruebas y el despliegue. Usaremos GitHub Actions como ejemplo, pero el concepto es aplicable a GitLab CI, Jenkins o cualquier otra herramienta.
Fase 1: Integración Continua (CI)
El objetivo es asegurar que cada push a la rama develop o main no rompa nada.
name: CI Pipeline PrestaShop
on:
push:
branches: [ develop, main ]
pull_request:
branches: [ main ]
jobs:
test:
runs-on: ubuntu-latest
services:
mysql:
image: mysql:8.0
env:
MYSQL_ROOT_PASSWORD: test_root
MYSQL_DATABASE: prestashop_test
MYSQL_USER: test_user
MYSQL_PASSWORD: test_pass
ports:
- 3306:3306
options: --health-cmd="mysqladmin ping" --health-interval=10s --health-timeout=5s --health-retries=5
steps:
- uses: actions/checkout@v4
- name: Set up PHP
uses: shivammathur/setup-php@v2
with:
php-version: '8.1'
extensions: mbstring, pdo, mysql, gd, curl, intl
tools: composer:v2
- name: Install dependencies
run: composer install --no-interaction --prefer-dist
- name: Run PHP CodeSniffer
run: |
vendor/bin/phpcs --standard=PSR12 modules/ themes/
- name: Run unit tests (si existieran)
run: |
# Aquí irían tus tests unitarios específicos del módulo
echo "Tests unitarios ejecutados correctamente."
[INFO] Este pipeline asume que tienes módulos o temas con código PHP que debe ser validado. Si solo despliegas la tienda base, puedes omitir los tests de código y centrarte en la integridad de la configuración.
Fase 2: Construcción de la Imagen Docker
Una vez superados los tests, construimos una imagen personalizada que incluye nuestro tema y módulos. Esto es clave para un despliegue automatizado PrestaShop eficiente.
# Dockerfile.prod
FROM prestashop/prestashop:8.2-apache
# Copiamos nuestros archivos personalizados
COPY ./themes /var/www/html/themes
COPY ./modules /var/www/html/modules
COPY ./override /var/www/html/override
COPY ./img /var/www/html/img
# Configuraciones adicionales (php.ini, etc.)
COPY ./config/php.ini /usr/local/etc/php/conf.d/prestashop.ini
# Ajustamos permisos (importante para que PrestaShop pueda escribir)
RUN chown -R www-data:www-data /var/www/html && \
chmod -R 755 /var/www/html
EXPOSE 80
[WARNING] No copies todo el directorio var/www/html de tu instalación local. Solo los directorios que contienen personalizaciones. La imagen base ya tiene el núcleo de PrestaShop.
Añadimos el paso de build en el pipeline:
build:
needs: test
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Log in to Docker Hub
uses: docker/login-action@v3
with:
username: ${{ secrets.DOCKER_USERNAME }}
password: ${{ secrets.DOCKER_PASSWORD }}
- name: Build and push Docker image
uses: docker/build-push-action@v5
with:
context: .
file: ./Dockerfile.prod
push: true
tags: |
${{ secrets.DOCKER_USERNAME }}/prestashop-custom:${{ github.sha }}
${{ secrets.DOCKER_USERNAME }}/prestashop-custom:latest
Fase 3: Despliegue Continuo (CD)
Finalmente, desplegamos la nueva imagen en nuestro servidor de producción. Aquí tienes dos enfoques comunes:
Opción A: Despliegue con SSH y Docker Compose
deploy:
needs: build
runs-on: ubuntu-latest
steps:
- name: Deploy via SSH
uses: appleboy/ssh-action@v1.0.0
with:
host: ${{ secrets.SERVER_HOST }}
username: ${{ secrets.SERVER_USER }}
key: ${{ secrets.SSH_PRIVATE_KEY }}
script: |
cd /path/to/your/prestashop-deployment
docker pull ${{ secrets.DOCKER_USERNAME }}/prestashop-custom:${{ github.sha }}
docker compose down
export TAG=${{ github.sha }}
docker compose up -d
docker image prune -f
Opción B: Despliegue con Docker Swarm o Kubernetes
Para entornos de alta disponibilidad, puedes usar orquestadores. Un ejemplo simplificado con Docker Swarm:
deploy-swarm:
needs: build
runs-on: ubuntu-latest
steps:
- name: Deploy to Swarm
uses: docker/compose-swarm-deploy-action@v1
with:
stack-name: prestashop
compose-file: docker-compose.prod.yml
env-file: .env.production
# La imagen ya está en el registro, solo se actualiza el servicio
Buenas prácticas y consideraciones de seguridad
Implementar un CI/CD ecommerce no solo es cuestión de automatización, sino también de robustez.
Gestión de secretos
Nunca expongas contraseñas, claves de API o tokens en el código. Utiliza los secretos de tu plataforma de CI (GitHub Secrets, GitLab CI Variables) y pásalos como variables de entorno en tiempo de ejecución.
Estrategia de backups
Antes de cualquier despliegue automatizado, asegúrate de tener un backup reciente de la base de datos y los archivos de la tienda. Puedes añadir un paso en el pipeline que realice un dump de MySQL antes de actualizar.
docker exec prestashop_db mysqldump -u root -p$MYSQL_ROOT_PASSWORD prestashop > backup_$(date +%Y%m%d_%H%M%S).sql
Pruebas de humo post-despliegue
Incluye un paso que verifique que la tienda responde correctamente después del despliegue. Por ejemplo, hacer una petición HTTP a la URL de la tienda y comprobar que devuelve un código 200.
- name: Smoke test
run: |
sleep 30 # Tiempo para que el contenedor arranque
curl -f -s -o /dev/null https://tudominio.com/
Gestión de la caché
PrestaShop utiliza cachés internas (Smarty, Doctrine). Después de un despliegue, es recomendable limpiarlas. Puedes hacerlo vía consola dentro del contenedor:
docker exec prestashop_app php bin/console prestashop:cache:clear --env=prod
Conclusión
La automatización de despliegues PrestaShop con Docker y CI/CD es una inversión que se amortiza rápidamente. Reduce el error humano, acelera las entregas de nuevas funcionalidades y proporciona un historial claro de cada cambio en tu tienda.
Hemos visto cómo estructurar un proyecto con Docker PrestaShop, definir un pipeline de integración y despliegue continuo, y aplicar buenas prácticas de seguridad y mantenimiento. El siguiente paso es adaptar estos conceptos a tu flujo de trabajo real y empezar a cosechar los beneficios de una operativa moderna y eficiente.
[TIP] Empieza por un entorno de staging. Automatiza el despliegue en un servidor de pruebas y, una vez que tengas confianza en el proceso, extiéndelo a producción. La clave es iterar y mejorar continuamente.
¿Listo para transformar tu gestión de ecommerce? El futuro del despliegue automatizado PrestaShop ya está aquí.
