En este artículo, exploraremos las mejores prácticas para implementar IaC con Pulumi, con ejemplos prácticos en GCP, AWS y DigitalOcean, estrategias avanzadas para Kubernetes y consideraciones clave en Disaster Recovery Planning (DRP).

1. ¿Por qué Pulumi para IaC?

Pulumi ofrece ventajas únicas frente a alternativas como Terraform o CloudFormation:

✅ Lenguajes familiares (Python, TypeScript, Go) en lugar de DSLs propietarios.
✅ Soporte multi-cloud (AWS, GCP, Azure, DigitalOcean, Kubernetes).
✅ Estado de infraestructura gestionado (Pulumi Service, S3, etc.).
✅ Integración con CI/CD nativa.
✅ Reutilización de código mediante componentes y librerías.

Ejemplo: Desplegando un cluster Kubernetes en DigitalOcean con Pulumi (Python)

import pulumi
import pulumi_digitalocean as do
# Crear un cluster Kubernetes en DigitalOcean
cluster = do.KubernetesCluster(
    "saas-cluster",
    region="nyc1",
    version="1.25.4-do.0",
    node_pool={
        "name": "default-pool",
        "size": "s-2vcpu-4gb",
        "node_count": 3,
    }
)
# Exportar el kubeconfig
pulumi.export("kubeconfig", cluster.kube_configs[0].raw_config)

Este código despliega un cluster gestionado en DigitalOcean con tres nodos, listo para integrarse en un pipeline de CI/CD.

2. Mejores Prácticas para IaC con Pulumi

🔹 Modularización y Reutilización

Evitar scripts monolíticos. En su lugar, estructurar el código en componentes reutilizables:

# Ejemplo: Módulo para un bucket S3 con políticas de acceso
class SecureBucket(pulumi.ComponentResource):
    def __init__(self, name, **kwargs):
        super().__init__("custom:SecureBucket", name, **kwargs)
        
        self.bucket = aws.s3.Bucket(name)
        aws.s3.BucketPolicy(
            f"{name}-policy",
            bucket=self.bucket.id,
            policy=json.dumps({
                "Version": "2012-10-17",
                "Statement": [{
                    "Effect": "Deny",
                    "Principal": "*",
                    "Action": "s3:*",
                    "Resource": [self.bucket.arn, f"{self.bucket.arn}/*"],
                    "Condition": {"Bool": {"aws:SecureTransport": False}}
                }]
            })
        )
# Uso del módulo
bucket = SecureBucket("prod-data-lake")

🔹 Gestión de Estado (State Management)

Pulumi guarda el estado de la infraestructura. Opciones recomendadas:

• Pulumi Service (gratis para proyectos pequeños).

• Amazon S3 / Google Cloud Storage (para mayor control).

# Inicializar un proyecto con backend en S3
pulumi login s3://my-pulumi-state-bucket

🔹 CI/CD Integrado

Ejemplo con GitHub Actions:

name: Deploy Infrastructure
on:
  push:
    branches: [main]
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - uses: pulumi/actions@v3
        with:
          command: up
          stack-name: prod
        env:
          PULUMI_ACCESS_TOKEN: ${{ secrets.PULUMI_ACCESS_TOKEN }}

3. Kubernetes con Pulumi: Gestión Eficiente

Pulumi permite gestionar Kubernetes de forma declarativa sin necesidad de kubectl manual.

Ejemplo: Despliegue de una App en Kubernetes

import pulumi_kubernetes as k8s
# Crear un Namespace
app_ns = k8s.core.v1.Namespace("app-ns")
# Desplegar una aplicación
app = k8s.apps.v1.Deployment(
    "app-deployment",
    metadata={"namespace": app_ns.metadata["name"]},
    spec={
        "replicas": 3,
        "selector": {"match_labels": {"app": "my-saas"}},
        "template": {
            "metadata": {"labels": {"app": "my-saas"}},
            "spec": {
                "containers": [{
                    "name": "app",
                    "image": "my-registry/my-saas-app:latest",
                    "ports": [{"container_port": 8080}]
                }]
            }
        }
    }
)
# Exponer el servicio
service = k8s.core.v1.Service(
    "app-service",
    metadata={"namespace": app_ns.metadata["name"]},
    spec={
        "selector": {"app": "my-saas"},
        "ports": [{"port": 80, "target_port": 8080}],
        "type": "LoadBalancer"
    }
)
pulumi.export("service_url", service.status["load_balancer"]["ingress"][0]["hostname"])

