site rebuild
This commit is contained in:
IGNY8 VPS (Salman)
194
docs/DEPLOYMENT_ARCHITECTURE.md
Normal file
194
docs/DEPLOYMENT_ARCHITECTURE.md
Normal file
@@ -0,0 +1,194 @@
|
||||
# Deployment Architecture Analysis
|
||||
|
||||
## Current Setup
|
||||
|
||||
### Domain Routing
|
||||
- **`app.igny8.com`** → Vite dev server container (`igny8_frontend:5173`)
|
||||
- Live reload enabled
|
||||
- Development mode
|
||||
- Changes reflect immediately
|
||||
|
||||
- **`igny8.com`** → Static files from `/var/www/igny8-marketing`
|
||||
- Production marketing site
|
||||
- Requires manual build + copy to update
|
||||
- No containerization
|
||||
|
||||
### Current Issues
|
||||
1. ❌ Marketing site deployment is manual (not containerized)
|
||||
2. ❌ No automated deployment process
|
||||
3. ❌ Dev changes affect `app.igny8.com` but not `igny8.com` (confusing)
|
||||
4. ⚠️ Marketing site not versioned with codebase
|
||||
|
||||
---
|
||||
|
||||
## Option Comparison
|
||||
|
||||
### Option A: Separate Containers (Recommended ✅)
|
||||
|
||||
**Structure:**
|
||||
```
|
||||
igny8_frontend_dev → app.igny8.com (Vite dev server)
|
||||
igny8_frontend_prod → app.igny8.com (Production build, optional)
|
||||
igny8_marketing → igny8.com (Marketing static site)
|
||||
```
|
||||
|
||||
**Pros:**
|
||||
- ✅ Clear separation of concerns
|
||||
- ✅ Independent scaling and updates
|
||||
- ✅ Marketing site can be updated without affecting app
|
||||
- ✅ Production app can be containerized separately
|
||||
- ✅ Better security isolation
|
||||
- ✅ Easier CI/CD automation
|
||||
- ✅ Version control for marketing deployments
|
||||
|
||||
**Cons:**
|
||||
- ⚠️ Slightly more complex docker-compose setup
|
||||
- ⚠️ Need to manage 2-3 containers instead of 1
|
||||
|
||||
**Implementation:**
|
||||
```yaml
|
||||
services:
|
||||
igny8_frontend_dev:
|
||||
# Current dev server for app.igny8.com
|
||||
image: igny8-frontend-dev:latest
|
||||
ports: ["8021:5173"]
|
||||
|
||||
igny8_marketing:
|
||||
# Production marketing site for igny8.com
|
||||
image: igny8-marketing:latest
|
||||
build:
|
||||
context: ./frontend
|
||||
dockerfile: Dockerfile.marketing
|
||||
volumes:
|
||||
- marketing_static:/usr/share/caddy:ro
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Option B: Current Approach (Keep Manual)
|
||||
|
||||
**Structure:**
|
||||
```
|
||||
igny8_frontend_dev → app.igny8.com (Vite dev server)
|
||||
/var/www/igny8-marketing → igny8.com (Manual static files)
|
||||
```
|
||||
|
||||
**Pros:**
|
||||
- ✅ Simple (already working)
|
||||
- ✅ No additional containers
|
||||
- ✅ Fast static file serving
|
||||
|
||||
**Cons:**
|
||||
- ❌ Manual deployment process
|
||||
- ❌ No version control for marketing site
|
||||
- ❌ Hard to rollback
|
||||
- ❌ Not containerized (harder to manage)
|
||||
- ❌ Deployment not reproducible
|
||||
|
||||
---
|
||||
|
||||
### Option C: Unified Production Build
|
||||
|
||||
**Structure:**
|
||||
```
|
||||
Single container serves both app and marketing from same build
|
||||
```
|
||||
|
||||
**Pros:**
|
||||
- ✅ Single container to manage
|
||||
- ✅ Both sites from same codebase
|
||||
|
||||
**Cons:**
|
||||
- ❌ Can't update marketing without rebuilding app
|
||||
- ❌ Larger container size
|
||||
- ❌ Less flexible deployment
|
||||
- ❌ Dev server still separate anyway
|
||||
|
||||
---
|
||||
|
||||
## Recommendation: **Option A - Separate Containers**
|
||||
|
||||
### Why This Is Better:
|
||||
|
||||
1. **Production-Ready App Container**
|
||||
- Can deploy production build of app to `app.igny8.com` when needed
|
||||
- Dev container for development, prod container for production
|
||||
|
||||
2. **Containerized Marketing Site**
|
||||
- Marketing site becomes a proper container
|
||||
- Easy to update: rebuild image, restart container
|
||||
- Version controlled deployments
|
||||
- Rollback capability
|
||||
|
||||
3. **Clear Separation**
|
||||
- Dev environment: `igny8_frontend_dev` → `app.igny8.com`
|
||||
- Production app: `igny8_frontend_prod` → `app.igny8.com` (when ready)
|
||||
- Marketing site: `igny8_marketing` → `igny8.com`
|
||||
|
||||
4. **Better CI/CD**
|
||||
- Can deploy marketing site independently
|
||||
- Can deploy app independently
|
||||
- Automated builds and deployments
|
||||
|
||||
5. **Scalability**
|
||||
- Each service can scale independently
|
||||
- Better resource management
|
||||
|
||||
---
|
||||
|
||||
## Implementation Plan
|
||||
|
||||
### Step 1: Create Marketing Dockerfile
|
||||
```dockerfile
|
||||
# frontend/Dockerfile.marketing
|
||||
FROM node:18-alpine AS builder
|
||||
WORKDIR /app
|
||||
COPY . .
|
||||
RUN npm install
|
||||
RUN npm run build:marketing
|
||||
|
||||
FROM caddy:latest
|
||||
COPY --from=builder /app/dist /usr/share/caddy
|
||||
COPY Caddyfile.marketing /etc/caddy/Caddyfile
|
||||
EXPOSE 8020
|
||||
CMD ["caddy", "run", "--config", "/etc/caddy/Caddyfile"]
|
||||
```
|
||||
|
||||
### Step 2: Create Marketing Caddyfile
|
||||
```caddyfile
|
||||
# frontend/Caddyfile.marketing
|
||||
:8020 {
|
||||
root * /usr/share/caddy
|
||||
try_files {path} /marketing.html
|
||||
file_server
|
||||
}
|
||||
```
|
||||
|
||||
### Step 3: Update docker-compose.app.yml
|
||||
Add marketing service alongside frontend dev service.
|
||||
|
||||
### Step 4: Update Main Caddyfile
|
||||
Point `igny8.com` to `igny8_marketing:8020` instead of static files.
|
||||
|
||||
---
|
||||
|
||||
## Migration Path
|
||||
|
||||
1. **Phase 1**: Add marketing container (keep current setup working)
|
||||
2. **Phase 2**: Test marketing container on staging domain
|
||||
3. **Phase 3**: Switch `igny8.com` to use container
|
||||
4. **Phase 4**: Remove manual `/var/www/igny8-marketing` setup
|
||||
|
||||
---
|
||||
|
||||
## Conclusion
|
||||
|
||||
**Separate containers (Option A) is the best long-term solution** because:
|
||||
- ✅ Production-ready architecture
|
||||
- ✅ Better DevOps practices
|
||||
- ✅ Easier maintenance
|
||||
- ✅ Scalable and flexible
|
||||
- ✅ Industry standard approach
|
||||
|
||||
The current setup works but is not ideal for production. Separate containers provide better separation, versioning, and deployment automation.
|
||||
|
||||
Reference in New Issue
Block a user