Create Week10 Mission

[J2H3233]

🗣️ 이슈 번호

closed #91

📝 미션 번호

10주차 Misson 1

📋 구현 사항

• 워크플로우 추가

📎 스크린샷

✅ 체크리스트

• Assignees에 본인을 선택 했나요?
• Merge 하려는 브랜치가 올바르게 설정되어 있나요?
• 로컬에서 실행했을 때 에러가 발생하지 않나요?
• 불필요한 주석이 제거되었나요?
• 코드 스타일이 일관적인가요?

🤔 질문 사항

[hardwoong]

GitHub Actions와 AWS EC2를 이용한 CI/CD 배포, 그리고 EC2 환경에서의 Google 로그인 문제 해결까지 모두 잘 해결하셨습니다.

---

1. CI/CD 배포 파이프라인 구축

GitHub Actions와 AWS EC2를 연동하여 자동 배포 시스템을 구축하셨습니다. 코드를 푸시하면 자동으로 배포되는 환경은 프로젝트 환경에서 편리하게 작용합니다.

• GitHub Actions 워크플로우를 통한 자동 배포 시스템 구축
• EC2 인스턴스에 자동 배포되는 파이프라인 구성
• 배포 환경에서 애플리케이션이 정상적으로 동작

2. Google 로그인 배포 환경 문제 해결

EC2 배포 환경에서 Google 로그인이 동작하지 않았던 문제를 잘 해결하셨습니다. googleStrategy.js를 보니 callbackURL이 상대 경로로 설정되어 있어, 현재 호스트에 자동으로 매핑되어 개발/프로덕션 환경 모두에서 동작할 수 있도록 잘 구성되어 있습니다!

해결 방법:

• Google OAuth 리다이렉트 URI를 상대 경로(/api/v1/auth/google/callback)로 설정
• Google Cloud Console에서 해당 도메인을 리다이렉트 URI로 등록
• 상대 경로를 사용하면 현재 호스트에 자동으로 매핑되어 환경에 따라 유연하게 동작합니다

코드 구성:

// src/middlewares/passport/googleStrategy.js
export const googleStrategy = new GoogleStrategy(
  {
    clientID: process.env.GOOGLE_CLIENT_ID,
    clientSecret: process.env.GOOGLE_CLIENT_SECRET,
    callbackURL: '/api/v1/auth/google/callback', // 상대 경로 사용
    scope: ['email', 'profile'],
  },
  async (accessToken, refreshToken, profile, done) => {
    // ...
  }
);

특히 인상적인 점:

• 상대 경로를 사용하여 환경에 따라 유연하게 동작하도록 구성한 점이 좋습니다!
• Google 로그인 시 기존 사용자의 정보를 업데이트하는 로직이 포함되어 있습니다

---

배포 환경에서의 Google OAuth 설정

핵심 포인트:

• Google OAuth는 IP 주소와 포트 번호 형태(43.201.11.212:3000)의 리다이렉트 URI를 지원하지 않습니다
• 따라서 도메인을 사용하는 것이 필수입니다
• 상대 경로를 사용하면 현재 호스트에 자동으로 매핑되어 개발/프로덕션 환경 모두에서 동작합니다
• callbackURL을 상대 경로로 설정하고, Google Cloud Console에서도 도메인 형태로 등록해야 합니다

현재 설정:

callbackURL: '/api/v1/auth/google/callback'; // 상대 경로 사용

이 설정이 올바르게 적용되어 Google 로그인이 정상적으로 동작하고 있습니다!

도메인 설정 과정:

1. 도메인 DNS 설정

   • 도메인 제공업체(예: 내도메인한국)에서 도메인의 A 레코드를 EC2 인스턴스의 퍼블릭 IP 주소로 설정
   • 이렇게 하면 도메인이 EC2 인스턴스를 가리키게 됩니다