4. Disaster Recovery Planning (DRP) con Pulumi

Un buen DRP define RTO (Recovery Time Objective) y RPO (Recovery Point Objective).

Visualización de RTO/RPO

(Imagen conceptual: Tabla comparando estrategias de backup y replicación)

Ejemplo: Configuración de DRP en AWS

import pulumi_aws as aws
# Replicación de buckets S3 entre regiones
primary_bucket = aws.s3.Bucket("primary-bucket", acl="private")
replica_bucket = aws.s3.Bucket("replica-bucket", acl="private")
aws.s3.BucketReplication(
    "replication",
    bucket=primary_bucket.id,
    role=replication_role.arn,
    rules=[{
        "status": "Enabled",
        "destination": {
            "bucket": replica_bucket.arn,
            "storage_class": "STANDARD"
        }
    }]
)

5. Conclusión

Pulumi es una herramienta poderosa para automatizar infraestructura cloud con código real, mejorando la productividad de equipos DevOps y startups SaaS.

🔹 Mejores prácticas clave:

• Modularizar el código IaC.

• Gestionar el estado de forma segura.

• Integrar con CI/CD.

• Planificar Disaster Recovery (RTO/RPO).

¿Listo para probar Pulumi? Comienza con su documentación oficial.

📢 ¿Quieres más detalles sobre algún tema? ¡Contactame!

#DevOps #InfrastructureAsCode #Pulumi #Kubernetes #CloudComputing #SaaS #DisasterRecovery

El 1 de junio de 2025, durante las elecciones judiciales en México, mi equipo fue responsable de una misión crítica: garantizar la descarga, validación y publicación automatizada de resultados electorales provenientes del INE (Instituto Nacional Electoral). Este flujo de datos tenía que funcionar 24/7, con una frecuencia de actualización de cada 5 minutos, y con máxima seguridad y tolerancia a fallos.

Operamos bajo un entorno regulado y expuesto mediáticamente, donde cualquier retraso, inconsistencia o vulnerabilidad sería inaceptable. Para esto, diseñamos una solución de automatización sobre Kubernetes, combinando scripting en Bash, tokens de autenticación y firmas criptográficas GPG. Aquí les comparto cómo lo hicimos.

2. Desafíos Técnicos

• Alta disponibilidad: La solución debía ejecutarse cada 5 minutos, sin interrupciones, durante toda la jornada electoral.

• Seguridad de datos: Era indispensable garantizar la autenticidad y no-repudio de los datos publicados.

• Tolerancia a errores: El sistema debía manejar fallos parciales en servicios externos sin detener la operación general.

• Infraestructura controlada: El ambiente se desplegó sobre clústeres Kubernetes autoescalables con nodos específicos para tareas cron.

3. Solución Implementada

Decidimos implementar un cron job especializado en Kubernetes, responsable de:

1. Autenticarse con un sistema remoto mediante un API Token.

2. Recuperar el archivo de los resultados.

3. Verificar y validar digitalmente los datos recibidos usando GPG.

4. Publicar los datos procesados en uno micrositio (con backup inmediato).

4. Detalles de Implementación Técnica

Archivo YAML del CronJob en Kubernetes:

apiVersion: batch/v1
kind: CronJob
metadata:
  name: resultados-electorales
spec:
  schedule: "*/5 * * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: recolector
            image: myregistry.com/electoral-job:latest
            imagePullPolicy: Always
            env:
            - name: API_TOKEN
              valueFrom:
                secretKeyRef:
                  name: electoral-secrets
                  key: api-token
            volumeMounts:
            - name: gpg-keys
              mountPath: /gpg
            command: ["/bin/sh"]
            args: ["-c", "/scripts/monitor.sh"]
          restartPolicy: OnFailure
          volumes:
          - name: gpg-keys
            secret:
              secretName: gpg-secret

El job se ejecuta cada 5 minutos utilizando una imagen liviana basada en Alpine, con herramientas mínimas necesarias, reforzada para evitar accesos no autorizados.

Mecanismo de seguridad adicional:

• Las claves GPG se inyectan como secreto de Kubernetes.

• Las salidas del script se redirigen a logs centralizados para auditoría.

• Las fallas se notifican vía webhook a un canal Slack monitoreado en tiempo real.

