From 8289f9ed9e58f9ca5e24e3535a0518a34435e732 Mon Sep 17 00:00:00 2001 From: Franco Sbaffi Date: Fri, 6 Dec 2024 15:12:13 -0300 Subject: [PATCH 1/6] Se probaron funcionales totalmente diferentes a master --- .env | 3 +++ .env-staging | 3 +++ .gitattributes | 1 - docker/app3/Dockerfile | 11 ++++++++ docker/app3/index.html | 30 +++++++++++++++++++++ docker/docker-compose.yml | 46 +++++++++++++++++++++++---------- docker/nginx/nginx-staging.conf | 39 ++++++++++++++++++++++++++++ 7 files changed, 118 insertions(+), 15 deletions(-) create mode 100644 .env create mode 100644 .env-staging delete mode 100644 .gitattributes create mode 100644 docker/app3/Dockerfile create mode 100644 docker/app3/index.html create mode 100644 docker/nginx/nginx-staging.conf diff --git a/.env b/.env new file mode 100644 index 0000000..4019fa2 --- /dev/null +++ b/.env @@ -0,0 +1,3 @@ +APP_MODE=production +API_URL=https://api.example.com +DB_HOST=prod-db.example.com diff --git a/.env-staging b/.env-staging new file mode 100644 index 0000000..6d6e437 --- /dev/null +++ b/.env-staging @@ -0,0 +1,3 @@ +APP_MODE=staging +API_URL=https://staging.api.example.com +DB_HOST=staging-db.example.com diff --git a/.gitattributes b/.gitattributes deleted file mode 100644 index dfdb8b7..0000000 --- a/.gitattributes +++ /dev/null @@ -1 +0,0 @@ -*.sh text eol=lf diff --git a/docker/app3/Dockerfile b/docker/app3/Dockerfile new file mode 100644 index 0000000..9e5c74f --- /dev/null +++ b/docker/app3/Dockerfile @@ -0,0 +1,11 @@ +FROM nginx:alpine + +# En caso de que queramos usar variables de entorno, usar así: +# ARG APP_MODE=staging +# RUN echo "Ejecutando en modo $APP_MODE" + +COPY index.html /usr/share/nginx/html/index.html + +EXPOSE 80 + +CMD ["nginx", "-g", "daemon off;"] diff --git a/docker/app3/index.html b/docker/app3/index.html new file mode 100644 index 0000000..9587ae7 --- /dev/null +++ b/docker/app3/index.html @@ -0,0 +1,30 @@ + + + + + Volver al Futuro (Staging) + + + +

Volver al Futuro

+ DeLorean +

Bienvenido a la versión Staging de la App3.

+

Acá probamos nuevas funcionalidades antes de llevarlas a producción.

+

"¿Carretera? A donde vamos, no necesitamos carreteras."

