반응형

여러 사이트에 ssh 접속을 할때 접속 정보를 모두 기억하기가 어렵습니다.

예를 들어 AWS에 EC2가 여러개 있다면 아래와 같은 정보들을 모두 입력해야 하는 불편함이 있습니다.

ssh -i /path/key-pair-name.pem instance-user-name@instance-public-dns-name

이럴때를 위해 맥북에서는 ssh를 미리 저장해 놓고 alias 만으로 접속하는 기능이 있습니다.

 

맥북의 .ssh/config 파일을 사용하면 여러 서버에 대한 SSH 접속 설정을 간결하게 관리하고, 짧은 별칭(alias)으로 쉽게 접속할 수 있습니다. 이는 특히 여러 원격 서버나 여러 GitHub 계정을 관리할 때 매우 유용합니다.

 

.ssh/config 파일 생성 또는 열기

 

맥(macOS)의 경우 .ssh/config 파일이 자동으로 생성되어 있지 않을 수 있습니다. 이 경우 직접 파일을 생성해야 합니다.

touch ~/.ssh/config
open ~/.ssh/config

 

.ssh/config 파일 내용 작성

 

파일을 열고 아래와 같은 형식으로 각 서버의 접속 정보를 입력합니다.

Host [별칭]
    HostName [원격 서버의 IP 주소 또는 도메인 이름]
    User [접속할 사용자 계정]
    IdentityFile [SSH 키 파일 경로]
    Port [SSH 포트 번호 (기본값 22, 변경된 경우)]
  • Host: 이 별칭은 SSH 접속 시 사용할 짧은 이름(alias)이 됩니다.
  • HostName: 접속할 원격 서버의 IP 주소 또는 도메인 이름을 입력합니다.
  • User: 원격 서버에 접속할 사용자 계정 이름을 입력합니다.
  • IdentityFile: 해당 서버에 접속할 때 사용할 SSH 키 파일의 경로를 지정합니다. 예를 들어, ~/.ssh/your_key.pem과 같이 입력할 수 있습니다 . AWS EC2와 같은 경우 pem 키 파일을 다운로드하여 권한을 변경한 후 사용합니다.
  • 권한은 다음 명령을 사용하여 변경합니다.
chmod 600 your_key_file.pem
  • 권한을 변경하지 않으면 다음과 같은 메시지가 나옵니다.
Permissions 0644 for '/Users/admin/.ssh/id_rsa' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
Load key "/Users/admin/.ssh/id_rsa.pub": bad permissions
git@github.com: Permission denied (publickey).
  • Port: SSH 접속에 사용되는 포트 번호입니다. 기본값은 22이며, 변경된 경우에만 작성합니다.
  • Github의 경우 HostName과 User명은 아래와 같이 동일한 값을 사용합니다.
HostName github.com
User git

예시:

# 개인 GitHub 계정
Host github.com-personal
    HostName github.com
    User git
    IdentityFile ~/.ssh/id_rsa_personal

# 회사 GitHub 계정
Host github.com-work
    HostName github.com
    User git
    IdentityFile ~/.ssh/id_rsa_work

# 개발 서버
Host dev_server
    HostName 192.168.0.1
    User ubuntu
    IdentityFile ~/.ssh/dev_server_key.pem
    Port 2222

# Amazon Linux 2003 EC2     
Host aws-ec2
    HostName ec2-1-100-200-333.ap-northeast-2.compute.amazonaws.com
    User ec2-user
    IdentityFile ~/myec2.pem
 

 

연결 테스트 하기

다음과 같이 테스트를 할 수 있습니다.
ssh -T git@github.com-personal
ssh -T ec2-user@aws-ec2

 

Git 연결 설정을 config에 설정된 alias로 변경하기

 

기존 git 연결을 config에 설정한 alias명으로 변경할 수 있습니다.

git remote set-url origin git@github.com-personal:username/repo.git

 

SSH 접속하기

 

.ssh/config 파일에 설정한 별칭을 사용하여 터미널에서 간결하게 접속할 수 있습니다.

ssh [별칭]
ssh github.com-personal
ssh dev_server

 

이렇게 설정하면 복잡한 IP 주소, 사용자 이름, 키 파일 경로를 매번 입력할 필요 없이 간편하게 SSH 접속을 할 수 있습니다.

반응형
반응형

n8n을 AWS의 무료 인스턴스를 사용해서 설치하는 방법에 대해 알아봅니다.
 
https://youtu.be/rZnBHanWiZg

 

순서

  • Docker 설치
  • n8n 컨테이너 설치
  • AWS에 도메인 추가 (agent.codegear.info)
  • Nginx 설치 및 도메인 연결

 
n8n은 n8n 사이트에 가입해서 서비스를 사용할 수도 있고, 직접 셀프 호스팅으로 설치해서 사용할 수도 있습니다. 
가격은 Starter가 월24유로(약38,000원), Pro가 월60유로(약96,000원)으로 꽤 비용이 나가는 편입니다.
https://n8n.io/pricing/

 

n8n Plans and Pricing - n8n.io

Discover n8n's pricing alternatives for cost-effective workflow automation solutions. Find the perfect plan to maximize your workflows.

n8n.io

 
이전 포스팅에서 AWS에 EC2 인스턴스를 띄우고, Nginx를 설치하고, 도메인 연결하는 것까지 설명을 해놓았으니 참조하시기 바랍니다.
https://codegear.tistory.com/137

 

6천원 도메인, 무료 AWS로 '나만의 웹사이트' 띄우는 갓성비 끝판왕 가이드!

https://youtu.be/xXxljxkJy7Y 서비스 개발이 완료되면, 이를 서비스 하기 위해서는 서버와 도메인이 필요합니다.도메인을 싸게 구입하는 방법과AWS에서 도메인을 등록하고 서버를 셋팅해서 도메인 서버

codegear.tistory.com

이번 글에서는 앞에서 설정한 EC2 인스턴스에 Docker를 설치하고, n8n을 설치하는 방법을 주로 다룹니다.


Docker 설치

n8n을 쉽게 설치하기 위해서 우선 docker를 설치합니다.
Amazon Linux 2023에 Docker를 설치하는 방법은 AWS 문서에 잘 나와있습니다.
https://docs.aws.amazon.com/ko_kr/AmazonECS/latest/developerguide/create-container-image.html

 

Amazon ECS에서 사용할 컨테이너 이미지 생성 - Amazon Elastic Container Service

경우에 따라서는 ec2-user가 Docker 대몬에 액세스할 수 있는 권한을 제공하기 위해 인스턴스를 재부팅해야 할 수도 있습니다. 다음 오류가 표시될 경우 인스턴스를 재부팅합니다. Cannot connect to the D

docs.aws.amazon.com

터미널을 열어 EC2 인스턴스에 접속합니다.

ssh -i /path/to/your-key.pem ec2-user@YOUR_EC2_PUBLIC_IP

EC2 인스턴스에서 아래 명령을 수행합니다.

sudo yum update -y
sudo yum install docker
sudo service docker start
sudo usermod -a -G docker ec2-user


터미널 종료 후 다시 접속하면 ec2-user가 docker 권한을 갖게 됩니다.
다음 명령어로 docker의 정상 설치 여부를 확인할 수 있습니다.

docker info

 

Docker Compose 설치

sudo curl -L "https://github.com/docker/compose/releases/latest/download/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose



Docker Compose 권한 추가

sudo chmod +x /usr/local/bin/docker-compose


n8n 설치

디렉토리 생성

mkdir n8n_data 
cd n8n_data

 

docker-compose.yml 생성

docker에 이미지를 받고 컨테이너를 생성하기 위한 설정 파일을 생성합니다.

vi docker-compose.yml

아래 내용을 입력합니다. (vi에서 내용을 추가하기 위해서는 i 키를 누르셔야 합니다)

services:
  n8n:
    image: docker.n8n.io/n8nio/n8n # n8n Docker 이미지 사용
    restart: always # 컨테이너 종료 시 항상 재시작
    ports:
      - "5678:5678" # 호스트의 5678 포트를 컨테이너의 5678 포트에 연결 (n8n 기본 포트)
    environment:
      # n8n 라이선스 키 (선택 사항, 없으면 기본 기능으로 실행)
      # - N8N_LICENSE_KEY=YOUR_LICENSE_KEY
      
      # 데이터베이스 설정 (PostgreSQL 사용 권장)
      - DB_TYPE=postgresdb
      - DB_POSTGRESDB_HOST=n8n_db
      - DB_POSTGRESDB_PORT=5432
      - DB_POSTGRESDB_DATABASE=n8n_database
      - DB_POSTGRESDB_USER=n8n_user
      - DB_POSTGRESDB_PASSWORD=your_n8n_db_password # 안전한 비밀번호로 변경!

      # 웹훅 URL 설정 (선택 사항이지만 외부 접근 시 중요)
      - N8N_HOST=your.domain.com # n8n에 접속할 도메인 주소
      - N8N_PROTOCOL=https # HTTPS 사용 시
      - WEBHOOK_URL=https://your.domain.com/ # 웹훅 URL

    volumes:
      - ~/.n8n:/home/node/.n8n # n8n 데이터를 호스트에 영구 저장 (볼륨 마운트)

  n8n_db: # PostgreSQL 데이터베이스 서비스
    image: postgres:13 # PostgreSQL 13 버전 이미지 사용
    restart: always
    environment:
      - POSTGRES_DB=n8n_database
      - POSTGRES_USER=n8n_user
      - POSTGRES_PASSWORD=your_n8n_db_password # n8n 서비스의 DB_POSTGRESDB_PASSWORD와 동일하게 설정
    volumes:
      - pg_data:/var/lib/postgresql/data # PostgreSQL 데이터를 호스트에 영구 저장 (볼륨 마운트)

