195 lines
4.8 KiB
Markdown
195 lines
4.8 KiB
Markdown
# 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.
|
|
|