-
Notifications
You must be signed in to change notification settings - Fork 1
[All-Feat] Nginx 리버스 프록시 설정, 경로 수정 #366
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
WalkthroughThis pull request updates the frontend deployment and build processes. The deployment script now dynamically determines directory paths using the Changes
Sequence Diagram(s)sequenceDiagram
participant User
participant DeployScript as script/deploy/frontend_deploy.sh
participant FileSystem
User ->> DeployScript: Start Deployment
DeployScript ->> FileSystem: Check/Create backup directory ($BACKUP_DIR)
DeployScript ->> FileSystem: Archive FRONTEND_DIR using TIMESTAMP
DeployScript ->> FileSystem: Copy new client files from $APP_DIR/frontend/dist/client to $FRONTEND_DIR
alt Rollback Triggered
DeployScript ->> FileSystem: Extract backup file from $BACKUP_DIR using TIMESTAMP
end
sequenceDiagram
participant Developer
participant BuildProcess
Developer ->> BuildProcess: Trigger "build" script
BuildProcess ->> BuildProcess: Execute "build:client"
BuildProcess ->> BuildProcess: Execute "build:server" (with SSR)
BuildProcess ->> BuildProcess: Run "tsc -b" for TypeScript compilation
BuildProcess -->> Developer: Build complete
Possibly related PRs
Suggested reviewers
Poem
✨ Finishing Touches
🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 0
🧹 Nitpick comments (1)
script/deploy/nginx/frontend.conf (1)
50-55: Separate static asset handling with caching is consistent with SSR best practices.
Providing a 7-day cache for static resources is good. If you version your assets by hash, consider extending the cache duration for better performance.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📥 Commits
Reviewing files that changed from the base of the PR and between d33db15 and 22725cfa74db8b5012994c361bf63804dc24b7ba.
📒 Files selected for processing (2)
script/deploy/frontend_deploy.sh(1 hunks)script/deploy/nginx/frontend.conf(1 hunks)
🧰 Additional context used
🧠 Learnings (1)
script/deploy/nginx/frontend.conf (1)
Learnt from: dioo1461
PR: softeer5th/Team4-enDolphin#350
File: script/deploy/nginx/frontend.conf:49-51
Timestamp: 2025-03-25T07:32:54.031Z
Learning: For Nginx configurations with SSR (Server-Side Rendering), caching directives like 'expires' and 'Cache-Control' headers should be removed from proxy location blocks to prevent API requests from being cached by browsers. Static assets should have their own location blocks with appropriate caching settings.
🔇 Additional comments (2)
script/deploy/frontend_deploy.sh (1)
7-7: Switch to dynamic SSR directory path is beneficial.
Good improvement for flexibility and maintainability. Just ensure$APP_DIRis correctly set before usage in different environments.script/deploy/nginx/frontend.conf (1)
37-42:Details
❓ Verification inconclusive
Proxy configuration for SSR looks appropriate.
By specifyingproxy_http_version 1.1,Upgrade, andConnectionheaders, you correctly enable WebSocket and SSE. Confirm that port5173is indeed where your SSR process is listening in production.Also applies to: 48-48
🏁 Script executed:
#!/bin/bash # Verify SSR is actually running on port 5173 ss -tlnp | grep ':5173'Length of output: 116
Below is an updated verification step to help confirm that your SSR process is indeed running on port 5173. Since the original command using
ssfailed due to the command not being available in the environment, please run the following fallback script to check usinglsof:Rewritten Review Comment:
Ensure SSR Port Verification for Nginx ProxyThe proxy configuration for SSR looks appropriate. By specifying
proxy_http_version 1.1along with theUpgradeandConnectionheaders, you correctly enable WebSocket and SSE support. However, please verify that the SSR process is indeed listening on port5173in production. Note that the previous check usingssfailed because the tool was not available. Use the above fallback script (or a similar method) to manually confirm that the SSR process is active on port5173.Also applies to: Lines 48-48
🏁 Script executed:
#!/bin/bash # Verify SSR is running on port 5173 using lsof lsof -i tcp:5173Length of output: 113
Ensure SSR Port Verification for Nginx Proxy
The proxy configuration for SSR is correctly set up with
proxy_http_version 1.1,Upgrade, andConnectionheaders enabling WebSocket and SSE. However, it's essential to confirm that the SSR process is listening on port5173in production. Attempts to automatically verify this usingssandlsoffailed due to those tools not being available in the environment. Please perform a manual verification (or use alternative tools such asnetstatif available) to ensure that your SSR process is indeed active on port5173.Also applies to: Lines 48-48
kwon204
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
just ask; pm2 start $SSR_DIR/index.js 여기에서 index.js를 어디서 가져오는 지 궁금합니다.
아 그러네요 그부분을 수정하기보다는 제가 서버파일을 빌드해서 |
22725cf to
35f3c9b
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 0
🔭 Outside diff range comments (1)
script/deploy/frontend_deploy.sh (1)
20-30: 💡 Verification agent🧩 Analysis chain
Review server restart sequence.
The script restarts the SSR server before copying the new frontend files (line 35), which might cause the server to run with outdated files. Additionally, it's not clear how the SSR server files are being updated.
🏁 Script executed:
#!/bin/bash # Check if the index.js file exists in the SSR_DIR directory if [ -f "$SSR_DIR/index.js" ]; then echo "Found index.js in $SSR_DIR" echo "File contents:" head -n 20 "$SSR_DIR/index.js" else echo "index.js not found in $SSR_DIR" echo "Directory contents:" ls -la "$SSR_DIR" || echo "Directory does not exist or is empty" fi # Check if the server build is available in the frontend/dist directory if [ -d "$APP_DIR/frontend/dist/server" ]; then echo "Server build found in dist/server directory" echo "Directory contents:" ls -la "$APP_DIR/frontend/dist/server" else echo "Server build not found in dist/server directory" fiLength of output: 409
Fix Deployment Sequence and Environment Variables for SSR Server
- The verification script indicates that the expected SSR files (e.g.,
index.jsin theSSR_DIRand the server build infrontend/dist/server) are missing. This reinforces the concern that the SSR server is being restarted before updated files are deployed.- Reorder the deployment steps so that the updated SSR/frontend files are copied or built first, ensuring that when the SSR server is restarted (using PM2), it runs the latest version.
- Verify that environment variables (
SSR_DIRandAPP_DIR) are correctly defined so that the file paths resolve properly during deployment.
🧹 Nitpick comments (3)
frontend/server/index.js (1)
44-44: Consider adding error handling for server startup.While the dynamic port configuration is good, the server startup lacks error handling. Adding a try-catch block around the server initialization would make the application more robust.
- app.listen(PORT); - // eslint-disable-next-line no-console - console.log(`\nServer running at \x1b[33mhttp://localhost:${PORT}\x1b[0m \n`); + app.listen(PORT, (err) => { + if (err) { + // eslint-disable-next-line no-console + console.error('Failed to start server:', err); + process.exit(1); + } + // eslint-disable-next-line no-console + console.log(`\nServer running at \x1b[33mhttp://localhost:${PORT}\x1b[0m \n`); + });Also applies to: 46-46
frontend/package.json (1)
11-11: Consider separating preview from full build.While the updated preview script works correctly, it always rebuilds the entire application before starting the server. Consider adding a separate script for just running the production server without rebuilding for faster iterations during testing.
"preview": "pnpm build && cross-env NODE_ENV=production node dist/server", + "serve:prod": "cross-env NODE_ENV=production node dist/server",script/deploy/frontend_deploy.sh (1)
53-55: Consider parameterizing the backup retention policy.The script currently keeps the 5 most recent backups. Consider making this configurable by adding a variable for the number of backups to retain.
-# 오래된 백업 정리 (최근 5개만 유지) +# Define backup retention count +BACKUP_RETENTION=5 + +# 오래된 백업 정리 (최근 $BACKUP_RETENTION개만 유지) echo "오래된 프론트엔드 백업 정리 중..." -cd $APP_DIR/frontend/backups && ls -t | tail -n +6 | xargs rm -f || true +cd $APP_DIR/frontend/backups && ls -t | tail -n +$((BACKUP_RETENTION+1)) | xargs rm -f || true
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📥 Commits
Reviewing files that changed from the base of the PR and between 22725cfa74db8b5012994c361bf63804dc24b7ba and 35f3c9b.
⛔ Files ignored due to path filters (1)
frontend/pnpm-lock.yamlis excluded by!**/pnpm-lock.yaml
📒 Files selected for processing (3)
frontend/package.json(2 hunks)frontend/server/index.js(3 hunks)script/deploy/frontend_deploy.sh(3 hunks)
🔇 Additional comments (13)
frontend/server/index.js (5)
3-3: Good addition of the process import.Using the
node:processmodule allows proper access to environment variables needed for the new environment-aware server configuration.
9-10: Well-structured environment and port configuration.Great job implementing environment detection and configurable port settings. Using environment variables with sensible defaults (PORT=5173) follows best practices for configurable server deployments.
13-13: Appropriate dynamic HTML path configuration.The conditional path setting based on environment is a good approach for managing different file structures between development and production environments.
25-27: Good implementation of conditional static file serving.Conditionally serving static files only in production mode is appropriate since this aligns with the updated build structure where client assets are in the '../client' directory in production.
32-32: Correct usage of dynamic HTML path.This properly utilizes the environment-specific path determined earlier.
frontend/package.json (3)
9-9: Good addition of server build script.The new server build script correctly configures Vite to build the SSR component with appropriate output directory.
10-10: Well-structured build script update.The updated build script now properly chains client and server builds, ensuring both parts of the application are built during the process.
56-56: Good addition of cross-env dependency.Adding cross-env ensures that environment variables are set consistently across different operating systems, which is important for cross-platform development.
script/deploy/frontend_deploy.sh (5)
6-6: Good improvement to SSR directory path.Making the SSR directory path relative to APP_DIR rather than using a hardcoded path improves maintainability and flexibility.
9-10: Well-structured backup configuration.The addition of backup directory and timestamp variables provides a solid foundation for the backup system.
12-16: Good implementation of the backup process.Creating backups before deployment is an excellent practice that enables recovery in case of deployment failures.
35-35: Correct update to copy command for new build structure.The updated path correctly references the client files from the new build structure.
48-48: Proper update to rollback command.Using the BACKUP_DIR variable ensures consistency with the backup creation process.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 0
🧹 Nitpick comments (1)
script/deploy/frontend_deploy.sh (1)
12-16: Frontend Backup Process:
The backup process is clearly implemented by creating the backup directory (if missing) and archiving the current frontend state using tar with elevated permissions:mkdir -p $BACKUP_DIR sudo tar -czf $BACKUP_DIR/frontend_$TIMESTAMP.tar.gz -C $FRONTEND_DIR .This is a robust approach. One minor note: verify that using
sudohere is necessary given the file/directory permissions in your environment.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
script/deploy/frontend_deploy.sh(3 hunks)
🔇 Additional comments (4)
script/deploy/frontend_deploy.sh (4)
6-6: Dynamic SSR Directory Update:
Changing the SSR directory assignment from a hardcoded path toSSR_DIR=$APP_DIR/frontend/dist/serverimproves flexibility by tying the path to the environment variable
APP_DIR. This ensures that the deployment will correctly reference the built server artifacts regardless of the absolute location.
9-10: Backup Directory and Timestamp Initialization:
Introducing theBACKUP_DIRvariable and computing a dynamicTIMESTAMPusingBACKUP_DIR=$APP_DIR/frontend/backups TIMESTAMP=$(date +"%Y%m%d%H%M%S")allows for organized, timestamped backups of the frontend. This maximizes traceability and simplifies rollback management. Make sure that the
$APP_DIRand backup paths are correctly set up in your deployment environment.
35-35: Updated File Copy Command:
Modifying the copy command to:sudo cp -r $APP_DIR/frontend/dist/client/* $FRONTEND_DIR/ensures that only the client artifacts are deployed to the web root. This addresses the prior issue of incorrect file path usage. Confirm that all needed static assets are present in the
clientfolder after the build step.
47-48: Rollback Process Correction:
Updating the rollback extraction command to use the newly defined$BACKUP_DIR:sudo tar -xzf $BACKUP_DIR/frontend_$TIMESTAMP.tar.gz -C $FRONTEND_DIRcreates a consistent backup-restore strategy. This change ensures that rollbacks are performed using the same backing-up logic.
kwon204
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
고생하셨습니다
dioo1461
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM !~




#️⃣ 연관된 이슈>
📝 작업 내용> 이번 PR에서 작업한 내용을 간략히 설명해주세요(이미지 첨부 가능)
SSR 서버를 띄우기 위한 파일 경로가 잘못 설정되어 있어 수정해서 다시 올립니다.
🙏 여기는 꼭 봐주세요! > 리뷰어가 특별히 봐주었으면 하는 부분이 있다면 작성해주세요
Summary by CodeRabbit