2. Google Cloud Console 설정

   • Google Cloud Console에서 OAuth 리다이렉트 URI를 도메인 형태로 등록
   • 예: http://your-domain.com/api/v1/auth/google/callback 또는 https://your-domain.com/api/v1/auth/google/callback
   • IP 주소 형태는 Google OAuth에서 지원하지 않으므로 도메인을 사용해야 합니다

3. 애플리케이션 코드

   • EC2 환경에서는 코드 변경이 필요 없습니다
   • callbackURL: "/api/v1/auth/google/callback"로 상대 경로를 사용하면, 현재 도메인에 자동으로 매핑됩니다

---

개선이 필요한 점

1. updateUserInfo 함수가 import되지 않았습니다

문제점:

googleStrategy.js에서 updateUserInfo 함수를 사용하고 있지만, import되지 않았습니다.

// src/middlewares/passport/googleStrategy.js
} else {
    user = await updateUserInfo(user.id,{
        name: name,
        snsId: snsId,
    })
}

개선 방안:

updateUserInfo 함수를 import하거나, 해당 함수를 구현해야 합니다.

// src/middlewares/passport/googleStrategy.js
import { Strategy as GoogleStrategy } from 'passport-google-oauth20';
import { findByEmail } from '../../repositories/auth.repository.js';
import {
  SocialRegisterService,
  updateUserInfo,
} from '../../services/auth.service.js'; // updateUserInfo 추가
import { Provider } from '@prisma/client';

또는 updateUserInfo 함수가 auth.service.js에 없다면, 해당 함수를 구현해야 합니다.

---

마무리

이번 미션을 통해 실제 프로덕션 환경 배포의 전 과정을 경험하셨습니다. CI/CD 파이프라인 구축부터 도메인 설정, OAuth 인증까지 모두 다루셨습니다!

특히 Google OAuth 리다이렉트 URI를 상대 경로로 설정하여 환경에 따라 유연하게 동작하도록 구성하신 점이 인상적입니다. Google 로그인 시 기존 사용자 정보를 업데이트하는 로직을 포함하신 점도 좋습니다!

여러 번의 시도 끝에 성공한 GitHub Actions 워크플로우도 고생 많으셨습니다!

---

참고사항

HTTPS 설정 권장:

• 현재 HTTP로 동작하고 있다면, 프로덕션 환경에서는 HTTPS를 사용하는 것이 보안상 안전합니다
• AWS Certificate Manager(ACM)를 사용하여 SSL/TLS 인증서를 발급받고, Application Load Balancer나 CloudFront와 연동하여 HTTPS를 적용할 수 있습니다
• 또는 Let's Encrypt를 사용하여 무료 SSL 인증서를 발급받을 수도 있습니다 (저는 이 방법을 더 선호합니다! 더 편해서..)

보안 그룹 확인:

• AWS EC2 보안 그룹 설정에서 HTTPS(443 포트)가 열려있는지 확인하세요
• 필요하다면 HTTP(80 포트)도 열어두되, 가능하면 HTTPS로 리다이렉트하는 것을 권장합니다

환경 변수 관리:

• 개발 환경과 프로덕션 환경의 설정을 환경 변수로 관리하는 것을 권장합니다
• 현재 상대 경로를 사용하고 있어 callbackURL은 환경 변수로 관리할 필요가 없지만, 다른 설정들(예: GOOGLE_CLIENT_ID, GOOGLE_CLIENT_SECRET)은 환경 변수로 관리하는 것이 좋습니다

PM2 또는 프로세스 매니저 사용:

• 프로덕션 환경에서는 PM2나 다른 프로세스 매니저를 사용하여 애플리케이션을 관리하는 것을 권장합니다
• systemd 서비스를 사용하는 것도 좋은 선택입니다
• 이렇게 하면 서버 재시작 시에도 애플리케이션이 자동으로 실행되고, 로그 관리도 편리합니다

모니터링 및 로그 관리:

• 배포 환경에서는 애플리케이션 로그를 모니터링하는 것이 중요합니다
• systemd의 journalctl을 사용하여 로그를 확인할 수 있습니다
• 예: journalctl -u your-service-name -f (실시간 로그 확인)