5. Resultados y Aprendizajes

• 🕔 100% de uptime durante más de 24 horas continuas.

• 🔐 0 incidentes de seguridad, gracias al control estricto de accesos y firmas.

• 📉 Carga minimizada gracias a imágenes optimizadas y nodos taintados solo para procesamiento.

• 🔁 Escalabilidad futura lista: el diseño permite extender el flujo a múltiples fuentes de datos judiciales o comiciales.

Este tipo de soluciones no solo demandan experiencia técnica, sino criterio operativo y sentido de urgencia. Lo que está en juego es la confianza pública y la responsabilidad institucional.

🚨 ¿Necesitas diseñar soluciones críticas como esta?

Si estás enfrentando un proyecto sensible en medios, gobierno o datos públicos, y necesitas:

• Consultoría para despliegues en Kubernetes

• Implementación de cron jobs confiables

• Diseño de infraestructura segura y autoescalable

📩 Contáctame para una sesión gratuita de diagnóstico técnico.
Haz que tu próxima implementación funcione como un reloj suizo, incluso bajo presión electoral.

En el mundo del desarrollo de software, la implementación de una pipeline de CI/CD robusta y eficiente es fundamental para mantener la agilidad y calidad del producto. Como desarrollador, me he enfrentado al reto de automatizar el despliegue de artefactos Java en múltiples entornos. En este artículo, compartiré mi experiencia implementando pipelines con Google Cloud Build, scripts Bash y el repositorio de artefactos Archiva para gestionar despliegues en máquinas virtuales.

El problema inicial

Antes de implementar nuestra solución automatizada, nos enfrentábamos a varios desafíos:

• Despliegues manuales propensos a errores
• Falta de consistencia entre entornos
• Tiempos de entrega prolongados
• Dificultad para rastrear qué versión estaba desplegada en cada entorno
• Complejidad para gestionar dependencias y artefactos Java

Necesitábamos una solución que pudiera gestionar el ciclo completo: desde la compilación del código fuente hasta el despliegue en nuestras máquinas virtuales, manteniendo un registro central de los artefactos generados.

Componentes de la solución

Google Cloud Build

Elegimos Cloud Build como el motor principal de nuestra pipeline de CI/CD por varias razones:

• Integración nativa con Google Cloud Platform
• Escalabilidad automática según las necesidades
• Facilidad para definir pasos de construcción mediante archivos YAML
• Capacidad para utilizar imágenes Docker personalizadas
• API robusta para la integración con otros servicios

SonarQube

Implementamos SonarQube como parte esencial de nuestra pipeline para garantizar la calidad del código:

• Análisis estático para detectar bugs y vulnerabilidades
• Medición de cobertura de pruebas
• Evaluación continua de la deuda técnica
• Verificación del cumplimiento de estándares de codificación
• Integración perfecta con el flujo de CI/CD

Apache Archiva

Para la gestión de artefactos, implementamos Apache Archiva, un repositorio de artefactos que nos permitió:

• Almacenar y versionar nuestros JAR, WAR y otros artefactos Java
• Gestionar dependencias de manera centralizada
• Establecer políticas de retención de artefactos
• Controlar el acceso a los diferentes repositorios
• Rastrear metadatos de los artefactos

Scripts Bash

El pegamento que unía todo nuestro sistema eran los scripts Bash, que nos proporcionaron:

• Flexibilidad para adaptarnos a casos específicos
• Capacidad para interactuar con APIs y servicios externos
• Manejo de errores y reintentos personalizados
• Despliegue en máquinas virtuales mediante SSH

Arquitectura de la pipeline

Nuestra pipeline de CI/CD sigue este proceso:

1. Trigger: Un push a una rama específica o la creación de una tag desencadena la pipeline
2. Build: Cloud Build compila el código Java utilizando Maven o Gradle
3. Test: Se ejecutan pruebas unitarias e integración
4. Análisis de calidad: SonarQube realiza un análisis estático y evaluación de calidad del código
5. Empaquetado: Se generan los artefactos (JAR, WAR)
6. Publicación: Los artefactos se suben a Apache Archiva
7. Despliegue: Scripts Bash se conectan por SSH a las VMs y despliegan los artefactos

Implementación estratégica

La implementación de nuestra pipeline requirió un enfoque meticuloso para integrar correctamente todos los componentes. La configuración de Cloud Build con los pasos adecuados fue fundamental, así como la integración de SonarQube para garantizar que solo el código que cumpliera con los estándares de calidad pudiera pasar a producción.

