가비아는 한국에서 대표적인 도메인 및 호스팅 서비스를 제공하는 회사입니다.

도메인은 개인 블로그나 회사 웹사이트를 운영할 때 반드시 필요한 요소인데요, 오늘은 가비아에서 도메인을 구매하는 방법을 단계별로 알아보겠습니다.

또한, 가비아 외에도 다른 도메인 구매 서비스에는 어떤 것들이 있는지 소개하고, 마지막으로 구매한 도메인을 AWS의 Route53에 등록하여 실제로 사용하는 방법까지 함께 알아볼 예정입니다.

가비아 도메인 구매 방법

가비아 접속 및 회원 가입

• 가비아 사이트(gabia.com)에 접속 후 회원 가입.

도메인 검색

• 원하는 도메인 이름 입력 → 사용 가능한 도메인 확인.

도메인 선택 및 결제

• 적합한 도메인 확장자(TLD) 선택(.com, .net 등)
• .shop이나 .store로 끝나는 도메인은 비교적 저렴하게 구매할 수 있습니다. 예를 들어 가비아에서는 이러한 도메인을 단 550원에 구매할 수 있어 초기 도메인 연결 비용을 절감할 수 있다는 장점이 있습니다.

가비아 외 인기 도메인 구매 서비스 소개

가비아와 함께 많이 사용되는 도메인 구매 사이트 몇 곳을 소개하며 비교합니다

• Namecheap
  • 국제적으로 많이 사용되는 서비스.
  • 간단한 UI와 저렴한 가격으로 초보자에게 적합.
• GoDaddy
  • 글로벌 1위 도메인 등록 서비스.
  • 마케팅과 브랜드 구축에 유용한 부가서비스 제공.
• AWS Route53
  • 도메인 구매와 DNS 관리가 한 곳에서 가능.
  • AWS의 클라우드 서비스와 쉽게 연동 가능.
• Google Domains
  • 간편한 UI와 다양한 TLD(도메인 확장자) 지원.
  • Google Workspace와의 호환성 좋음.

가비아 도메인 AWS Route53 등록 방법

SSL/TLS 인증서는 웹 애플리케이션 데이터를 안전하게 보호하기 위해 HTTPS를 적용하는 데 필수적입니다. AWS 환경에서 HTTPS를 설정할 때 자주 비교되는 두 가지 옵션이 있습니다. AWS Certificate Manager (ACM)와 Let's Encrypt. 이번 글에서는 두 방법의 특징, 장단점, 차이점, 그리고 적합한 사용 사례를 비교해 보겠습니다.

1. AWS Certificate Manager (ACM)

AWS Certificate Manager (ACM)은 AWS에서 제공하는 SSL/TLS 인증서 발급 및 관리 서비스로 AWS 리소스에서 HTTPS를 적용하는 데 최적화된 도구입니다.

특징

• AWS 리소스 전용: ACM 인증서는 AWS 리소스(CloudFront, ELB, API Gateway)에서만 사용할 수 있습니다.
• 자동 갱신: 인증서를 수동으로 갱신할 필요 없이 자동 갱신됩니다.
• 도메인 검증: DNS 또는 이메일을 통해 소유권을 검증합니다.
• 무료 제공: AWS 리소스와 연동 시 추가 비용 없이 사용할 수 있습니다.

장점

1. AWS 서비스와 강력한 통합:
   • CloudFront, ELB, API Gateway 등과 몇 번의 클릭만으로 HTTPS를 설정할 수 있습니다.
2. 자동 갱신:
   • 인증서 만료 걱정 없이 자동으로 갱신됩니다.
3. 비용 효율성:
   • AWS 리소스 내에서 사용 시 무료입니다.

단점

1. 제한된 사용 환경:
   • ACM 인증서는 AWS 리소스 외부에서는 사용할 수 없습니다.
2. DNS 설정 복잡성:
   • 도메인 소유권 확인 과정에서 DNS CNAME 설정 작업이 필요할 수 있습니다.