volumes:
  pg_data: # PostgreSQL 데이터 볼륨 정의

입력이 완료되면 vi editor에서 esc를 누른 후 다음 명령을 입력하여 저장합니다.

:wq

 

n8n 컨테이너 실행

docker-compose.yml 파일이 있는 디렉토리에서 다음 명령어를 실행합니다

docker-compose up -d

컨테이너가 잘 실행되었는지는 아래 명령어를 사용합니다.

docker-compose ps

 
컨테이너 로그도 확인해 줍니다.

docker-compose logs

 


 

도메인 설정하기

n8n에서 사용할 도메인은 agent.codegear.info입니다.
이를 위해 AWS Route53에 A 레코드 생성해야 합니다.
생성방법은 다음과 같습니다.
 

  • codegear.info 호스팅 영역 클릭:
    • "호스팅 영역" 목록에서 codegear.info를 클릭하여 상세 페이지로 들어갑니다.
  • 레코드 생성:
    • "레코드 생성(Create record)" 버튼을 클릭합니다.
  • 레코드 설정:
    • 레코드 이름(Record name):
      • agent를 입력합니다. 이렇게 하면 agent.codegear.info가 됩니다. (루트 도메인 codegear.info에 연결하려면 비워둡니다.)
    • 레코드 유형(Record type):
      • A - IPV4 주소로 트래픽 라우팅을 선택합니다. (도메인을 IP 주소에 연결하는 가장 일반적인 유형입니다.)
    • 값(Value):
      • Nginx 및 N8N이 설치된 AWS EC2 인스턴스의 퍼블릭 IP 주소를 입력합니다. (가급적 탄력적 IP 주소를 사용하는 것을 권장합니다. 탄력적 IP는 인스턴스 재부팅 시 IP가 변경되지 않습니다.)
      • 예: 52.78.XXX.XXX
    • TTL(Time to Live):
      • 기본값 (300초)을 유지하거나 원하는 값으로 설정합니다. TTL이 짧을수록 DNS 변경 사항이 더 빨리 전파되지만, DNS 서버에 더 많은 부하를 줍니다.
    • 라우팅 정책(Routing policy):
      • 단순 라우팅(Simple routing)을 유지합니다.
  • 레코드 생성:
    • "레코드 생성" 버튼을 클릭하여 설정을 저장합니다.

DNS 전파 확인

터미널을 열어 다음 명령으로 DNS 전파를 확인할 수 있습니다.

nslookup agent.codegear.info

 


Nginx 설정

Nginx 설정 파일 구조 이해