+ + diff --git a/docker/docker-compose.yml b/docker/docker-compose.yml index 6f1c6d9..deaca74 100644 --- a/docker/docker-compose.yml +++ b/docker/docker-compose.yml @@ -1,40 +1,57 @@ +version: '3.8' + services: app1: build: context: ./app1 - image: app1_image:latest + image: app1_image:dev + # Cambiar el volumen o bind mount para staging volumes: - - app1-data:/var/www/html + - ./app1-staging:/var/www/html + environment: + - APP_ENV=staging networks: - - my-network + - my-staging-network app2: build: context: ./app2 - image: app2_image:latest + image: app2_image:dev + volumes: - - ./app2:/var/www/html + - ./app2-staging:/var/www/html + environment: + - APP_ENV=staging + networks: + - my-staging-network + + app3: + build: + context: ./app3 + image: app3_image:dev + # Este servicio no existe en master, es solo para staging + environment: + - APP_ENV=staging networks: - - my-network + - my-staging-network nginx: build: context: ./nginx - image: nginx_image:latest + image: nginx_image:staging ports: - - "80:80" + - "8080:80" # Nota: un puerto distinto a master para no colisionar + volumes: + - ./nginx/nginx-staging.conf:/etc/nginx/nginx.conf:ro depends_on: - app1 - app2 + - app3 networks: - - my-network - -volumes: - app1-data: - app2-data: + - my-staging-network networks: - my-network: + my-staging-network: driver: bridge @@ -55,4 +72,5 @@ networks: + diff --git a/docker/nginx/nginx-staging.conf b/docker/nginx/nginx-staging.conf new file mode 100644 index 0000000..8d6654d --- /dev/null +++ b/docker/nginx/nginx-staging.conf @@ -0,0 +1,39 @@ +events {} + +http { + upstream app1_staging { + server app1:80; + } + + upstream app2_staging { + server app2:80; + } + + upstream app3_staging { + server app3:80; + } + + server { + listen 80; + + + location /app1/ { + proxy_pass http://app1_staging/; + } + + + location /app2/ { + proxy_pass http://app2_staging/; + } + + + location /app3/ { + proxy_pass http://app3_staging/; + } + + + location / { + return 200 "Bienvenido al entorno STAGING"; + } + } +} From e2df6d68ac1f2e5cdb6ea506aa78087ba0ece749 Mon Sep 17 00:00:00 2001 From: Franco Sbaffi <99909205+FrancoSbaffi@users.noreply.github.com> Date: Fri, 6 Dec 2024 15:40:59 -0300 Subject: [PATCH 2/6] Update README.md --- README.md | 47 ++++++++++++++++++++++++++++++++--------------- 1 file changed, 32 insertions(+), 15 deletions(-) diff --git a/README.md b/README.md index a7c7098..aa9431c 100644 --- a/README.md +++ b/README.md @@ -1,19 +1,36 @@ -# Proyecto Integrado Basado en Clases +# Proyecto Integrador (Rama Staging) -Este proyecto implementa los conceptos aprendidos en las clases. Se incluyen: -1. **Balanceo de cargas (NGINX)** -2. **Almacenamiento por bloques** -3. **Creación y despliegue de imágenes Docker** -4. **Repositorios y ramas** +Bienvenid@ a la rama **staging**, el escalón más bajo en la cadena de desarrollo de este proyecto. Acá es donde tiramos todas las ideas, prototipos, experimentos y pruebas locas que se nos ocurran, sin miedo a romper nada, porque justamente para eso existe: es nuestro taller de prueba y error, el “laboratorio” donde vemos qué funciona y qué no. ---- +## ¿Por qué "la rama más baja"? -## Requisitos Previos -- Docker y Docker Compose instalados. -- Git configurado. +En este flujo de trabajo, **staging** es como el subsuelo de un gran edificio: +- Por encima, hay pisos más “presentables” (como `develop` o `master`), donde la cosa ya está más pulida. +- En cambio acá, en `staging`, nos damos la libertad de ensayar cualquier cambio sin la presión de tenerlo prolijo ni terminado. +- Imaginate un galpón lleno de chatarra, piezas sueltas, prototipos, ensayos y un sinfín de ideas en estado bruto. Así es `staging`. + +## ¿Qué hacemos acá? + +- **Experimentar a lo grande:** + Podemos agregar nuevos servicios (quizás un `app3` improvisado), modificar el `nginx.conf` las veces que queramos, cambiar volúmenes, bind mounts, imágenes, variables de entorno, todo sin problemas. + +- **Probar configuraciones inestables:** + Si algo no funciona, no importa. Lo dejamos igual. Por ahí más adelante nos sirve. Si algo funciona, copado, lo podemos “ascender” a la rama `feature/nueva-funcionalidad` para desarrollarlo mejor o pulirlo con más detalle. + +- **Decidir el destino de las ideas:** + Las cosas que en `staging` demuestran potencial —ese código que “funca” bien, esa configuración que parece prometedora— se llevan a `feature/nueva-funcionalidad` para ser mejoradas y eventualmente, si todo sale bien, incorporarlas a entornos más arriba en la pirámide (quizás `develop` y luego `master`). + +## ¿Y qué pasa con lo que no sirve? + +Acá viene lo interesante: +- En `staging` no eliminamos las cosas que no funcionan. Las dejamos ahí por si algún día nos inspiran o nos sirven para otro experimento futuro. +- Esta es la gracia: `staging` no tiene la presión de ser prolijo ni útil ahora, sino de ser un espacio creativo donde lo que no resultó hoy, quizás mañana sí. + +## Resumen + +- **staging = el subsuelo experimental:** probamos, testeamos y ensayamos sin miedo. +- Lo que sirve: asciende a `feature/nueva-funcionalidad` para desarrollarlo a fondo. +- Lo que no sirve: se queda, por si las dudas, porque nunca se sabe cuándo puede venir bien. + +En definitiva, la rama `staging` es el lugar perfecto para que, como único desarrollador, puedas volcar todas tus ideas, jugar con configuraciones, probar nuevas imágenes Docker, ajustar el `docker-compose.yml` una y otra vez, y todo eso sin tocar ni afectar el código más “serio” de las ramas superiores. Es el semillero de la creatividad, el sótano donde se gestan las innovaciones que podrían (o no) llegar a la cima del proyecto. -## Pasos para Ejecutar el Proyecto -### 1. Clonar el Repositorio -```bash -git clone https://github.com/usuario/proyecto-integrado.git -cd proyecto-integrado From 6a45e942e67cd4d687394b97373114724a19edc6 Mon Sep 17 00:00:00 2001 From: Franco Sbaffi <99909205+FrancoSbaffi@users.noreply.github.com> Date: Fri, 6 Dec 2024 15:43:28 -0300 Subject: [PATCH 3/6] Update README.md --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index aa9431c..b27a31b 100644 --- a/README.md +++ b/README.md @@ -32,5 +32,5 @@ Acá viene lo interesante: - Lo que sirve: asciende a `feature/nueva-funcionalidad` para desarrollarlo a fondo. - Lo que no sirve: se queda, por si las dudas, porque nunca se sabe cuándo puede venir bien. -En definitiva, la rama `staging` es el lugar perfecto para que, como único desarrollador, puedas volcar todas tus ideas, jugar con configuraciones, probar nuevas imágenes Docker, ajustar el `docker-compose.yml` una y otra vez, y todo eso sin tocar ni afectar el código más “serio” de las ramas superiores. Es el semillero de la creatividad, el sótano donde se gestan las innovaciones que podrían (o no) llegar a la cima del proyecto. +En definitiva, la rama `staging` es el lugar perfecto para que, como único desarrollador, puedas volcar todas tus ideas, jugar con configuraciones, probar nuevas imágenes Docker, ajustar el `docker-compose.yml` una y otra vez, y todo eso sin tocar ni afectar el código más “serio” de las ramas superiores. From 39a70a6242891f536516059b736d1ceb77af5960 Mon Sep 17 00:00:00 2001 From: Franco Sbaffi Date: Fri, 6 Dec 2024 16:24:14 -0300 Subject: [PATCH 4/6] Agregando directorios experimentales en staging --- mock-data/usuarios.json | Bin 0 -> 192 bytes scripts/generar_usuarios.sh | Bin 0 -> 190 bytes tools/README.md | Bin 0 -> 224 bytes 3 files changed, 0 insertions(+), 0 deletions(-) create mode 100644 mock-data/usuarios.json create mode 100644 scripts/generar_usuarios.sh create mode 100644 tools/README.md diff --git a/mock-data/usuarios.json b/mock-data/usuarios.json new file mode 100644 index 0000000000000000000000000000000000000000..bf5f4f091296b44e6d5737b963615e6aa211c404 GIT binary patch literal 192 zcmezWubM%DL5ZQ1p%{o08HyM(8S;T_B?c>?cr*}08FoUVSsVNakgDe Date: Fri, 6 Dec 2024 16:33:29 -0300 Subject: [PATCH 5/6] Opciones nuevas dentro de Staging --- scripts/generar_usuarios.sh | Bin 190 -> 952 bytes tools/README.md | Bin 224 -> 936 bytes 2 files changed, 0 insertions(+), 0 deletions(-) diff --git a/scripts/generar_usuarios.sh b/scripts/generar_usuarios.sh index 9486391b7d3dad4e3dea35e356ef3da0aaf4afe7..3606a6c4938eb1983fc4417ede04c52e27e48376 100644 GIT binary patch literal 952 zcmZvb%TB^z5QS&WQ~bh46UEDttsy3c=z<5Zr4}eDt!aV8$MpeRxmUk4e~@BG)61NH zE@#e6f4&EHX4f{e!YY5K*4ol~mRrWVwqSjGz^b?#OL@OKdTTda!M6Bs!5cEvd`qd|2&jx-4o7k5v@XqiHWXtgmHpNzsH{0NQ1u}NL?cjm4+SVSog-O6$l|R68 z&KhS{gJ#aAawa4EN{>;+3crG?DR-=Xss}M!bh>V^&&gX;BSy_R&74m#X%XnQ;8{6` zmeau95+lC?Rbs~%C=&a-cMhs_tYM53st#*rvm%E&5B7*o&-TPuhOP7Hm3U8yU4kUe zVNF~^Tmtg$Xzt1tXp#JJn2<#?6YG71Y(*UWg~X1!ny9)ao%0ksO)vFHNaNhO~w}wAWsL#O9Zlufb4W2 Xs|d)?0jtSj$OnpKG9&|eTtEl_HcSwk diff --git a/tools/README.md b/tools/README.md index 6e4d887452825772747310dddb779a273f36817e..2ba572d7279a4f5eddbd4d8e0dcfca3f20db12bc 100644 GIT binary patch literal 936 zcmaiyK~BR!3`M<0;tr9zX(hxRkf_8lnodg;NYf!{D#~qp2KK;zc0$=yD4L1K^KE~B z&-d5N3VX0*XZ^G7t+lOnvIkj(J<5~p)qT%aTO$ixDNH${_#Yk73-Rf3TYDFZOttOw zZ|xv_Bjm<2G#*_FlkHC4y;iFoR4==iy;d~UlI+%~UWpZTlk8v$mbgO5UeRZrHbQiE zZ?|^iYo^;L-FF_lQ|!ct=;alrEI8kCPo*7hN`(Fr>X)2qsGnCA_ zp@X&aAwM1zVWCr~fKH{o2n)|(c*Xa9P0yiD l Date: Mon, 23 Dec 2024 04:07:06 -0300 Subject: [PATCH 6/6] Update README.md --- README.md | 48 +++++++++++++++++++++++++----------------------- 1 file changed, 25 insertions(+), 23 deletions(-) diff --git a/README.md b/README.md index b27a31b..b389fc1 100644 --- a/README.md +++ b/README.md @@ -1,36 +1,38 @@ -# Proyecto Integrador (Rama Staging) +# (Staging Branch) -Bienvenid@ a la rama **staging**, el escalón más bajo en la cadena de desarrollo de este proyecto. Acá es donde tiramos todas las ideas, prototipos, experimentos y pruebas locas que se nos ocurran, sin miedo a romper nada, porque justamente para eso existe: es nuestro taller de prueba y error, el “laboratorio” donde vemos qué funciona y qué no. +Welcome to the staging branch—the foundation of the development pipeline for this project. This is where all ideas, prototypes, experiments, and unconventional tests are implemented, free from the worry of breaking anything. Think of it as the workshop for trial and error, the "laboratory" where we see what works and what doesn't. -## ¿Por qué "la rama más baja"? +## Why Call It the "Lowest Level" Branch? -En este flujo de trabajo, **staging** es como el subsuelo de un gran edificio: -- Por encima, hay pisos más “presentables” (como `develop` o `master`), donde la cosa ya está más pulida. -- En cambio acá, en `staging`, nos damos la libertad de ensayar cualquier cambio sin la presión de tenerlo prolijo ni terminado. -- Imaginate un galpón lleno de chatarra, piezas sueltas, prototipos, ensayos y un sinfín de ideas en estado bruto. Así es `staging`. +In this workflow, **staging** is like the basement of a tall building: -## ¿Qué hacemos acá? +- Above it are more "polished" floors (like `develop` or `master`) where things are more refined. +- Here in `staging`, however, we embrace freedom to test any changes without the need for neatness or completion. +- Imagine a warehouse filled with scrap, loose parts, prototypes, trials, and countless raw ideas. That's `staging`. + +## What Happens Here? -- **Experimentar a lo grande:** - Podemos agregar nuevos servicios (quizás un `app3` improvisado), modificar el `nginx.conf` las veces que queramos, cambiar volúmenes, bind mounts, imágenes, variables de entorno, todo sin problemas. +- **Big Experiments:** + Add new services (perhaps an improvised app3), modify nginx.conf as many times as necessary, change volumes, bind mounts, images, and environment variables—all without concerns. -- **Probar configuraciones inestables:** - Si algo no funciona, no importa. Lo dejamos igual. Por ahí más adelante nos sirve. Si algo funciona, copado, lo podemos “ascender” a la rama `feature/nueva-funcionalidad` para desarrollarlo mejor o pulirlo con más detalle. +- **Testing Unstable Configurations:** + If something doesn't work, that's fine. We leave it as is; it might be useful later. If something works, great! It can be "promoted" to the feature/new-functionality branch for further development and refinement. -- **Decidir el destino de las ideas:** - Las cosas que en `staging` demuestran potencial —ese código que “funca” bien, esa configuración que parece prometedora— se llevan a `feature/nueva-funcionalidad` para ser mejoradas y eventualmente, si todo sale bien, incorporarlas a entornos más arriba en la pirámide (quizás `develop` y luego `master`). +- **Deciding the Fate of Ideas:** + Anything that shows potential in staging—like functional code or promising configurations—gets carried over to `feature/new-functionality` for enhancement. If all goes well, it may eventually reach higher branches (develop, then master). -## ¿Y qué pasa con lo que no sirve? +## What Happens to Things That Don’t Work? -Acá viene lo interesante: -- En `staging` no eliminamos las cosas que no funcionan. Las dejamos ahí por si algún día nos inspiran o nos sirven para otro experimento futuro. -- Esta es la gracia: `staging` no tiene la presión de ser prolijo ni útil ahora, sino de ser un espacio creativo donde lo que no resultó hoy, quizás mañana sí. +Here’s the interesting part: -## Resumen +- In `staging`, we don’t delete things that don’t work. We keep them in place, just in case they inspire us or become useful for another experiment in the future. +- The beauty of `staging` lies in being a creative space where what doesn't work today might find its purpose tomorrow. -- **staging = el subsuelo experimental:** probamos, testeamos y ensayamos sin miedo. -- Lo que sirve: asciende a `feature/nueva-funcionalidad` para desarrollarlo a fondo. -- Lo que no sirve: se queda, por si las dudas, porque nunca se sabe cuándo puede venir bien. +## Summary -En definitiva, la rama `staging` es el lugar perfecto para que, como único desarrollador, puedas volcar todas tus ideas, jugar con configuraciones, probar nuevas imágenes Docker, ajustar el `docker-compose.yml` una y otra vez, y todo eso sin tocar ni afectar el código más “serio” de las ramas superiores. +- **staging = Experimental Basement**: We test, trial, and explore freely. +- Things that work: Get promoted to feature/new-functionality for deeper development.. +- Things that don’t work: Stay here for potential future use. + +In essence, the staging branch is the perfect space for me, as the sole developer, to unleash creativity, play with configurations, test new Docker images, adjust docker-compose.yml repeatedly, and do so without affecting the more "serious" code in the upper branches.