적합한 사용 사례

• AWS 리소스를 기반으로 운영되는 애플리케이션에서 HTTPS 설정.
• 자동 갱신과 관리의 편리함이 중요한 경우.

2. Let's Encrypt

Let's Encrypt는 비영리 기관에서 제공하는 무료 SSL/TLS 인증서 발급 서비스로, AWS뿐 아니라 모든 서버 환경에서 HTTPS 적용이 가능합니다.

특징

• 범용 사용 가능: AWS 외에도 EC2, Nginx, Apache 등 다양한 환경에서 사용할 수 있습니다.
• 자동 발급 및 갱신 지원: Certbot 같은 도구를 사용하면 인증서를 자동으로 발급 및 갱신할 수 있습니다.
• 무료 제공: 누구나 무료로 SSL 인증서를 사용할 수 있습니다.

장점

1. 범용성:
   • AWS 외 서버나 클라우드 환경에서도 사용 가능합니다.
2. 무료:
   • 전 세계 누구나 인증서를 무료로 발급받을 수 있습니다.
3. 오픈 소스 도구 활용:
   • Certbot과 같은 오픈 소스 도구를 사용해 설정을 자동화할 수 있습니다.

단점

1. 수동 설정 필요:
   • 초기 설정에서 Certbot 설치 및 자동화 스크립트 작성이 필요합니다.
2. 짧은 유효 기간:
   • 인증서 유효 기간이 90일로 짧아 정기적인 갱신이 요구됩니다.

적합한 사용 사례

• EC2에서 Nginx, Apache 같은 웹 서버와 HTTPS 설정.
• AWS 외부 또는 온프레미스 환경에서 HTTPS가 필요한 경우.
• 비용을 최소화하면서 유연한 HTTPS 설정을 원하는 경우.

3. 주요 차이점 비교

항목ACMLet's Encrypt

4. 선택 가이드: 언제 무엇을 사용할까?

ACM을 선택해야 할 때

• AWS 서비스를 중심으로 애플리케이션을 운영 중일 때.
• ELB, CloudFront, API Gateway와 HTTPS를 간편하게 연결하고 싶을 때.
• 인증서 갱신과 관리를 자동화하고 싶을 때.
• EC2에서 직접 HTTPS를 설정할 필요가 없을 때.

Let's Encrypt를 선택해야 할 때

• EC2에서 직접 Nginx, Apache와 HTTPS를 설정해야 할 때.
• AWS 외부의 서버나 클라우드 서비스에서 인증서를 사용할 때.
• 초기 설정에 약간의 수작업이 가능하며 비용을 최소화하고 싶을 때.

5. 출처