Desarrollamos scripts personalizados para manejar la comunicación entre los diferentes sistemas y establecimos puertas de calidad (quality gates) en cada etapa del proceso. El diseño modular nos permitió tener un sistema fácilmente adaptable a diferentes proyectos y entornos.

La integración entre SonarQube, Archiva y nuestros scripts de despliegue fue uno de los aspectos más desafiantes, pero también uno de los más gratificantes una vez implementado correctamente. Cada componente tenía un papel bien definido en la cadena de CI/CD, lo que permitía identificar rápidamente cualquier problema y solucionarlo sin afectar al resto del sistema.

Configuración de SonarQube

La integración de SonarQube fue crucial para mantener la calidad del código:

1. Establecimos Quality Gates con umbrales estrictos:
   • Cobertura de código mínima del 80%
   • Cero vulnerabilidades críticas
   • Menos de 5% de código duplicado
2. Configuramos reglas personalizadas según los estándares de nuestra organización
3. Implementamos webhooks para notificar al equipo sobre problemas detectados
4. Integramos los resultados del análisis como un paso bloqueante en nuestra pipeline

Configuración de Archiva

Para Archiva, creamos un repositorio interno y configuramos las políticas de seguridad:

1. Creamos usuarios específicos para despliegue con permisos limitados
2. Configuramos la retención de snapshots y releases
3. Establecimos políticas de proxy para dependencias externas
4. Configuramos índices para búsquedas eficientes

Lecciones aprendidas

Durante la implementación de esta solución, aprendí varias lecciones valiosas:

Calidad como prioridad

La integración de SonarQube desde el principio nos ahorró innumerables horas de depuración y problemas en producción:

• El análisis continuo permite detectar problemas temprano en el ciclo de desarrollo
• Los desarrolladores mejoraron sus prácticas al recibir retroalimentación inmediata
• La visualización de métricas de calidad motivó al equipo a mejorar constantemente

Gestión de secretos

Implementamos un sistema robusto para la gestión de credenciales:

• Secretos almacenados en Secret Manager de GCP
• Variables de entorno seguras en Cloud Build
• Cuentas de servicio con privilegios mínimos

Tolerancia a fallos

Los despliegues a veces fallaban por problemas de red o recursos. Mejoramos la resiliencia con:

• Reintentos automáticos con backoff exponencial
• Validaciones de estado tras el despliegue
• Capacidad de rollback automático

Paralelización

Para reducir los tiempos de despliegue en entornos con muchas VMs, implementamos:

• Despliegues paralelos con control de concurrencia
• Caché de artefactos entre pasos de la pipeline
• Optimización de la compilación con compilación incremental

Resultados

La implementación de esta pipeline nos proporcionó beneficios significativos:

• Reducción del tiempo de despliegue: de 45 minutos a menos de 5 minutos
• Eliminación de errores humanos: gracias a la automatización completa
• Mejora en la calidad del código: las métricas de SonarQube mostraron una reducción del 40% en la deuda técnica
• Mayor trazabilidad: registro completo de qué versión está en cada entorno
• Mejora de la colaboración: el equipo puede concentrarse en desarrollo en lugar de operaciones
• Escalabilidad: añadir nuevos entornos o servidores es trivial

Conclusión

La combinación de Cloud Build, SonarQube, scripts Bash y Apache Archiva nos ha permitido crear una solución robusta para el despliegue de aplicaciones Java. Si bien he compartido algunos aspectos de nuestra implementación, las soluciones específicas para cada organización requieren un análisis detallado de su infraestructura, procesos y necesidades particulares.

Esta arquitectura nos permitió no solo automatizar despliegues, sino también elevar significativamente la calidad del software entregado, reduciendo incidentes en producción y acelerando el ciclo de desarrollo.

Para equipos que enfrentan retos similares, recomiendo un enfoque incremental y personalizado. Cada organización tiene necesidades únicas que deben ser cuidadosamente analizadas para implementar la solución óptima.

¿Necesitas implementar una solución similar en tu organización? En webmago.dev ofrecemos consultoría especializada en la implementación de pipelines de CI/CD para entornos Java. Contáctanos para explorar cómo podemos ayudarte a optimizar tus procesos de desarrollo y despliegue.