Amazon Linux 2023의 Nginx는 일반적으로 /etc/nginx/nginx.conf가 메인 설정 파일이고, 이 파일 안에서 include /etc/nginx/conf.d/*.conf; 지시어를 통해 /etc/nginx/conf.d/ 디렉토리 안의 .conf 파일들을 불러옵니다.
따라서 우리는 주로 /etc/nginx/conf.d/agent.codegear.info.conf와 같은 별도의 파일을 생성하여 도메인별 설정을 관리하는 것이 좋습니다.


  1. 새로운 Nginx 설정 파일 생성: SSH로 EC2 인스턴스에 접속한 후, 다음 명령어를 사용하여 /etc/nginx/conf.d/ 디렉토리에 agent.codegear.info.conf 파일을 생성하고 편집합니다.
    sudo nano /etc/nginx/conf.d/agent.codegear.info.conf
    
  2. 파일 내용 붙여넣기: vi 에디터에 다음 내용을 붙여넣으세요. 이 설정은 agent.codegear.info에 대한 HTTP/HTTPS 처리 및 N8N으로의 리버스 프록시를 담당합니다.내용을 붙여넣은 후 ecs를 누르고 :wq! 엔터를 입력하여 저장하고 종료합니다.
    server {
        listen 80;
        listen [::]:80;
        server_name agent.codegear.info;
    
        # Certbot will use this location to verify domain ownership
        location /.well-known/acme-challenge {
            allow all;
            root /usr/share/nginx/html; # Ensure this directory exists and is readable by Nginx
        }
    }
  3. Certbot 실행 (필수): 위 Nginx 설정 파일은 agent.codegear.info에 대한 SSL 인증서가 /etc/letsencrypt/live/agent.codegear.info/ 경로에 있다고 가정합니다. 이 인증서는 Certbot을 실행해야 발급됩니다.
    • Certbot이 agent.codegear.info 도메인을 인식하고, 해당 도메인에 대한 SSL 인증서를 발급받은 후, agent.codegear.info.conf 파일 내의 ssl_certificate와 ssl_certificate_key 경로를 자동으로 채우거나 확인해 줍니다.
    • HTTP 트래픽을 HTTPS로 리디렉션할지 물으면 2: Redirect를 선택하는 것이 좋습니다.
      sudo certbot --nginx -d agent.codegear.info
      
  4. Nginx 설정 테스트 및 재시작: 이제 새로운 설정 파일이 올바른지 확인하고 Nginx를 다시 시작하여 변경 사항을 적용합니다.sudo nginx -t 명령어가 syntax is ok와 test is successful을 반환해야 합니다.
    sudo nginx -t          # Nginx 설정 파일 문법 검사
    sudo systemctl restart nginx # Nginx 서비스 재시작
    

     

     

  5. Certbot이 설정 파일에 SSL 관련된 셋팅을 자동으로 추가했으므로 이부분에 n8n이 사용하는 5678 포트로 redirect 처리가 필요합니다. 아래 내용을 ssl 아래에 추가하면 됩니다.
	# --- Proxy headers for N8N ---
    # Ensures N8N gets correct client IP, protocol, and host information.
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header Host $http_host;

    # --- WebSocket support for N8N UI ---
    # Crucial for N8N's real-time updates and interactive UI.
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";

    # --- Reverse proxy to N8N  ---
    location / {
        proxy_pass http://localhost:5678/; # <-- Updated N8N internal port
        proxy_http_version 1.1;
        proxy_buffering off;
        proxy_read_timeout 300s;  # Increased timeout for long-running workflows
        proxy_send_timeout 300s;
    }
  • 전체 설정 파일은 다음과 같습니다.
# --- HTTP Block: Handles HTTP requests and redirects to HTTPS ---
server {
    listen 80;
    listen [::]:80; # IPv6 listening
    server_name agent.codegear.info;

    # Certbot's domain validation challenge location.
    # This must be present in the HTTP block to allow Certbot to renew certificates.
    location ~ /.well-known/acme-challenge {
        allow all;
        root /usr/share/nginx/html; # Ensure this path is correct and accessible
    }

    # All other HTTP requests are permanently redirected to HTTPS.
    # Certbot usually inserts/modifies this.
    return 301 https://$host$request_uri;
}

# --- HTTPS Block: Handles secure (HTTPS) requests and proxies to N8N ---
server {
    listen 443 ssl;
    listen [::]:443 ssl; # IPv6 listening
    http2 on; # Correct way to enable HTTP/2

    server_name agent.codegear.info;

    # --- Let's Encrypt (Certbot) managed SSL certificate paths ---
    # These paths are filled in by Certbot after successful certificate issuance.
    ssl_certificate /etc/letsencrypt/live/agent.codegear.info/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/agent.codegear.info/privkey.pem;
    include /etc/letsencrypt/options-ssl-nginx.conf; # Certbot's recommended SSL options
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # Diffie-Hellman parameters for stronger security

    # --- Proxy headers for N8N ---
    # Ensures N8N gets correct client IP, protocol, and host information.
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header Host $http_host;

    # --- WebSocket support for N8N UI ---
    # Crucial for N8N's real-time updates and interactive UI.
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";

    # --- Reverse proxy to N8N  ---
    location / {
        proxy_pass http://localhost:5678/; # <-- Updated N8N internal port
        proxy_http_version 1.1;
        proxy_buffering off;
        proxy_read_timeout 300s;  # Increased timeout for long-running workflows
        proxy_send_timeout 300s;
    }

    # Optional: Error pages
    # error_page 404 /404.html;
    # location = /404.html { }
    # error_page 500 502 503 504 /50x.html;
    # location = /50x.html { }
}

최종 확인:

이렇게 하면 기존 codegear.info 설정에 영향을 주지 않으면서 agent.codegear.info 서브도메인을 통해 n8n에 안전하게 접근할 수 있습니다.
 
 

반응형
반응형

 

최근 제가 가장 관심있게 보고 있는게 n8n입니다.

n8n은 Workflow를 자동화하는 솔루션입니다.

워크플로우 자동화 솔루션은 이전에도 많이 있었습니다.

하지만 n8n이 기존 솔루션들과 다른점이 하나 있습니다.

바로 AI Agent를 사용할 수 있다는 점입니다.

n8n 워크플로우 샘플

AI Agent는 LLM을 연결하여 질문과 수행을 판단할 수 있게 하는 역할을 합니다.

즉, Workflow 중간에 LLM이 개입해서 업무를 판단하고 처리할 수 있다는 뜻입니다.

이게 엄청난 매력으로 작용하게 됩니다.

 

이 n8n에 대해 알아보도록 하겠습니다.

 

N8N이란 무엇인가요?

n8n은 무엇인가?

N8N (엔에잇엔)은 "노드 기반의 워크플로우 자동화 도구"입니다. 코딩 없이도 다양한 웹 서비스와 애플리케이션을 연결하여 복잡한 자동화 작업을 만들 수 있도록 도와주는 오픈소스 플랫폼입니다.

쉽게 말해, 레고 블록처럼 생긴 "노드(Node)"들을 연결해서 원하는 작업을 순서대로 쭉 나열하면, N8N이 그 순서에 따라 자동으로 작업을 처리해 주는 방식입니다.

  • 노드 기반(Node-based): 각 서비스나 기능이 하나의 블록(노드)으로 표현되어, 드래그 앤 드롭으로 연결하기만 하면 됩니다. 코드를 직접 작성할 필요가 없어 프로그래밍 초보자도 쉽게 접근할 수 있어요.
  • 오픈소스(Open Source): 누구나 자유롭게 사용하고 수정하며 개선할 수 있습니다. 커뮤니티가 활성화되어 있어 다양한 정보와 도움을 얻기 쉽죠.
  • 자체 호스팅 가능(Self-hostable): AWS 같은 클라우드 서버에 직접 설치하여 운영할 수 있어, 데이터 보안과 비용 효율성 면에서 큰 장점을 가집니다.

 

N8N으로 어떤 자동화를 할 수 있나요?

N8N은 웹훅, API, 데이터베이스, 클라우드 서비스 등 수많은 서비스와 연동할 수 있어 그 활용 범위가 무궁무진합니다. 몇 가지 대표적인 활용 예시를 들어볼게요.

  1. 데이터 수집 및 통합:
    • "새로운 이메일이 오면, 첨부 파일을 구글 드라이브에 저장하고 슬랙으로 알림 보내기"
    • "특정 웹사이트의 데이터를 주기적으로 가져와 스프레드시트에 자동 업데이트하기"
  2. 마케팅 및 영업 자동화:
    • "새로운 리드(잠재 고객)가 CRM(고객 관계 관리) 시스템에 추가되면, 자동으로 환영 이메일 보내고 담당자에게 알림 주기"
    • "유튜브 채널에 새 영상이 올라오면, 자동으로 트위터에 홍보 트윗 작성하기"
  3. 내부 업무 프로세스 자동화:
    • "지라(Jira)에 새로운 티켓이 생성되면, 팀원에게 디스코드 알림 보내고 관련 파일 드롭박스에 자동 생성하기"
    • "매일 아침 특정 데이터베이스에서 리포트를 추출하여 이메일로 발송하기"
  4. AI 에이전트 워크플로우 구축 (CodeGear 시리즈의 핵심!):
    • "사용자의 질문을 OpenAI API로 보내 답변을 생성하고, 그 답변을 슬랙/디스코드/웹사이트에 자동 게시하기"
    • "들어오는 데이터를 분석하여 특정 조건에 맞으면 AI가 요약하고, 관련 액션을 자동으로 트리거하기" (예: 고객 문의 분류 후 AI가 1차 답변 초안 작성)
    • "AI가 생성한 콘텐츠를 구글 시트에 저장하거나, 웹사이트에 자동으로 발행하기"
  5. 소셜 미디어 관리:
    • "인스타그램에 새 게시물이 올라오면, 자동으로 페이스북 페이지에도 동시 발행하기"

 

왜 N8N인가요?

  • 코드 지식 없이도 강력한 자동화:
    • 복잡한 API 연동이나 스크립트 작성 없이도 드래그 앤 드롭만으로 워크플로우를 만들 수 있습니다.
  • 다양한 서비스 연동:
    • 수백 가지의 내장 통합(Integrations)을 제공하며, 웹훅 등을 통해 거의 모든 서비스와 연결할 수 있습니다.
  • 강력한 커스터마이징:
    • 오픈소스이므로 필요에 따라 기능을 확장하거나 직접 노드를 개발할 수도 있습니다.
  • 데이터 주권:
    • 클라우드 서비스에 민감한 데이터를 맡기지 않고, 내 서버에서 직접 관리할 수 있어 안심입니다.

결론

결론적으로 N8N은 코딩 없이도 누구나 자신의 업무와 서비스를 효율적으로 자동화할 수 있도록 돕는 강력한 도구입니다.

특히 AI 시대에 반복적인 작업을 AI에 맡기고, 그 결과를 다른 서비스로 연동하는 등의 복잡한 워크플로우를 구축하는 데 핵심적인 역할을 할 것입니다.


다음 영상에서는 이 강력한 N8N을 여러분의 AWS 서버에 월 0원으로 설치하는 방법을 상세히 알려드릴 예정이니 기대해주세요!

반응형
반응형

https://youtu.be/xXxljxkJy7Y

 

서비스 개발이 완료되면, 이를 서비스 하기 위해서는 서버와 도메인이 필요합니다.

도메인을 싸게 구입하는 방법

AWS에서 도메인을 등록하고 서버를 셋팅해서 도메인 서버를 만드는 방법에 대해 알아봅니다.



인터넷은 보통 IP라는 주소를 사용합니다. 예를들면 111.111.111.111 이런 형식으로 되어 있습니다.
naver.com의 도메인을 whois에서 검색해보면 다음과 같은 결과가 나옵니다.

218.232.110.133 이런 주소를 직접 입력하기는 어려워서 도메인(naver.com과 같은 형태)이란 것을 사용합니다.


이 도메인을 싸게 구입하는 방법과 실 서비스를 위해 AWS에서 도메인을 셋팅하는 방법에 대해 알아보겠습니다.  

 


도메인 구입 (6,000원)

도메인은 AWS에서도 구입이 가능합니다.

하지만 가격 비교를 위해 AWS와 여러 도메인 구입 사이트를 확인해 보겠습니다.


AWS Route53

AWS에서 도메인을 구입하기 위한 서비스는 Route53입니다.
Route53에 들어가면 도메인 등록에 원하는 도메인(codegear)을 입력하고 조회를 합니다.

다음과 같이 검색결과가 나옵니다. codegear.info 기준으로 가격은 $25입니다.


가비아

다음은 대표적인 국내 도메인 사이트인 가비아에서 검색을 해보았습니다.
codegear.info를 이벤트 가격인 6,000원으로 판매하고 있습니다.

https://domain.gabia.com

 

가비아: 대한민국 도메인 점유율 1위

대한민국 100만 도메인 등록 업체

domain.gabia.com

Gabia 도메인 검색


Whois

whois에서 동일하게 검색을 해보았습니다.
codegear.info를 44,000원으로 판매하고 있습니다.

https://domain.whois.co.kr/

 

후이즈 도메인

도메인 등록, 안전한 도메인 연장 관리, 기업 도메인 관리 컨설팅, 강력한 부가서비스 제공

domain.whois.co.kr


GoDaddy

GoDaddy에서는 7,918원에 판매를 하고 있습니다.
https://kr.godaddy.com/

 

나만의 여정 만들기 | GoDaddy KR

온라인에서 성장하는 데 필요한 모든 지원 수단 및 도구인 웹사이트, 도메인, 디지털 및 소셜 마케팅 외에 GoDaddy 가이드를 통해 모든 단계 안내

kr.godaddy.com

1년 이상일 경우는 가격이 비슷하겠지만, 1년 사용료는 가격 차이가 꽤 납니다.
그러니 사이트 별로 꼭 비교하여 구매하시기 바랍니다.


AWS에 도메인 등록하기

Route 53을 DNS 서비스로 사용하고 기존 등록 기관은 유지하는 방법

이 방법은 도메인 등록 기관(예: 가비아, 후이즈, Godaddy 등)은 그대로 유지하되, 해당 도메인의 DNS 관리를 Route 53으로 위임하는 방식입니다.

 

AWS Route 53에서 "호스팅 영역" 생성:

  • AWS 콘솔에 로그인하여 Route 53 서비스로 이동합니다.
  • 왼쪽 메뉴에서 "호스팅 영역"을 선택하고 "호스팅 영역 생성" 버튼을 클릭합니다.
  • "도메인 이름" 필드에 다른 곳에서 구매한 도메인 이름을 정확하게 입력합니다 (예: codegear.info).
  • "유형"은 "퍼블릭 호스팅 영역"으로 선택합니다.
  • "호스팅 영역 생성"을 클릭합니다.

Route 53에서 제공하는 네임서버(NS) 확인:

  • 호스팅 영역이 생성되면 해당 호스팅 영역을 클릭하여 상세 정보를 확인합니다.
  • 여기서 **NS (Name Server)** 유형의 레코드를 찾아 "값/트래픽 라우팅 대상"에 나열된 4개의 네임서버 주소를 확인합니다. 이 주소들이 바로 Route 53이 해당 도메인의 DNS 관리를 위해 제공하는 고유한 네임서버입니다. (예: `ns-xxxx.awsdns-xx.com.`, `ns-xxxx.awsdns-xx.net.`, `ns-xxxx.awsdns-xx.org.`, `ns-xxxx.awsdns-xx.co.uk.`)
  • **주의:** 네임서버 주소 마지막에 있는 온점(`.`)은 제외하고 복사합니다.

기존 도메인 등록 기관에서 네임서버 변경:

  • 도메인을 구매했던 등록 기관(예: 가비아, 후이즈 등) 웹사이트에 로그인합니다.
  • 도메인 관리 또는 네임서버 변경 메뉴로 이동합니다.
  • 기존에 설정되어 있던 네임서버를 Route 53에서 복사한 4개의 네임서버 주소로 변경합니다. 등록 기관에 따라 네임서버를 1차, 2차, 3차, 4차 등으로 구분하여 입력하는 칸이 있을 수 있습니다. 각 칸에 맞게 입력합니다.
  • 변경 사항을 저장합니다.
  • 주의사항:
    • 네임서버 변경은 전파(Propagation)되는 데 최대 48시간이 소요될 수 있습니다. 이 기간 동안 도메인 접속이 불안정할 수 있습니다. (경험상 이렇게까지 걸리지 않습니다. 보통 1시간 정도면 대부분 전파가 됩니다)
    • DNS 레코드를 추가할 때 TTL(Time To Live) 값을 적절히 설정해야 합니다. 값이 낮을수록 DNS 변경 사항이 빠르게 적용되지만, DNS 서버에 부하를 줄 수 있습니다. 일반적으로 웹사이트 연결에는 300초(5분) ~ 3600초(1시간) 정도가 적당합니다.
    • 네임서버 전파 상태는 아래 사이트에서 확인할 수 있습니다.
      https://www.whatsmydns.net/
 

DNS Propagation Checker - Global DNS Checker Tool

Instant DNS Propagation Check. Global DNS Propagation Checker - Check DNS records around the world.

www.whatsmydns.net


AWS에 서버 셋팅하기

AWS 프리 티어 EC2 인스턴스 설정 (Amazon Linux 2023)

프리 티어 핵심 요약:

  • 기간: AWS 계정 생성 후 12개월 동안 제공.
  • 인스턴스 유형: `t2.micro` 또는 `t3.micro` (일부 리전에서 제공)만 프리 티어 적용. (이 중 하나만 선택!)
  • 사용 시간: 월별 최대 750시간. (예: `t2.micro` 1개를 한 달 내내 켜두면 약 730시간이므로 프리 티어 범위 내.) 만약 `t2.micro` 2개를 동시에 사용하면 375시간(750/2)만 무료가 되므로 주의!
  • 스토리지 (EBS): 총 30GB까지 무료 (GP2 또는 마그네틱). 여러 인스턴스에 걸쳐 총합 30GB입니다.
  • 네트워크: 퍼블릭 IPv4 주소 (탄력적 IP 포함) 사용 시 **월 750시간 무료** (2024년 2월 1일 이후 유료화되었지만, 프리 티어 사용자는 월750시간까지 무료).

단계별 설정 방법:

1. AWS 계정 로그인 및 리전 선택:

  • AWS 콘솔(console.aws.amazon.com)에 로그인합니다.
  • 가장 중요! 화면 우측 상단에서 원하는 리전(Region)을 선택합니다. 보통 서울 리전(ap-northeast-2)을 많이 사용하지만, 사용 목적에 따라 다른 리전을 선택할 수 있습니다. (리전을 잘못 선택하면 나중에 인스턴스를 못 찾을 수 있어요!)

2. EC2 서비스로 이동:

  • 검색창에 "EC2"를 입력하거나, 서비스 목록에서 "EC2"를 클릭합니다.
  • EC2 대시보드에서 "인스턴스 시작" 버튼을 클릭합니다.

3. 인스턴스 이름 및 태그 지정:

  • 이름 및 태그: 인스턴스에 식별하기 쉬운 이름을 입력합니다. (예: `MyNginxServer`, `AutoBlogInstance`)
  • (선택 사항) 필요에 따라 태그를 추가할 수 있습니다.

4. 애플리케이션 및 OS 이미지(AMI) 선택:

  • Amazon Machine Image (AMI): 서버의 운영체제(OS)를 선택하는 단계입니다.
  • "프리 티어 사용 가능" 라벨이 붙은 AMI를 선택해야 합니다.
  • "Amazon Linux 2023 AMI"를 선택합니다. (이전 버전인 Amazon Linux 2와 헷갈리지 마세요!)

5. 인스턴스 유형 선택:

  • 인스턴스 유형: 서버의 성능을 결정합니다.
  • "프리 티어 사용 가능" 라벨이 붙은 `t2.micro` (또는 일부 리전에서는 `t3.micro`)를 선택합니다. 다른 유형을 선택하면 바로 요금이 부과될 수 있으니 반드시 확인하세요!


6. 키 페어(로그인) 생성 또는 선택:

  • 키 페어(로그인): SSH로 인스턴스에 접속하기 위한 인증 키입니다. 없다면 새로 생성해야 합니다.
  • "새 키 페어 생성"을 클릭합니다.
  • 키 페어 이름: 원하는 이름을 입력합니다. (예: `my-ec2-key`)
  • 키 페어 유형: `RSA`를 선택합니다. (더 나은 보안을 위해 `ED25519`도 좋지만, `RSA`가 일반적이고 호환성이 높습니다.)
  • 프라이빗 키 파일 형식: `PEM`을 선택합니다. (PuTTY를 사용하는 경우 `PPK`로 변환해야 하지만, `PEM`이 일반적인 리눅스/macOS 터미널 접속에 용이합니다.)
  • "키 페어 생성" 버튼을 클릭하면 `.pem` 파일이 자동으로 다운로드됩니다. **이 파일은 절대로 잃어버리거나 남에게 노출해서는 안 됩니다! 안전한 곳에 보관하세요. (이 키 없이는 인스턴스에 다시 접근할 수 없습니다.)

7. 네트워크 설정 (보안 그룹):

  • 네트워크 설정: 인스턴스의 네트워크 규칙(방화벽)을 설정하는 부분입니다.
  • "편집" 버튼을 클릭하여 세부 설정을 변경합니다.
  • 보안 그룹 (Security Group):
    • "보안 그룹 생성"을 선택합니다. (기존 보안 그룹이 있다면 선택해도 되지만, 처음이라면 새로 생성하는 것이 좋습니다.)
    • 보안 그룹 이름: 식별하기 쉬운 이름을 지정합니다. (예: `web-server-sg`)
    • 설명: 간단한 설명을 추가합니다. (예: `Web server security group for HTTP/HTTPS/SSH`)
    • 인바운드 보안 그룹 규칙:
      • 규칙 추가 클릭:
        • 유형: `SSH` (포트 22) - 인스턴스에 터미널로 접속하기 위해 필수입니다.
        • 소스 유형: `내 IP` (현재 접속한 IP에서만 허용) 또는 `어디서나(0.0.0.0/0)` (모든 IP에서 접속 허용 - **보안에 취약**하니 신중하게 선택하세요. 개인 서버라면 `내 IP`가 좋습니다.)
      • 규칙 추가 클릭:
        • 유형: `HTTP` (포트 80) - 웹사이트 접속을 위해 필수입니다.
          소스 유형: `어디서나(0.0.0.0/0)` (모든 곳에서 웹사이트 접속 허용)
          규칙 추가 클릭:
          유형: `HTTPS` (포트 443) - SSL/TLS 웹사이트 접속을 위해 필수입니다.
        • 소스 유형: `어디서나(0.0.0.0/0)`
      • (필요한 경우, 다른 포트(예: n8n의 기본 포트 5678)도 여기서 추가할 수 있습니다.)
  • 스토리지 구성:
    • 스토리지: 인스턴스의 하드 디스크 용량입니다.
    • 크기(GiB): 30 GiB로 설정합니다. (프리 티어 최대 용량입니다. 초과하면 과금됩니다.)
    • 볼륨 유형: `gp2` (범용 SSD) 또는 `Standard` (마그네틱)를 선택합니다. (`gp3`도 프리 티어에 포함될 수 있으나, `gp2`가 가장 보편적입니다.)
    • (스냅샷, 암호화 등은 필요에 따라 설정하며, 일반적으로 기본값을 유지합니다.)

9. 고급 세부 정보 (선택 사항):

  • 고급 세부 정보: 대부분의 경우 기본값을 유지해도 됩니다.
  • 퍼블릭 IP 자동 할당: "활성화"로 되어 있는지 확인합니다. (기본적으로 활성화되어 있습니다. 그래야 인스턴스 생성 후 바로 퍼블릭 IP를 받을 수 있습니다.)
  • (IAM 역할, 종료 방지 등은 필요에 따라 설정합니다.)

10. 요약 및 인스턴스 시작:

  • 우측 "요약" 패널에서 지금까지 설정한 내용을 최종적으로 검토합니다. 특히 AMI, 인스턴스 유형, 스토리지, 보안 그룹 규칙이 프리 티어 기준에 맞는지 다시 한번 확인합니다.
  • "인스턴스 시작" 버튼을 클릭합니다.

11. 인스턴스 시작 완료 및 접속:

  • 인스턴스 시작이 완료되면 "모든 인스턴스 보기"를 클릭하여 인스턴스 목록으로 이동합니다.
  • 새로 생성된 인스턴스의 **상태 검사**가 `초기화`에서 `2/2 검사 통과`로 바뀔 때까지 잠시 기다립니다.
  • 인스턴스를 선택하고 하단 상세 정보에서 **퍼블릭 IPv4 주소**를 확인합니다.

탄력적 IP (고정IP) - 12개월 무료

  • 과거에는 탄력적 IP가 실행 중인 EC2 인스턴스에 연결되어 있으면 무료였습니다.
  • 하지만 2024년 2월 1일부터는 실행 중인 EC2 인스턴스에 연결된 첫 번째 탄력적 IP 주소시간당 $0.005 USD의 요금이 부과됩니다.
  • 예외: AWS Free Tier 사용자는 계정 생성 후 12개월 동안 월 750시간의 퍼블릭 IPv4 주소 사용이 무료로 제공됩니다.

AWS에서 탄력적 IP(Elastic IP) 추가 및 연결 방법

  1. EC2 대시보드 이동:
    • 검색창에 "EC2"를 입력하여 EC2 서비스 대시보드로 이동합니다.
  2. 올바른 리전(Region) 선택 확인:
    • 화면 우측 상단에서 현재 작업 중인 EC2 인스턴스가 위치한 리전이 올바르게 선택되어 있는지 반드시 확인합니다. 탄력적 IP는 리전별로 할당됩니다.
  3. 탄력적 IP 대시보드로 이동:
    • EC2 대시보드 왼쪽 메뉴에서 "네트워크 및 보안(Network & Security)" 아래에 있는 "탄력적 IP(Elastic IPs)"를 클릭합니다.
  4. 새 탄력적 IP 주소 할당:
    • "탄력적 IP(Elastic IPs)" 페이지에서 상단의 "탄력적 IP 주소 할당(Allocate Elastic IP address)" 버튼을 클릭합니다.
  5. IP 주소 설정 확인:
    • 대부분의 경우, 별도의 설정을 변경할 필요 없이 기본 옵션(Amazon 풀의 IPv4 주소)을 유지하면 됩니다.
    • "할당(Allocate)" 버튼을 클릭합니다.
    • 성공적으로 할당되면 새로운 탄력적 IP 주소가 "탄력적 IP" 목록에 추가된 것을 확인할 수 있습니다.
  6. 할당된 탄력적 IP를 EC2 인스턴스에 연결 (Associate):
    • 목록에서 방금 할당받은 새 탄력적 IP 주소를 선택합니다.
    • 상단 "작업(Actions)" 드롭다운 메뉴를 클릭합니다.
    • "탄력적 IP 주소 연결(Associate Elastic IP address)"을 선택합니다.
  7. 연결할 인스턴스 선택:
    • "리소스 유형(Resource type)" 드롭다운에서 "인스턴스(Instance)"를 선택합니다.
    • "인스턴스(Instance)" 드롭다운에서 탄력적 IP를 연결하고자 하는 실행 중인 EC2 인스턴스를 선택합니다. (인스턴스가 중지되어 있으면 목록에 표시되지 않을 수 있습니다.)
    • "프라이빗 IP 주소(Private IP address)"는 일반적으로 선택한 인스턴스의 기본 프라이빗 IP 주소가 자동으로 채워집니다. 변경할 필요 없습니다.
    • "연결(Associate)" 버튼을 클릭합니다.
  8. 연결 확인:
    • 연결이 성공하면 "탄력적 IP" 목록에서 해당 IP 주소 옆에 "연결된 인스턴스 ID"가 표시됩니다.
    • EC2 대시보드의 "인스턴스(Instances)" 메뉴로 돌아가서 해당 인스턴스를 클릭합니다. 인스턴스 상세 정보의 "세부 정보(Details)" 탭에서 "탄력적 IP 주소(Elastic IP address)" 항목에 방금 연결한 IP 주소가 표시되는 것을 확인할 수 있습니다.

도메인을 서버에 연결

Route 53 호스팅 영역에 DNS 레코드 추가:

  • 이제 원하는 AWS 서비스(예: EC2, S3, Amplify 등)에 트래픽을 라우팅하기 위한 레코드를 Route 53 호스팅 영역에 추가해야 합니다.
  • 웹사이트 연결 (탄력적 IP 주소 사용):
    • "레코드 생성"을 클릭합니다.
    • "레코드 이름": `www` 또는 비워두면 도메인 자체를 의미합니다.
    • "레코드 유형": `A - IPv4 주소 및 일부 AWS 리소스로 트래픽 라우팅`을 선택합니다.
    • "값": 연결하고자 하는 EC2 인스턴스의 탄력적 IP 주소를 입력합니다.
    • "라우팅 정책": "단순 라우팅"을 선택합니다.
    • "레코드 생성"을 클릭합니다.
  • Load Balancer, S3 버킷, CloudFront 등 연결:
    • "레코드 유형": `A` 또는 `AAAA`를 선택한 후 "별칭"을 "예"로 설정하고 연결하려는 AWS 리소스를 선택합니다. (Load Balancer, S3 웹사이트 호스팅, CloudFront 배포 등은 별칭 레코드를 통해 쉽게 연결할 수 있습니다.)
  • 서브 도메인 연결 (CNAME):
    • `blog.mydomain.com`과 같은 서브 도메인을 연결하려면 "레코드 유형"을 `CNAME`으로 선택하고 "값"에 대상 도메인 이름을 입력합니다.

AWS EC2에 Nginx 설치하기

SSH로 EC2 인스턴스에 접속하기:

1. 터미널 (macOS/Linux) 또는 PuTTY (Windows) 준비:

  • macOS/Linux: 터미널을 엽니다.
  • Windows: PuTTY 또는 Windows Terminal에서 OpenSSH 클라이언트를 사용할 수 있습니다. PuTTY를 사용하려면 `pem` 파일을 `ppk` 파일로 변환해야 합니다 (`PuTTYgen` 사용).

2. `.pem` 키 파일 권한 설정 (Linux/macOS):

  • 다운로드한 `.pem` 파일이 있는 디렉토리로 이동합니다.
  • 파일 권한을 변경합니다. (매우 중요! 권한이 없으면 접속 불가.)
chmod 400 your_key_pair_name.pem


3. SSH 접속:

  • 터미널에서 다음 명령어를 입력합니다.
ssh -i "your_key_pair_name.pem" ec2-user@your_instance_public_ip

 

  • `your_key_pair_name.pem`: 다운로드한 키 페어 파일의 이름
  • `ec2-user`: Amazon Linux의 기본 사용자 이름입니다. (Ubuntu는 `ubuntu`, CentOS는 `centos` 또는 `ec2-user` 등 OS마다 다를 수 있습니다.)
  • `your_instance_public_ip`: EC2 콘솔에서 확인한 인스턴스의 퍼블릭 IPv4 주소
  • 처음 접속 시 "Are you sure you want to continue connecting (yes/no/[fingerprint])?" 메시지가 나오면 `yes`를 입력합니다.

 

이제 EC2 인스턴스에 성공적으로 접속하여 원하는 작업을 수행할 수 있습니다!

 

Nginx 설치 및 셋팅

1. 패키지 목록 업데이트

설치 전 최신 패키지 정보를 가져오기 위해 시스템을 업데이트합니다.

sudo dnf update -y

(-y 옵션은 모든 질문에 "예"로 자동 응답하여 설치 과정을 자동화합니다.)

 

2. Nginx 설치

이제 dnf 명령어를 사용하여 Nginx를 설치합니다.

sudo dnf install nginx -y

 

3. Nginx 서비스 시작 및 활성화

Nginx 설치가 완료되면, 서비스를 시작하고 서버 재부팅 시 자동으로 시작되도록 설정합니다.

sudo systemctl start nginx
sudo systemctl enable nginx

 

4. Nginx 서비스 상태 확인

Nginx가 올바르게 실행 중인지 확인합니다.

sudo systemctl status nginx

"active (running)"이라는 메시지가 보이면 Nginx가 정상적으로 실행되고 있는 것입니다.

 

5. 방화벽 설정 (선택 사항)

Amazon Linux 2023은 기본적으로 firewalld가 설치되어 있지 않을 수 있습니다. 만약 방화벽을 사용하고 있다면, HTTP (80번 포트) 및 HTTPS (443번 포트) 트래픽을 허용하도록 설정해야 합니다.

  • firewalld 설치 (필요한 경우):
    sudo dnf install firewalld -y
    sudo systemctl start firewalld
    sudo systemctl enable firewalld
    
  • HTTP 및 HTTPS 포트 열기:
    sudo firewall-cmd --permanent --add-service=http
    sudo firewall-cmd --permanent --add-service=https
    sudo firewall-cmd --reload
    

6. 보안 그룹 설정 (AWS EC2에서 필수)

EC2 인스턴스 생성할때 보안 그룹(Security Group)을 이미 오픈했습니다.

HTTP (80번 포트) 및 HTTPS (443번 포트) 인바운드 규칙으로 외부에서 Nginx 웹 서버에 접속할 수 있습니다.

 

7. Nginx 기본 페이지 확인

웹 브라우저를 열고 EC2 인스턴스의 퍼블릭 IP 주소 또는 퍼블릭 DNS를 입력합니다. http://your-instance-ip

정상적으로 설치되었다면 Nginx의 기본 환영 페이지가 표시될 것입니다.

이제 Amazon Linux 2023에 Nginx가 성공적으로 설치되었으며, 웹 서버로 사용할 준비가 완료되었습니다. Nginx 설정 파일은 /etc/nginx/nginx.conf에 있으며, 가상 호스트 설정 등은 /etc/nginx/conf.d/ 디렉토리에 .conf 파일을 생성하여 관리하는 것이 일반적입니다.

 

Nginx SSL 적용하기

Nginx에 SSL/TLS를 적용하여 HTTPS를 사용하면 웹사이트의 보안을 강화하고 사용자 데이터를 보호할 수 있습니다. 가장 일반적이고 권장되는 방법은 Let's Encrypt에서 무료 SSL 인증서를 발급받고, Certbot 도구를 사용하여 Nginx에 자동으로 적용하는 것입니다.

Amazon Linux 2023 환경에서 Certbot을 사용하여 Nginx에 SSL을 적용하는 단계를 안내해 드리겠습니다.

준비물:

  1. 도메인: SSL을 적용할 도메인 이름 (예: example.com).
  2. DNS 설정: 해당 도메인이 Nginx 서버의 퍼블릭 IP 주소를 가리키도록 DNS A 레코드가 설정되어 있어야 합니다. (설치 전 필수)
  3. Nginx 설치 및 실행: 앞서 설명한 대로 Nginx가 Amazon Linux 2023에 설치되어 실행 중이어야 합니다.
  4. 보안 그룹 및 방화벽: AWS EC2 인스턴스의 보안 그룹에서 HTTP (80번 포트)  HTTPS (443번 포트) 인바운드 규칙이 열려 있어야 합니다.

Nginx SSL 적용 (Certbot 사용):

1. Certbot 설치

Certbot은 Let's Encrypt 인증서를 쉽고 자동으로 발급하고 Nginx에 적용할 수 있도록 도와주는 도구입니다. Amazon Linux 2023에서는 dnf를 사용하여 설치할 수 있습니다.

Bash
 
# EPEL(Extra Packages for Enterprise Linux) 저장소 활성화 (Certbot이 EPEL에 있을 수 있습니다)
sudo dnf install epel-release -y

# Certbot 및 Nginx 플러그인 설치
# Amazon Linux 2023에서는 python3-certbot-nginx 대신 python-certbot-nginx 일 수 있습니다.
# 먼저 아래 명령을 시도하고 실패하면 'python-certbot-nginx'로 시도하세요.
sudo dnf install certbot python3-certbot-nginx -y

만약 python3-certbot-nginx가 없다는 오류가 발생하면, python-certbot-nginx로 다시 시도하거나, Certbot 공식 웹사이트에서 제공하는 Amazon Linux용 설치 지침을 확인하는 것이 가장 좋습니다. (현재 시간 기준으로는 python3-certbot-nginx가 일반적입니다.)

 

2. Nginx 설정 확인

Certbot이 Nginx 설정을 자동으로 수정하려면, Nginx가 올바르게 구성되어 있어야 합니다. 특히, 도메인 이름이 server_name 지시문에 명시되어 있어야 합니다.

기본 설정 파일은 /etc/nginx/nginx.conf 또는 /etc/nginx/conf.d/default.conf에 있을 수 있습니다. 예를 들어, default.conf 파일을 열어 편집합니다.

sudo vi /etc/nginx/nginx.conf
# 또는
sudo vi /etc/nginx/conf.d/default.conf

http 블록 내에 다음과 유사한 server 블록이 있는지 확인합니다 (아직 HTTPS 설정은 하지 않습니다):

server {
    listen 80;
    server_name your_domain.com www.your_domain.com; # 여기에 실제 도메인 이름을 입력하세요
    # 기타 설정 (root, index, location 등)
    # ...
}

변경 사항을 저장하고 Nginx 설정 구문이 올바른지 확인합니다.

sudo nginx -t

syntax is ok와 test is successful 메시지가 표시되어야 합니다.

Nginx를 다시 로드합니다.

sudo systemctl reload nginx

 

3. SSL 인증서 발급

이제 Certbot을 사용하여 Let's Encrypt 인증서를 발급받고 Nginx에 적용합니다.

sudo certbot --nginx

이 명령을 실행하면 Certbot이 몇 가지 질문을 할 것입니다:

  • 이메일 주소: 인증서 갱신 알림 및 보안 관련 통지를 받을 이메일 주소를 입력합니다.
  • 서비스 약관 동의: 약관에 동의합니다.
  • 도메인 선택: Certbot이 Nginx 설정에서 감지한 도메인 목록이 표시됩니다. SSL을 적용할 도메인 번호를 선택하거나 all을 입력하여 모두 적용합니다.
    • 예시: 1: your_domain.com 2: www.your_domain.com 원하는 도메인 번호를 쉼표로 구분하여 입력하거나, 1,2와 같이 입력할 수 있습니다.
  • HTTP -> HTTPS 리디렉션 설정: Certbot이 HTTP(80번 포트)로 들어오는 모든 요청을 HTTPS(443번 포트)로 자동으로 리디렉션할지 물어봅니다. **"2: Redirect"**를 선택하는 것이 좋습니다.

성공적으로 완료되면 Certbot이 인증서가 발급되었고 Nginx 설정이 업데이트되었다는 메시지를 표시합니다. 인증서는 /etc/letsencrypt/live/your_domain.com/ 경로에 저장됩니다.

 

4. Nginx 설정 자동 업데이트 확인

Certbot이 Nginx 설정 파일 (예: /etc/nginx/conf.d/default.conf 또는 새로운 설정 파일)을 자동으로 수정합니다. 변경된 내용은 다음과 유사할 것입니다:

server {
    listen 80;
    server_name your_domain.com www.your_domain.com;
    return 301 https://$host$request_uri; # HTTP -> HTTPS 리디렉션
}

server {
    listen 443 ssl http2; # HTTPS (443) 포트 및 HTTP/2 활성화
    server_name your_domain.com www.your_domain.com;

    ssl_certificate /etc/letsencrypt/live/your_domain.com/fullchain.pem; # 전체 인증서 체인
    ssl_certificate_key /etc/letsencrypt/live/your_domain.com/privkey.pem; # 개인 키
    include /etc/letsencrypt/options-ssl-nginx.conf; # Certbot이 제공하는 보안 설정
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # DH 매개변수 (보안 강화)

    # 기타 설정 (root, index, location 등)
    # ...
}

 

5. SSL 적용 확인

웹 브라우저를 열고 https://your_domain.com으로 접속하여 자물쇠 아이콘이 표시되고 웹사이트가 정상적으로 로드되는지 확인합니다. 또한 http://your_domain.com으로 접속했을 때 자동으로 https://로 리디렉션되는지도 확인합니다.

 

6. 인증서 자동 갱신 확인

Let's Encrypt 인증서는 90일마다 갱신해야 합니다. Certbot은 일반적으로 시스템에 cron job 또는 systemd timer를 자동으로 설정하여 인증서가 만료되기 전에 갱신되도록 합니다.

다음 명령어로 자동 갱신 시뮬레이션을 실행하여 제대로 작동하는지 확인할 수 있습니다.

sudo certbot renew --dry-run

이 명령이 오류 없이 실행되면 자동 갱신이 잘 설정된 것입니다.


이렇게 하면 모든 셋팅이 완료되고 브라우저에 도메인을 입력하면 다음과 같은 화면을 볼 수 있습니다.

 

 

앞으로는 이 도메인을 기반으로 여러 가지 사이트들을 만드는 과정도 진행할 예정입니다.

반응형
반응형

AWS Code Pipeline을 사용해서 Build시 다음과 같은 오류가 발생하는 경우가 있습니다.

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed 
- JavaScript heap out of memory

 

문제 해결을 위해 검색을 해보면 대부분 아래와 같이 heap memory 옵션을 추가하라고 나옵니다.

export NODE_OPTIONS="--max-old-space-size=8192"

 

하지만 이 옵션의 경우 AWS 빌드 컨테이너의 메모리 사이즈가 이것보다 클 경우만 사용 가능한 옵션입니다.

즉, 기본적으로 빌드 컨테이너의 메모리가 부족하면 이것을 늘려도 소용이 없다는 뜻입니다.

 

이 경우 빌드 컨테이너의 메모리를 늘려서 문제를 해결할 수 있습니다.

AWS 콘솔에서 Code Build - Build Project 메뉴에 들어가서 프로젝트를 선택하면 설정된 메모리를 보실 수 있습니다.

편집 버튼을 클릭하면 메모리 사이즈를 변경할 수 있습니다.

반응형
반응형

AWS의 S3에 이미지를 올리면 자동으로 썸네일을 만들어 주는 람다에 대해 설명합니다.

다음은 이글의 유튜브 강의입니다.

https://youtu.be/fMtNmmtlLig


홈페이지에 갤러리 기능을 만들게 되면 꼭 필요한게 이미지의 썸네일 입니다.

이미지를 업로드 할때마다 썸네일을 별도로 제작하기는 너무 귀찮은 작업이죠.

이럴때 AWS의 람다를 사용하면 썸네일을 자동으로 생성할 수 있습니다.

 

해당 내용은 AWS 공식 홈페이지에 자세하게 설명이 되어 있습니다.

https://docs.aws.amazon.com/ko_kr/lambda/latest/dg/with-s3-tutorial.html

 

자습서: Amazon S3 트리거를 사용하여 썸네일 이미지 생성 - AWS Lambda

자습서: Amazon S3 트리거를 사용하여 썸네일 이미지 생성 이 자습서에서는 Lambda 함수를 생성하고 Amazon Simple Storage Service(Amazon S3)에 대한 트리거를 구성합니다. Amazon S3는 S3 버킷에 업로드된 각 이

docs.aws.amazon.com

해당 내용을 기반으로 썸네일 자동 생성 기능을 만들어 봅니다.

 

순서는 다음과 같습니다.

1. AWS CLI 설치

2. 버킷 생성

3. IAM 역할(Role) 생성

4. 리사이즈용 프로그램 개발(Python)

5. 프로젝트 빌드

6. 배포

7. S3 트리거 생성

8. 테스트

 

1. AWS CLI 설치

간단한 파이썬 코드를 작성할 경우에는 AWS 콘솔에서도 파이썬 라이브러리가 포함되어 있기 때문에 작업이 가능하지만,

이미지 썸네일을 만드는 경우에는 pillow라는 라이브러리를 사용해야 하므로 콘솔에서는 처리가 어렵습니다.

따라서 로컬에서 라이브러리를 다운받아 서버에 배포하는 과정이 필요합니다.

 

로컬에서 람다 패키지를 만들어 서버에 배포하기 위해서는 AWS CLI를 사용합니다.

다음 URL에 각OS별 설치 방법에 따라 설치를 합니다.

https://docs.aws.amazon.com/ko_kr/cli/latest/userguide/getting-started-install.html

 

최신 버전의 AWS CLI 설치 또는 업데이트 - AWS Command Line Interface

이전 버전에서 업데이트하는 경우 unzip 명령을 실행하면 기존 파일을 덮어쓸지 묻는 메시지가 표시됩니다. 스크립트 자동화와 같은 경우에 이러한 프롬프트를 건너뛰려면 unzip에 대한 -u 업데이

docs.aws.amazon.com

 

2. 버킷 생성

AWS 콘솔에 로그인해서 S3 서비스에서 버킷을 만들어 줍니다. (기존 버킷을 사용해도 됨)

 

저는 다음과 같이 버킷을 생성하였습니다.

  • codegear-slider-bucket

 

다음과 같이 폴더를 2개 생성합니다.

  • images : 이미지 업로드용 폴더
  • resized-images : 썸네일 자동 생성 이미지 저장용 폴더

 

3. IAM 역할(Role) 생성

AWS 콘솔의 IAM으로 이동.

액세스 관리 - 역할(Role) 메뉴로 이동하여 "역할 만들기"를 클릭.

  • Role Name : S3_Image_Resize

권한 정책에는 다음 3가지를 추가합니다.

  • AmazonS3FullAccess (S3 Access 권한)
  • AWSLambdaBasicExecutionRole (Clowd Watch 로그 작성 권한)
  • AWSLambda_FullAccess (Lambda Access 권한)

 

4. 리사이즈용 프로그램 개발(Python)

로컬환경에서 이미지 리사이즈용 파이썬 프로젝트를 생성합니다.

lambda-s3-python 폴더를 생성하고 생성된 폴더로 이동합니다.

  • lambda_function.py로 파이썬 소스 파일을 생성합니다.

다음과 같이 코드를 생성합니다.

import boto3
import os
import sys
import uuid
from urllib.parse import unquote_plus
from PIL import Image
import PIL.Image

s3_client = boto3.client('s3')

def resize_image(image_path, resized_path):
  base_width = 300
  with Image.open(image_path) as image:
    w_percent = (base_width/float(image.size[0]))
    h_size = int((float(image.size[1])*float(w_percent)))
    image = image.resize((base_width,h_size), Image.ANTIALIAS)
    image.save(resized_path)

def lambda_handler(event, context):
  for record in event['Records']:
    bucket = record['s3']['bucket']['name']
    key = unquote_plus(record['s3']['object']['key'])
    tmpkey = key.replace('/', '')
    download_path = '/tmp/{}{}'.format(uuid.uuid4(), tmpkey)
    upload_path = '/tmp/resized-{}'.format(tmpkey)
    s3_client.download_file(bucket, key, download_path)
    resize_image(download_path, upload_path)
    s3_client.upload_file(upload_path, '{}'.format(bucket), 'resized-{}'.format(key))

pillow 파이썬 라이브러리를 package 폴더에 설치합니다.

pip install --target ./package pillow

template.yaml 파일을 루트폴더에 생성합니다.

AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31
Resources:
  CreateThumbnail:
    Type: AWS::Serverless::Function
    Properties:
      Handler: lambda_function.lambda_handler
      Runtime: python3.9
      Timeout: 10
      Policies: AWSLambdaExecute
      Events:
        CreateThumbnailEvent:
          Type: S3
          Properties:
            Bucket: !Ref SrcBucket
            Events: s3:ObjectCreated:*

  SrcBucket:
    Type: AWS::S3::Bucket

requirements.txt 파일을 루트폴더에 생성합니다.

Pillow == 9.2.0

 

5. 프로젝트 빌드

다음 명령어로 배포용 패키지를 빌드 합니다.

sam build --use-container

 

6. 배포

서버에 람다 함수를 배포합니다.

sam deploy --guided

 

 

7. S3 트리거 생성

AWS의 Lambda 서비스로 이동.

생성된 Lambda 함수를 클릭 후 함수명 클릭.

함수 개요에서 "트리거 추가"를 클릭합니다.

트리거 구성 아래의 소스 선택에 "S3"를 입력한 후 나타나는 S3를 선택합니다.

버킷을 선택하고, 접두어에는 버킷의 폴더명을, 체크박스를 체크하고 추가를 선택합니다.

아래와 같이 트리거가 추가 된걸 볼 수 있습니다.

8. 테스트

버킷의 images 폴더에 이미지를 업로드 합니다.

resized-images 폴더에 아래와 같이 이미지가 생성된것 볼 수 있습니다.

이미지를 다운받아 속성을 보면 크기가 "300 X 168 픽셀"로 만들어졌음을 볼 수 있습니다.

 

이상으로 AWS의 람다 기능을 이용해서 S3에 업로드된 이미지의 썸네일을 자동으로 만들어 보았습니다.

반응형
반응형

그동안 배웠던 내용들을 이용해서 사이트를 만드는 강좌를 진행합니다.

제목은 Nodejs와 Vuejs로 사이트 만들기 입니다.

 

이 글의 동영상 강좌입니다.

https://youtu.be/9RBeK3U8Z5Y

개발 스펙은 다음과 같습니다.

  • Backend는Nodejs (Nestjs 프레임워크를 사용합니다. TypeORM을 통해 DB를 연동합니다.)
  • Frontend는 Vuejs (Nuxtjs 프레임워크를 사용합니다.)
  • Database는 MySQL을 사용합니다. (MySQL Workbench의 Model 기능을 사용합니다.)

인프라는 다음과 같이 구성합니다.

  • Version Control(코드 저장소)은 Github을 사용합니다.
  • Production(운영) Server는 AWS의 EC2를 사용합니다.
  • Image가 배포될 Server는 AWS의 S3를 사용합니다.

기타

  • 배포는 Github Actions를 이용해서 자동배포가 되도록 구성을 합니다.
  • 로그인 및 회원 가입은 카카오 로그인을 이용해서 처리합니다.

기능

  • 사이트의 첫화면에 Slideshow가 나타나며 자동 스크롤이 됩니다.
  • 이 이미지는 관리자를 통해 관리되도록 합니다.

사이트를 직접 만들면서 각종 기술들이 어떻게 쓰이는지를 알아 갈 수 있도록 하는것이 이 강좌의 목적입니다.

많이 기대해주세요^^

반응형
반응형

다음은 이 글의 유튜브 영상입니다.

https://youtu.be/E3i9qt0SS-I

 

프로젝트를 진행할때 많은 시간을 들여야 하는 것 중에 하나가 바로 배포입니다.

형상관리(Git)에 커밋을 하고, 서버에 파일을 업로드 하고, 서버를 리스타트 하는 과정들을 수작업으로 반복하다 보면 여간 불편한게 아니죠.

이럴때 자동 배포 기능을 만들면 개발 PC에서 커밋하는 것만으로도 배포를 할 수 있습니다. 그럼 나머지 시간들은 다시 개발을 하거나 조금 쉴 수 있는 여유가 생기겠죠?

 

우선 전체적인 구성은 다음과 같습니다.

  1. 로컬 PC에서 개발을 한 후 Github에 Push를 합니다.
  2. Github Repository 특정 branch에 push가 되면 Github Action이 동작을 시작합니다.
  3. Github Actions가 Github Container Registry에 소스를 받은 후 Docker 이미지로 빌드를 합니다.
  4. 빌드된 이미지를 EC2에 등록된 Runner가 복사합니다.
  5. 기존 이미지를 삭제하고 새로운 이미지로 실행을 합니다.

환경

  • 프론트 : Vuejs (Nuxt)
  • 형상관리 : Git (Github)
  • 빌드 : Docker (Github Action)
  • 서버 : Linux (AWS EC2 micro)

* nodejs, git, docker는 기본적으로 설치되어 있어야 합니다.

순서

  • Github 저장소 생성
  • 프로젝트 원격 저장소 클론
  • Nuxt 프로젝트 생성
  • Docker로 로컬 테스트
  • Github Actions
  • AWS EC2 생성 및 Docker 설치
  • 자동 배포 테스트

Github 저장소 생성 및 연결

www.github.com 에서 아래와 같이 저장소를 만듭니다.

  • Repository name은 프로젝트명과 동일하게 생성합니다.
  • Repository는 아무나 사용할 수 없도록 private으로 만듭니다.
  • 주의하실 점은 Owner명에 대문자가 들어가 있으면 안됩니다.
  • Github Action에서 도커빌드시에 대문자를 쓸 수 없다는 오류가 납니다.

프로젝트 원격 저장소 클론

원격 저장소를 local PC로 클론합니다.

  • 저는 github desktop을 이용했습니다.
  • git 명령어 또는 다른 프로그램을 사용하셔도 됩니다.

  • 우측 상단의 아래 화살표를 클릭합니다.

  • 우측 상단의 Add 버튼을 누르고 clone repository를 선택합니다.

 

 

  • Repository를 선택하고 Clone 버튼을 클릭하면 로컬PC에 폴더가 생성됩니다.

 

Vue (Nuxt) 프로젝트 생성

Clone 받은 폴더로 이동한 후 다음과 같이 Nuxt 프로젝트를 생성합니다. 

  • 선택항목은 모두 자동으로 선택합니다.
npx create-nuxt-app nuxt-auto-deploy

프로젝트 생성이 완료되면 생성된 모든 파일을 상위 폴더로 옮겨줍니다.

cd nuxt-auto-deploy
mv * ..

다시 상위 폴더로 이동하여 비어있는 nuxt-auto-deploy 폴더를 삭제합니다.

cd ..
rm -Rf nuxt-auto-deploy

 

다음과 같이 프로젝트를 실행합니다.

npm run dev 또는 yarn dev

실행이 완료되면 브라우저에서 http://localhost:3000으로 실행 화면을 확인할 수 있습니다.

 

확인이 되었으면 ctrl+C 키를 눌러 프로젝트 실행을 종료합니다.

 

Docker로 로컬 테스트

Docker 이미지를 만들기 위해 프로젝트 루트에 Dockerfile을 아래와 같이 생성합니다.

FROM node:14.19.0

RUN mkdir -p /app
WORKDIR /app
ADD . /app/

RUN rm yarn.lock || true
RUN rm package-lock.json || true
RUN yarn
RUN yarn build

ENV HOST 0.0.0.0
EXPOSE 3000

CMD [ "yarn", "start"]
  • FROM node:14.19.0 : nodejs 14.19.0 버전의 이미지를 받아서 docker image를 생성합니다.
  • RUN mkdir -p /app : app 폴더를 생성합니다.
  • ADD . /app/ : 현재 폴더의 모든것을 생성된 app 폴더에 복사합니다.
  • RUN rm ... || true : 파일 삭제. 뒤의 "|| true" 는 파일이 없을 경우 오류로 인해 실행이 중단되지 않게 하기 위해 추가합니다.
  • RUN yarn build : nuxt 프로젝트를 빌드합니다.
  • ENV HOST 0.0.0.0 : 모든 IP를 개방합니다.
  • EXPOSE 3000 : 3000번 포트를 개방합니다.
  • CMD ["yarn", "start"] : yarn start 명령을 실행합니다.

Docker 이미지 생성시 불필요한 파일을 제외하도록 루트 폴더에 .dockerignore 파일을 생성합니다.

node_modules/
dist/

Dockerfile을 저장하고 다음 명령으로 이미지를 생성 합니다.

docker build --tag nuxt-auto-deploy:0.0.1 .

Docker 이미지를 실행합니다.

docker run --name nuxt-auto-deploy -d -p 3000:3000 nuxt-auto-deploy:0.0.1
  • --name 뒤의 이름(nuxt-auto-deploy)은 도커 컨테이너명이고,
  • 뒤의 nuxt-auto-deploy:0.0.1은 docker image명과 tag명입니다.

localhost:3000으로 접속하면 아까와 동일한 화면을 확인할 수 있습니다.

Docker 테스트가 모두 완료되었으므로 코드를 github에 push 합니다.

 

Github Actions 

Github Access Token 발급
github에 접속한 후 계정에서 settings 메뉴로 이동합니다.

왼쪽 메뉴 하단의 Developer settings를 선택합니다.

왼쪽 메뉴에서 Personal access tokens를 선택하고, Generate new token을 선택합니다.

토큰의 유효기간과 권한을 설정합니다.

  • 유효기간은 최대 1년까지 가능합니다.
  • 권한은 workflow, write:packages, delete:packages를 선택합니다.

하단의 generate 버튼을 클릭하면 토큰이 생성됩니다.

생성된 토큰을 복사하여 Repository-Settings-Secret-Actions에 등록합니다.

 

 

레파지토리의 Actions 탭으로 이동하여 "set up a workfolow yourself"를 클릭합니다.

아래와 같이 workflow 파일을 작성합니다.

이것은 Github Container Registry를 이용해서 docker를 빌드하고 서버에 푸쉬해주는 역할을 합니다.

 

Github Actions으로 AWS EC2에 CI/CD 구축하기

AWS EC2에 CI/CD 구축하기

velog.io

다음은 workflow 파일입니다.( .github/workflows/main.yml)

name: CI/CD Docker

# 트리거를 수행할 브랜치를 지정합니다.
on:
  push:
    branches: [ main ]

# 환경설정
env:
  DOCKER_IMAGE: ghcr.io/${{ github.actor }}/nuxt-auto-deploy
  VERSION: ${{ github.sha }}
  NAME: go_cicd

jobs:
  # 빌드 Job
  build:
    name: Build
    runs-on: ubuntu-latest
    steps:
      # github repository에서 checkout
      - uses: actions/checkout@v2
      # docker build 수행
      - name: Set up docker buildx
        id: buildx
        uses: docker/setup-buildx-action@v1
      - name: Cache docker layers
        uses: actions/cache@v2
        with:
          path: /tmp/.buildx-cache
          key: ${{ runner.os }}-buildx-${{ env.VERSION }}
          restore-keys: |
            ${{ runner.os }}-buildx-
      # GitHub 컨테이너 레지스트리에 로그인 후 빌드 & 푸시
      - name: Login to ghcr
        uses: docker/login-action@v1
        with:
          registry: ghcr.io
          username: ${{ github.repository_owner }}
          password: ${{ secrets.GITHUB_TOKEN }}
      - name: Build and push
        id: docker_build
        uses: docker/build-push-action@v2
        with:
          builder: ${{ steps.buildx.outputs.name }}
          push: true
          tags: ${{ env.DOCKER_IMAGE }}:latest
  # 배포 Job
  deploy:
    needs: build  # build 후에 실행되도록 정의
    name: Deploy
    runs-on: [ self-hosted, label-go ] # AWS ./configure에서 사용할 label명
    steps:
      - name: Login to ghcr
        uses: docker/login-action@v1
        with:
          registry: ghcr.io
          username: ${{ github.repository_owner }}
          password: ${{ secrets.GITHUB_TOKEN }}
      # 3000 -> 80 포트로 수행하도록 지정
      - name: Docker run
        run: |
          docker stop ${{ env.NAME }} && docker rm ${{ env.NAME }} && docker rmi ${{ env.DOCKER_IMAGE }}:latest
          docker run -d -p 80:3000 --name go_cicd --restart always ${{ env.DOCKER_IMAGE }}:latest

commit 버튼을 클릭하면 다음과 같이 파일이 생성됩니다.

.github/workflows/main.yml

 

AWS EC2 생성 및 Docker 설치

이제 자동 배포가 적용될 서버를 만듭니다.

AWS console에 로그인 한 후 EC2 서비스로 이동합니다.

인스턴스 시작 버튼을 클릭합니다.

무료로 사용할 수 있는 Amazon Linux 2 AMI를 선택합니다.

t2.micro를 선택하고 검토및시작 버튼을 클릭합니다.

보안그룹 편집을 선택합니다.

규칙추가 버튼을 누르고 80번 port를 추가한 후 검토및시작 버튼을 클릭합니다.

인스턴스 실행이 완료되면 해당 인스턴스를 체크하고 연결을 클릭합니다.

SSH 클라이언트를 클릭하면 접속 방법이 나옵니다.

터미널을 이용해 ssh로 접속을 합니다.

 

AWS에 Docker 설치

아래 내용을 참조해서 Docker를 설치합니다.

https://docs.aws.amazon.com/ko_kr/AmazonECS/latest/developerguide/create-container-image.html#create-container-image-install-docker

 

Amazon ECS용 Docker 기본 사항 - Amazon Elastic Container Service

Amazon ECS용 Docker 기본 사항 Docker는 사용자가 Linux 컨테이너를 기반으로 하는 분산 애플리케이션을 구축, 실행, 테스트 및 배포할 수 있는 도구를 제공합니다. Amazon ECS는 태스크 정의에 Docker 이미

docs.aws.amazon.com

AWS에 Github Runner 설치

github repository의 settings 탭에서 Runner를 선택합니다.

Runners / Create self-hosted runner를 선택하고, Linux를 선택합니다.

Architecture는 x64로 하고 Download 항목을 한라인씩 복사해서 EC2에서 실행합니다.

./config.sh 문을 실행하면 다음과 같이 입력을 요청합니다.

  • Enter the name of the runner group to add this runner to : 엔터
  • Enter the name of runner : 엔터
  • Enter any additional label : label-go (워크플로우 yml에 작성했던 라벨명
  • Enter name of work folder : 엔터

./run.sh는 다음과 같이 백그라운드로 실행을 합니다.

nohup ./run.sh &
  • tail -f nohup.out 명령을 실행하면 ec2상의 빌드 로그를 확인할 수 있습니다.

Runner 셋팅이 끝나면 github의 Settings - Actions - Runner 메뉴에서 다음과 같이 등록된것을 확인할 수 있습니다.

 

자동 배포 테스트

이제 소스를 수정하고 push를 하면 다음과 같이 빌드가 실행이 됩니다. 

해당 빌드를 클릭하면 세부 정보를 확인할 수 있습니다.

build와 Deploy가 나타나고, 실행되는 것을 확인 할 수 있습니다.

Build 또는 Deploy를 누르면 세부 실행 내역을 볼 수 있습니다.

Deploy가 완료되면 다음과 같은 화면을 볼 수 있습니다.

EC2 인스턴스의 공인 IP를 확인합니다.

브라우저에 아이피를 입력하면 다음과 같은 결과를 확인할 수 있습니다.

 

이제 Push를 하면 서버에 자동 배포가 되는 것을 확인할 수 있습니다.

 

branch를 하나 더 만들어서 (예 : develop) 개발시에 사용하고,
main으로 merge 할 때 자동으로 배포되도록 하는 것도 가능합니다.

반응형
반응형

AWS의 Route53에서 서브 도메인을 생성하는 방법입니다.

기존에 www.mycodegear.com이라는 도메인이 있을 경우, blog.mycodegear.com과 같은 서브 도메인을 추가할 수 있습니다.

 

- AWS 콘솔에 접속 후 Route53으로 이동합니다.

- 호스팅영역을 클릭합니다.

- 서브도메인을 추가할 도메인 이름을 클릭합니다.

- 레코드 생성을 클릭합니다.

- 레코드 이름에 서브도메인의 이름을 입력합니다. (blog.mycodegear.com의 경우 blog만 입력)

- 레코드 유형은 CNAME을 선택합니다.

- 값은 AWS 리소스의 Alias값을 입력합니다.

- TTL은 default 값인 300초로 합니다.

- 라우팅 정책은 default 값인 단순 라우팅으로 합니다.

 

이렇게 하고 레코드 생성을 클릭하면 작성한 레코드가 추가되고,

생성된 domain을 브라우저에 입력하면 연결을 확인할 수 있습니다.

반응형

+ Recent posts