• AWS Certificate Manager 공식 문서 (AWS Docs)
• Let’s Encrypt 공식 웹사이트 (Let's Encrypt)
• Certbot 문서 (Certbot)

이 글을 통해 ACM과 Let's Encrypt의 장단점을 비교하고 여러분의 상황에 맞는 HTTPS 인증 솔루션을 선택하는 데 도움이 되길 바랍니다.

1. 문제 상황

Spring Boot 애플리케이션에서 Redis 연결 설정을 완료한 후, 애플리케이션을 실행했지만 다음과 같은 에러가 발생했습니다:

org.springframework.data.redis.RedisConnectionFailureException: Unable to connect to Redis
Caused by: java.net.ConnectException: Connection refused

이 에러는 Redis 서버와 애플리케이션이 제대로 통신하지 못하는 경우에 발생합니다.

2. 문제 원인

• Redis 서버가 실행되지 않음
• Redis 설정 파일에서 외부 접근을 허용하지 않음
• Spring Boot의 Redis 설정에서 호스트가 잘못 지정됨
• Docker 네트워크 문제: 애플리케이션과 Redis 컨테이너가 서로 다른 네트워크에 속해 있음
• 포트 문제: Redis가 사용하는 포트(기본: 6379)가 열려 있지 않음

3. 해결 방법

Redis를 EC2에 직접 설치하거나 Docker를 통해 Redis 컨테이너를 설정하여 문제를 해결할 수 있습니다. 저는 Docker 환경에서 해결한 과정을 아래에 공유합니다.

4. Docker 환경에서 Redis 설정 및 문제 해결

4.1 Redis와 Spring Boot 애플리케이션이 통신할 네트워크 생성

먼저, Docker 컨테이너 간의 통신을 위해 네트워크를 생성합니다.

docker network create social-network

4.2 Redis 컨테이너 실행

Redis 컨테이너를 실행하면서, 이전에 생성한 네트워크(social-network)에 연결합니다.

docker run -d \\
  --name redis \\
  --network social-network \\
  -p 6379:6379 \\
  redis

• -name redis: 컨테이너 이름을 redis로 설정
• -network social-network: social-network 네트워크에 연결
• p 6379:6379: Redis의 기본 포트를 EC2에서 열어줌

4.3 Spring Boot 컨테이너 실행

Spring Boot 애플리케이션 컨테이너도 같은 네트워크에 연결하여 실행합니다.

docker run -d \\
  --name social-media \\
  --network social-network \\
  -p 8080:8080 \\
  -e AWS_S3_ACCESS_KEY=$AWS_S3_ACCESS_KEY \\
  -e AWS_S3_BUCKET_NAME=$AWS_S3_BUCKET_NAME \\
  -e AWS_S3_REGION=$AWS_S3_REGION \\
  -e AWS_S3_SECRET_KEY=$AWS_S3_SECRET_KEY \\
  <도커이미지이름>:latest

• -network social-network: Redis와 같은 네트워크에 연결
• Redis와 동일한 네트워크에 연결하지 않으면 Connection refused 에러가 발생합니다.

4.4 Spring Boot 설정 변경

Spring Boot 애플리케이션의 application.yml에서 Redis 호스트 이름을 redis로 변경합니다.

spring:
  data:
    redis:
      host: redis
      port: 6379

• host: redis: Docker 네트워크 내에서 Redis 컨테이너의 이름을 호스트로 지정

4.5 컨테이너 상태 확인

컨테이너들이 제대로 실행되고 있는지 확인합니다.

docker ps

출력

CONTAINER ID   IMAGE                              COMMAND                  CREATED         STATUS         PORTS                                       NAMES
0d2f25acb373   redis                              "docker-entrypoint.s…"   2 minutes ago   Up 2 minutes   0.0.0.0:6379->6379/tcp, :::6379->6379/tcp   redis
de6bb85de644   <image이름>  			  "java -Dspring.profi…"   2 minutes ago   Up 2 minutes   0.0.0.0:8080->8080/tcp, :::8080->8080/tcp   <설정한 이름>

5. Redis 연결 테스트

Spring Boot 애플리케이션 내에서 Redis 연결이 제대로 이루어졌는지 확인합니다.

5.1 컨테이너 내부에서 Redis CLI 테스트

social-media 컨테이너 내부에서 Redis CLI를 설치한 후 Redis에 연결해보세요.

docker exec -it social-media bash

내부에서 Redis CLI를 설치하고 연결 테스트를 수행합니다.

apt-get update && apt-get install redis-tools -y
redis-cli -h redis -p 6379 ping

출력 

PONG

• PONG 응답이 나오면 Redis와의 연결이 성공적으로 이루어진 것입니다.

6. 해결

위 과정을 통해 Spring Boot 애플리케이션이 Redis와 성공적으로 연결되었습니다. 이제 애플리케이션에서 Redis를 사용하는 기능을 정상적으로 실행할 수 있습니다.

7. 참고 명령어

• Docker 네트워크 생성:
• docker network create social-network
• Redis 컨테이너 실행:
• docker run -d --name redis --network social-network -p 6379:6379 redis
• Spring Boot 애플리케이션 컨테이너 실행:
• docker run -d --name social --network social-network -p 8080:8080

이렇게 문제를 해결하면 Spring Boot 애플리케이션과 Redis 간의 Connection refused 에러를 효과적으로 해결할 수 있습니다. 

Elastic Load Balancer (ELB)

Elastic Load Balancer(ELB)는 AWS의 트래픽 분산 서비스로 애플리케이션의 가용성과 확장성을 높이는 데 사용됩니다. 여러 서버 간 트래픽을 분산하여 병목 현상을 방지하고 효율적으로 부하를 처리합니다.

ELB의 주요 특징

1. 트래픽 분산
   • 다수의 EC2 인스턴스, 컨테이너, Lambda 함수 등으로 트래픽을 고르게 분배하여 애플리케이션 성능을 최적화합니다.
2. HTTPS 지원
   • AWS Certificate Manager(ACM)를 사용해 HTTPS 리스너를 설정, 데이터 전송 보안을 강화합니다.
   • 👉 ACM 알아보러 가기
3. 다양한 로드 밸런서 유형
   • Application Load Balancer(ALB): HTTP/HTTPS 트래픽 처리, URL 기반 라우팅 지원.
   • Network Load Balancer(NLB): 초고속 트래픽 처리를 위한 고성능 로드 밸런서.
   • Gateway Load Balancer(GLB): 네트워크 어플라이언스를 통합하여 대규모 트래픽 관리.
4. 고가용성과 자동 확장
   • 다수의 리소스에 대해 자동으로 트래픽을 분산하며 리소스 추가 시 자동 확장을 지원합니다.

ELB의 주요 사용 사례

1. 다수의 EC2 인스턴스 트래픽 관리
   • 대규모 트래픽을 처리하기 위해 여러 EC2 인스턴스에 고르게 트래픽을 분산.
2. 동적 콘텐츠 처리
   • API 호출, 사용자 요청, 데이터베이스 연결 등 실시간 트래픽 관리.
3. 고가용성 애플리케이션
   • 트래픽 증가나 서버 장애 시에도 서비스 중단 없이 애플리케이션을 운영.
4. 백엔드 보호
   • 로드 밸런싱을 통해 서버를 직접 노출하지 않고 간접적으로 트래픽 처리.

CloudFront: 개념과 사용 사례

CloudFront는 AWS의 콘텐츠 배포 네트워크(CDN) 서비스로 사용자와 가까운 엣지 로케이션에서 콘텐츠를 제공함으로써 전송 속도를 향상하고 지연 시간을 최소화합니다.

CloudFront의 주요 특징

1. 콘텐츠 캐싱
   • 정적 파일(HTML, CSS, 이미지, 동영상 등)을 엣지 로케이션에 저장하여 빠르게 전달.
2. HTTPS 지원
   • HTTPS를 기본 지원하며, ACM과 쉽게 통합하여 보안 연결 제공.
3. 글로벌 네트워크 활용
   • AWS 글로벌 네트워크의 엣지 로케이션을 통해 지연 시간을 감소.
4. 보안 기능
   • AWS WAF(Web Application Firewall)와 통합하여 보안 필터링.
   • DDoS 방어(AWS Shield)를 통해 애플리케이션 보호.

CloudFront의 주요 사용 사례

1. 정적 콘텐츠 배포
   • 웹사이트의 이미지, 동영상, CSS, JavaScript 파일을 빠르게 제공.
2. 글로벌 서비스 구축
   • 전 세계 사용자들에게 동일한 속도로 콘텐츠를 제공.
3. API Gateway와 통합
   • REST API, 서버리스 애플리케이션과의 연동을 통해 성능과 보안 강화.
4. 동영상 스트리밍
   • 동영상 또는 대용량 콘텐츠를 캐싱하여 스트리밍 성능을 최적화.

CloudFront와 ELB: 주요 차이점

항목CloudFrontElastic Load Balancer (ELB)

언제 CloudFront와 ELB를 사용할까?

CloudFront가 적합한 경우

• 정적 콘텐츠(이미지, CSS, JS) 배포가 필요한 경우.
• 글로벌 사용자를 대상으로 하는 서비스.
• API Gateway와의 통합이 필요하거나 보안을 강화하려는 경우.

ELB가 적합한 경우

• EC2 인스턴스를 사용하는 동적 애플리케이션.
• 고성능, 고가용성 애플리케이션에서 트래픽 분산이 필요한 경우.
• 데이터베이스와의 통신이 많은 API 호출 처리.

CloudFront와 ELB를 함께 사용할 때

• CloudFront는 전 세계적으로 정적 콘텐츠를 캐싱하여 배포.
• ELB는 백엔드 EC2 인스턴스 간 트래픽을 분산, 동적 요청 처리.

이 두 서비스를 결합하면 글로벌 사용자 대상의 빠른 정적 콘텐츠 제공과 안정적인 동적 애플리케이션 관리를 동시에 수행할 수 있습니다.

결론

CloudFront와 ELB는 서로 다른 목적에 최적화된 AWS 서비스입니다.

• 정적 콘텐츠 제공과 글로벌 사용자 지원이 필요하다면 CloudFront
• 동적 트래픽 처리와 로드 밸런싱이 필요하다면 ELB를 사용하는 것이 적합합니다.

필요에 따라 두 서비스를 함께 사용해 최적의 성능과 안정성을 확보할 수 있습니다.

출처

• AWS CloudFront 공식 문서
• AWS Elastic Load Balancer 공식 문서
• AWS WAF 및 보안 서비스
• AWS Global Infrastructure

@AuthenticationPrincipal과 @PreAuthorize는 모두 인증된 사용자에 대한 정보를 가져오거나 접근 제어를 구현하는 데 사용되지만, 목적과 사용 방식이 다릅니다.

1. @AuthenticationPrincipal

@AuthenticationPrincipal은 현재 인증된 사용자의 정보를 메서드의 파라미터로 주입할 때 사용됩니다. 이를 통해 컨트롤러 메서드 내부에서 인증된 사용자 정보를 직접 사용할 수 있습니다.

예를 들어, @AuthenticationPrincipal을 사용하여 userId를 메서드 파라미터로 전달받으면, 인증된 사용자의 ID 또는 UserDetails 객체를 사용할 수 있게 됩니다.

@DeleteMapping("/posting/{postingId}")
public ResponseEntity<Void> deletePostingById(
        @PathVariable Long postingId,
        @AuthenticationPrincipal String userId) {
    // userId를 통해 현재 사용자 정보를 확인하고 처리
    postingService.deletePostingByUserAndId(userId, postingId);
    return ResponseEntity.status(HttpStatus.NO_CONTENT).build();
}

주요 특징:

• 인증된 사용자 객체(UserDetails 또는 userId)를 직접 파라미터로 받습니다.
• 메서드 내부에서 인증된 사용자의 정보를 활용하여 원하는 로직을 구현할 수 있습니다.
• @AuthenticationPrincipal은 보통 인증된 사용자 정보를 쉽게 활용하기 위해 컨트롤러 메서드의 파라미터로 주입하는 데 주로 사용됩니다.

2. @PreAuthorize

@PreAuthorize는 메서드 호출 전에 권한을 검사하는 데 사용됩니다. @PreAuthorize는 SpEL(스프링 표현 언어)을 사용하여 권한 조건을 정의하며 해당 조건을 만족해야만 메서드를 실행할 수 있습니다.

예를 들어 특정 게시글의 작성자인 경우에만 삭제할 수 있도록 @PreAuthorize를 사용해 권한을 제한할 수 있습니다.

@PreAuthorize("@postingService.isOwner(authentication, #postingId)")
@DeleteMapping("/posting/{postingId}")
public ResponseEntity<Void> deletePostingById(@PathVariable Long postingId) {
    postingService.deletePostingById(postingId);
    return ResponseEntity.status(HttpStatus.NO_CONTENT).build();
}

주요 특징:

• 메서드 실행 전에 권한 조건을 평가하여 접근 제어를 수행합니다.
• authentication 객체나 파라미터(예: #postingId)를 사용하여 권한 검사 로직을 정의할 수 있습니다.
• 서비스 또는 리포지토리 메서드에서도 사용할 수 있으며, 메서드 자체에 대한 접근 제어를 수행합니다.

차이점 요약

기능 @AuthenticationPrincipal @PreAuthorize

결국 @AuthenticationPrincipal은 인증된 사용자 정보를 파라미터로 주입하여 로직에서 활용할 때 유용하고 @PreAuthorize는 특정 권한이나 조건을 만족할 때만 메서드를 호출하도록 보장할 때 적합합니다.

문제

Spring Boot 백엔드에서 multipart/form-data 요청 처리 시, 아래와 같은 에러가 발생

org.springframework.web.HttpMediaTypeNotSupportedException:
Content-Type 'multipart/form-data;boundary=--dio-boundary-0131634832;charset=UTF-8'

1. @RequestBody와 multipart/form-data의 비호환성:
   • @RequestBody는 JSON 데이터를 처리하는 데 사용되며 multipart/form-data 요청과 호환되지 않음.
   • multipart/form-data는 파일과 텍스트 필드를 함께 처리하는 특별한 Content-Type으로 @RequestPart 또는 @RequestParam이 필요함.

해결 방법

1. 컨트롤러 수정

@ModelAttribute를 사용하여 multipart 요청의 데이터를 처리함으로써 JSON과 파일 데이터를 DTO 객체로 매핑할 수 있었습니다.

@PostMapping(GlobalURI.POSTING_ROOT_URI)
public ResponseEntity<RequestResultDto> registerPosting(
        @ModelAttribute RegisterPostingRequest requestDto,
        @AuthenticationPrincipal String userId) {
    return ResponseEntity.status(HttpStatus.CREATED)
            .body(postingService.registerPosting(requestDto, userId));
}

2. Spring 설정 확인

multipart/form-data 요청을 처리하려면, Spring Boot의 MultipartResolver 설정이 올바르게 구성되어 있어야 합니다.

application.yml 설정

spring:
  servlet:
    multipart:
      enabled: true
      max-file-size: 10MB
      max-request-size: 10MB

추가 개념 설명

@ModelAttribute란?

• Spring MVC에서 요청 데이터를 객체로 매핑하는 데 사용.
• 기본적으로 HTTP 요청의 파라미터를 매핑하며 multipart/form-data 요청도 지원.

@ModelAttribute와 Multipart

• multipart/form-data 요청에서 파일(MultipartFile)과 텍스트 필드를 DTO에 한 번에 매핑할 수 있는 강력한 방법.
• 텍스트 데이터는 HTTP 요청의 폼 필드에서 파일 데이터는 MultipartResolver를 통해 처리.

문제 상황

Spring Boot 애플리케이션에서 H2 메모리 데이터베이스를 사용해 JPA로 테이블을 생성하고, data.sql 파일로 초기 데이터를 삽입하려 했습니다. 하지만 애플리케이션 실행 중 다음과 같은 오류가 발생했습니다.

Table "BOOK" not found (this database is empty)

data.sql이 실행될 때 book 테이블이 아직 생성되지 않아 데이터 삽입에 실패한 것입니다. ddl-auto: create 옵션으로 JPA가 테이블을 자동 생성하도록 설정했지만, data.sql이 실행되는 시점이 JPA 테이블 생성 이전이어서 문제가 발생했습니다.

원인 분석

Spring Boot는 기본적으로 데이터베이스 초기화를 데이터 소스 설정 직후에 실행합니다. 따라서, data.sql이 테이블 생성 이전에 실행되어 테이블이 존재하지 않는 상태에서 데이터 삽입을 시도하는 문제가 발생했습니다.

해결 방법

이 문제를 해결하기 위해 defer-datasource-initialization: true 옵션을 추가했습니다. 이 설정은 Spring Boot 2.5 이상에서 제공되며 데이터베이스 초기화가 JPA에 의해 테이블이 생성된 후에 실행되도록 지연시킵니다.

적용 방법

application.yml에 다음 설정을 추가했습니다:

spring:     
  jpa:
    database-platform: org.hibernate.dialect.H2Dialect
    defer-datasource-initialization: true

이 설정으로 인해 JPA가 테이블을 먼저 생성하고, 이후에 data.sql이 실행되어 데이터가 정상적으로 삽입되었습니다.

결과

defer-datasource-initialization: true 옵션을 사용함으로써 테이블이 생성된 후 데이터가 삽입되도록 순서를 맞춰 문제를 해결할 수 있었습니다.

Docker 컨테이너에서 S3 관련 에러가 발생한 경우 원인은 대부분 환경 변수가 제대로 설정되지 않은 것입니다.

이번 포스팅에서는 환경 변수를 설정하고 Docker 컨테이너에 적용하는 다양한 방법을 정리해 보겠습니다.

🛑 문제 발생

Docker Hub에서 이미지를 pull 한 뒤 run 명령어를 실행했으나, 다음과 같은 S3 관련 에러가 발생했습니다.

원인 분석

컨테이너에서 필요한 S3 환경 변수(예: AWS_S3_ACCESS_KEY, AWS_S3_BUCKET_NAME 등)가 설정되지 않은 것이 원인입니다.

✅ 해결 방법

1️⃣ .env 파일 사용

Docker 컨테이너 실행 시, 필요한 환경 변수를 .env 파일에 저장하여 설정할 수 있습니다.

1. .env 파일 작성

아래와 같은 형식으로 .env 파일을 작성합니다:

AWS_S3_ACCESS_KEY=your-access-key
AWS_S3_SECRET_KEY=your-secret-key
AWS_S3_BUCKET_NAME=your-bucket-name
AWS_S3_REGION=your-region

2. Docker 컨테이너 실행

컨테이너 실행 시 .env 파일을 로드하여 환경 변수를 적용합니다:

docker run -p 8080:8080 --env-file=.env -d --name social <이미지이름>

다른 해결 방법들

2️⃣ Spring Boot 프로젝트 내 환경 변수 통합

만약 Spring Boot 프로젝트를 Docker 이미지로 빌드한 경우 환경 변수를 Spring Boot의 application.yml 또는 application.properties에 매핑할 수 있습니다.

1. application.yml 설정

application.yml 파일에 아래와 같이 환경 변수를 매핑합니다:

cloud:
  aws:
    credentials:
      access-key: ${AWS_S3_ACCESS_KEY}
      secret-key: ${AWS_S3_SECRET_KEY}
    region:
      static: ${AWS_S3_REGION}
    s3:
      bucket: ${AWS_S3_BUCKET_NAME}

2. Dockerfile 수정

.env 파일을 Docker 빌드 과정에 포함시킵니다:

COPY .env /app/.env

3. 컨테이너 실행

컨테이너 실행 시 .env 파일에 설정된 값을 사용합니다:

docker run -p 8080:8080 -d --name social <이미지이름>

3️⃣ Docker Compose 활용

Docker Compose를 사용하면 환경 변수를 보다 편리하게 관리할 수 있습니다.

1. docker-compose.yml 작성

.env 파일을 Docker Compose와 함께 사용할 수 있도록 설정합니다:

version: '3.8'
services:
  app:
    image: <이미지이름>
    ports:
      - "8080:8080"
    env_file:
      - .env

2. Docker Compose 실행

docker-compose up -d

 정리

• Docker 환경 변수 설정은. env 파일, Spring Boot 설정, 또는 Docker Compose를 통해 간단히 해결할 수 있습니다.
• 권장되는 방법은. env 파일과 Docker Compose를 조합하여 관리하는 방식입니다.