🔹 El Problema: Procesamiento Seguro de Archivos

Un cliente necesitaba un sistema donde:

1. Al subir un archivo cifrado y comprimido a un bucket de Cloud Storage, se validara su autenticidad mediante una firma compartida entre emisor y receptor.

2. Si el archivo era válido, se descomprimía y se verificaba la integridad de los archivos internos usando SHA-256.

3. Solo los archivos que pasaran todas las validaciones serían procesados.

⚡ La Solución: Automatización con Cloud Functions

1️⃣ Trigger por Eventos de Cloud Storage

Configuré una Cloud Function activada por eventos de Cloud Storage (google.storage.object.finalize), lo que permite ejecutar código cada vez que se sube un archivo.

Validación de Firma Compartida

El archivo ZIP incluía un archivo .signature con una firma generada mediante un secreto compartido. Usé HMAC-SHA256 para asegurar que el archivo no fuera alterado.

import hmac
import hashlib
def validate_signature(secret_key, file_content, received_signature):
    generated_signature = hmac.new(secret_key.encode(), file_content, hashlib.sha256).hexdigest()
    return hmac.compare_digest(generated_signature, received_signature)

3️⃣ Descompresión y Validación SHA-256

Una vez validada la firma, el sistema descomprimía el archivo y verificaba cada archivo interno contra un hash predefinido.

import zipfile
import hashlib
def check_file_hash(file_path, expected_hash):
    with open(file_path, "rb") as f:
        file_data = f.read()
        computed_hash = hashlib.sha256(file_data).hexdigest()
        return computed_hash == expected_hash

4️⃣ Notificación y Manejo de Errores

Si alguna validación fallaba, el sistema enviaba una alerta por Pub/Sub o Correo Electrónico para notificar al administrador.

📊 Resultados

✅ Procesamiento automatizado y seguro sin intervención manual o humana.
✅ Reducción de errores por archivos corruptos o no autorizados.
✅ Escalabilidad gracias a Cloud Functions (pago por uso).

🚀 ¿Necesitas una Solución Similar?

Si buscas automatizar procesos en la nube con GCP, AWS o Azure, puedo ayudarte a diseñar e implementar una solución robusta y segura.

📩 ¡Contáctame y hablemos de tu proyecto!

Hace apenas dos semanas, compartí contigo una herramienta que he estado afinando para simplificar tu flujo de trabajo. Winter CMS encapsula un entorno de desarrollo robusto y eficiente, ahorrándote horas de configuración y garantizando la consistencia en cada paso de tu proceso creativo.

¿Qué te ofrece Winter CMS?

• Un entorno consistente: Olvídate de los “funciona en mi máquina”. Winter CMS asegura que todos los miembros de tu equipo trabajen en un ambiente idéntico.
• Ahorro de tiempo invaluable: Dedica tu energía a lo que realmente importa: ¡codificar! Winter CMS viene listo para usarse.
• Flexibilidad total: Adapta Winter CMS a tus necesidades específicas. Su diseño modular te permite integrar las herramientas que realmente utilizas.
• La base de mis servicios: Winter CMS no es solo una imagen Docker, es la demostración de mi compromiso con la eficiencia y la calidad en el desarrollo. Utilizo esta misma base para ofrecerte soluciones robustas y escalables.

¿Qué Versiones de Winter CMS se han liberado?

• 1.2.7 php 8.2 fpm
• 1.2.7 php 8.2 apache
• 1.2.7 php 8.1 fpm
• 1.2.7 php 8.1 apache
• 1.2.7 php 8.0 fpm
• 1.2.7 php 8.0 apache

¿Listo para experimentar la calidez de un desarrollo sin complicaciones?

¡Quiero saber cómo Winter CMS puede impulsar mi próximo proyecto!

Al hacer clic en el botón de arriba, podrás contactarme directamente para discutir tus necesidades y descubrir cómo mis servicios, basados en la eficiencia de herramientas como Winter CMS, pueden llevar tus ideas al siguiente nivel.

Ya sea que necesites ayuda para optimizar tu flujo de trabajo, construir aplicaciones robustas o implementar soluciones escalables, estoy aquí para ofrecerte mi experiencia y las herramientas adecuadas.

¡No esperes más para descongelar tu potencial! Explora Winter CMS en Docker Hub: https://hub.docker.com/r/webmago/winter

Today I put my hands to write a basic docker-compose.yml to test the Docker Image using Docker Compose, SQLite as a database.

I decided to bind to my SSD local directories with storage, themes, plugins, and database container directories to keep this data safe if the container crashes or is removed.

WinterCMS binding directories

I created an .env file to inject environment variables and some values into the docker-compose.yml services file.

###
#
# Winter CMS Test Image
# Version 1.0
# @author: WebMago
#
###
#### ---- * WinterCMS Configuration * ---- ####
# Name
CONTAINER_CMS_NAME=wintercms
# Image
CONTAINER_CMS_IMAGE=webmago/winter:stable-v1.1.3-php7.4-apache
# Env values
APP_DEBUG=false
APP_KEY=base64:PUT-YOUR-KEY-HERE
TZ=America/Mexico_City
APP_LOCALE=en
DB_PATH_SQLITE=storage/database.sqlite
DB_TYPE=sqlite
SESSION_DRIVER=file
CMS_ACTIVE_THEME=jacoweb-freelance
#### ---- * WinterCMS Domains * ---- ####
# A fake domain to test locally
WINTER_DOMAINS=winter.webmago.io

On the docker-compose.yml the .env values are injected as you can view on the code below and the directories are bound locally on my SSD.

version: '3'
services:
  web-wintercms:
    image: ${CONTAINER_CMS_IMAGE}
    container_name: ${CONTAINER_CMS_NAME}
    restart: unless-stopped
    ports:
      - "80:80"
    environment:
        VIRTUAL_HOST: ${WINTER_DOMAINS}
        APP_DEBUG: ${APP_DEBUG}
        APP_KEY: ${APP_KEY}
        TZ: ${TZ}
        APP_LOCALE: ${APP_LOCALE}
        DB_PATH_SQLITE: ${DB_PATH_SQLITE}
        DB_TYPE: ${DB_TYPE}
        SESSION_DRIVER: ${SESSION_DRIVER}
        CMS_ACTIVE_THEME: ${CMS_ACTIVE_THEME}
    volumes:
     - ./config/test:/var/www/html/config/docker
     - ./wintercms/storage/database.sqlite:/var/www/html/storage/database.sqlite
     - ./wintercms/storage/logs:/var/www/html/storage/logs
     - ./wintercms/storage/app:/var/www/html/storage/app
     - ./wintercms/storage/cms:/var/www/html/storage/cms
     - ./wintercms/themes:/var/www/html/themes
     - ./wintercms/plugins:/var/www/html/plugins

To launch WinterCMS execute:

docker-compose up -d

This runs the process in the background, to stop the execution run:

docker-compose down

The first run creates the database.sqlite and assign a random password to the admin user, this is not visible if you run the docker-compose command using the flag -d.

This can be solved using three scenarios.

First Scenario

Execute the docker-compose without the flag -d

docker-compose up

Second Scenario

If you have been executed the docker-compose with the flag -d and used the YAML of this example, the database is not deleted and the change will keep on the next execution.

# Access the container
docker-compose exec -it wintercms bash
# change the admin password
php artisan winter:passwd
# Enter the username to reset, on this case is admin
 Username to reset:
 > admin
 Enter new password (leave blank for generated password) []:
 > 
Password successfully changed.
# exit the container.
exit

If you require to use redis my advice is to use my images as a base to generate a new image with this PHP extension.

Third Scenario

Add the environment variable INIT_WINTER with the false value into the environment section of the YAML file, only if you have not executed the docker-compose command as the first run.

# Access the container
docker-compose exec -it wintercms bash
# Winter up
php artisan winter:up
.
. # this show the DB migration process
.
.
. # finally the process displays the random password assigned, this is an example only
- The following password has been automatically generated for the "admin" account: xZ4DF20k8txIrcBRqEhkjw
 

Accessing the Backend After all the previous process, now you can access the Backend  CMS, on my case I define the host wintercms.webmago.io as a fake URL added to my hosts, on my web browser typed: http://wintercms.webmago.io/backend/ the user is admin and my password the defined or adjusted based on the previous three scenarios described. /etc/hosts file

127.0.0.1 wintercms.webmago.io

WinterCMS SQLite, Freelance Theme

Glitches

The demo theme currently is not available, this can origin errors on the Frontend, you need to install and activate one of the suggested on the Front-end theme section, find or add your old theme with the required adjustments for WinterCMS.

On the Plugins section, the oldest OctoberCMS Plugins are available to be installed, this can be an additional article for the WinterCMS series.

WinterCMS Plugins

If you require my help, please let me know, contact me.

Varios desarrolladores que hemos usado este CMS también han optado por mirar y  migrar sus proyectos a este nuevo Administrador de Contenido, y por ello me he unido para proveer de las primeras imágenes Docker de WinterCMS de forma gratuita.

Para generar dichas imágenes me base en el código  proporcionado por @aspendigital, haciendo una derivación para generar el CI  con Codefresh un SaaS al que le he confiado varios de mis pipelines desde hace mas de 2 años.

Al momento de escribir este artículo he generado 3 versiones de WinterCMS, v1.1.0, v1.1.2 y v1.1.3 con PHP 7.2 a 7.4 con dos variantes, para apache y fpm; el por que no esta la version 1.1.1 se debe a que generó un error de sqlite al momento de su construcción, por lo que opté por no generar sus respectivas imágenes, así también  las imágenes con PHP 5.6 fueron descartadas , esto debido a que WinterCMS recomienda usar la version PHP 7.2 en adelante.

¿Cómo usar la imagen?

La forma rápida

$ docker run -p 80:80 --name winter webmago/winter:latest

Detener la imagen con CTRL-C

$ docker rm winter # Destruye el contenedor

Si hay un conflicto con el puerto, recibirás un mensaje de error del daemon Docker. Intenta mapear a un puerto local (-p 8080:80) o apaga el contenedor o servidor que esté usando el puerto deseado.

$ docker run -p 80:80 --name winter -d webmago/winter:latest
$ docker stop winter  # Detener el contenedor. Para reiniciar docker start winter
$ docker rm winter  # Destruir el contenedor

Trabajar con archivos locales

# Developing a plugin
$ git clone git@github.com:aspendigital/oc-resizer-plugin.git
$ cd oc-resizer-plugin
$ docker run -p 80:80 --rm \
-v $(pwd):/var/www/html/plugins/aspendigital/resizer \
webmago/winter:latest

# docker-compose.yml
version: '2.2'
services:
  web:
    image: webmago/winter
    ports:
      - 80:80
    volumes:
      - $PWD:/var/www/html/plugins/aspendigital/resizer

$ docker-compose up -d # inicia los servicios definidos en `docker-compose.yml` en el fondo
$ docker-compose down # detiene y destruye

Estas son algunas formas principales de como usar esta imagen, si requieres una personalización o implementarla en algun cluster Kubernetes contactame.

Hace apenas unas horas el sitio web ha cambiado y muestra ya varias opciones para poder instalar y probar esta derivación de CMS, así también publican las razones por las cuales dieron origen a esta derivación de OctoberCMS hacia WinterCMS, tal y como mencioné previamente, fue debido al nuevo plan de negocios impuesta por parte del grupo que formaban al legendario CMS.

Lanzamiento Website WinterCMS

Cabe mencionar que el Marketplace aun esta pendiente y tendremos que esperar un poco mas de tiempo para poder acceder al ecosistema de plugins que tenia OctoberCMS o hacer un pequeño ajuste a tu configuración del archivo config/cms.php


'updateServer' => 'https://api.wintercms.com/marketplace',


Mientras tanto esteré ajustando mis sistemas y códigos para probar y proveerles apoyo en este nuevo CMS, no me resta mas que decir que WinterCMS llegue a tener éxito y no repitamos esta historia en el futuro cercano o lejano.

Por si fuera poco, si necesitas soporte, el costo es de $97.00 USD por ticket y solo incluye 1.5 hr., entre los que hemos usado OctoberCMS para los proyectos ya  existe una preocupación al respecto, y mientras no actualicemos no entraremos en esta modalidad, esto será a partir de que OctoberCMS defina la fecha de aplicación de esta nuevo modelo de negocios.

Ante esta situación, parte del equipo de OctoberCMS ha abandonado el proyecto y han lanzado una derivación llamada WinterCMS, al momento de escribir este artículo, el sitio solo muestra el logo, un campo para suscribirse a las notificaciones y un acceso a Discord; sin embargo, en su repositorio de  Github ya se ve algo de movimiento.

Habrá quienes se queden en OctoberCMS y paguen $9 o $150 USD al año, y habrá otros quienes opten por user WinterCMS, solo esperemos que esta decisión no sea contra-producente para el equipo de OctoberCMS.