netstat -ano | findstr 8080

프로세스 종료

taskkill /f /pid 포트번호

힙 정렬을 익히기 전에 필요한 힙에 관한 개념

부모 노드 값이 자식 노드 값 보다 항상 큰 조건을 만족(부모 >= 자식) 하는 완전 이진 트리 형제 관계의 노드는 대소 관계를 비교하지 않는다.

이진 트리 구조를 배열에 저장하여 힙 만들기

위와 같은 힙의 성질을 띄는 이진트리를 배열로 저장한 형태는 다음과 같다.

배열에 힙의 요소를 저장할 때 찾을 수 있는 규칙성

• 특정 노드의 부모 노드 인덱스: a[(i-1)/2]

• 왼쪽 자식의 인덱스: a[i * 2 + 1]

• 오른쪽 자식의 인덱스: a[i * 2 + 2]

힙 정렬

가장 큰 값이 루트에 위치하는 특징을 이용한 정렬 알고리즘

1. 루트 노드를 꺼낸다.
2. 비어있는 루트 노드에 힙의 마지막 노드를 옮긴다.
3. 이진트리를 다시 힙으로 구성한다.

루트 노드 10을 꺼냈다. 어떤 노드가 와야할까?

트리의 마지막 노드를 루트 노드로 옮긴다.

위의 트리는 힙의 성질을 띄고 있는가? NO

힙의 성질을 띄도록 노드를 옮긴다.

배열을 힙으로 만드는 방법

위 그림 처럼 아래 부분의 작은 부분 트리부터 시작해 올라가는 Bottom-up 방식을 사용하여 배열을 힙으로 만들 수 있다.

선택 정렬이 선형 탐색으로 최소값을 찾아 맨왼쪽의 값과 차례로 자리를 변경시키는 것과 같이 힙 정렬도 최대 값을 가진 루트 노드를 마지막 요소와 교체하고 다시 힙구조로 만들어 최대 루트 노드를 그 다음 마지막 요소와 변경하면서 정렬을 진행한다.

코드

private static void downHeap(int[] a, int left, int right) {
        int temp = a[left];
        int child;
        int parent;

        /*
        * 자식노드는 다시 부모노드가 된다 (parent = child)
        * */
        for (parent = left; parent < (right + 1) / 2; parent = child) {
            int cl = parent * 2 + 1;    // 왼쪽 자식
            int cr = cl + 1;            // 오른쪽 자식
            child = (cr <= right && a[cr] > a[cl]) ? cr : cl; // cr이 right 보다 크지 않는 조건이 필요.

            // 부모 노드가 자식노드보다 크면 현재 힙 상태의 배열임을 뜻하므로 종료
            if (temp >= a[child]) {
                break;
            }

            // 부모 노드가 자식 노드보다 작다면 부모 노드 값을 더 큰 자식 노드 값으로 교체한다.
            a[parent] = a[child];
        }

        a[parent] = temp;
    }

    private static void heapSort(int[] a, int n) {
        System.out.println("==== 입력으로 들어온 배열 힙으로 만들기 ==== ");
        System.out.println(Arrays.toString(a));
        /*
        * n 이 7이라면 i = 3
        * 그러면 3, 6 사이를 힙 처리
        * */
        for(int i = (n - 1) / 2; i >= 0; i--) {
            downHeap(a, i, n - 1);
        }

        System.out.println(Arrays.toString(a));
        System.out.println("==== 배열을 힙 상태로 변경 완료 ====");

        for (int i = n - 1; i > 0; i--) {
            swap(a, 0, i);
            downHeap(a, 0, i - 1);
        }
    }

    private static void swap(int[] a, int i, int j) {
        int temp = a[i];
        a[i] = a[j];
        a[j] = temp;
    }

선택 정렬의 과정

1. 선형 탐색을 통해 최솟 값을 찾는다.
2. 정렬되지 않은 부분 중 첫번째 요소와 자리를 바꾼다.

코드

public void selectionSort(int[] a, int n) {
    for (int i = 0; i < n - 1; i++) {
        int min = i;
        for(int j = i + 1; j < n; i++) {
            if (a[j] < a[min])
                min = j;

        swap(a, i, min);
    }
}

웹의 아키텍처는 대표적으로 3계층 아키텍처를 사용한다.

기본적은 구조는 위의 그림과 같이 클라이언트(브라우저) -> 프론트 -> 백엔드 -> db 구조로 구성된다.

여기서 프론트, 백엔드, db의 서버를 실행하는 컴퓨터를 각각 하나씩 따로 사용할 수 있지만, 사용자의 요청이 많아지면 과부하를 막기 위해 각각 여러 대의 컴퓨터에 서버를 실행한다.

Haproxy 사용하여 분산 부하 적용하기

총 2대의 컴퓨터에 nginx 서버를 실행하고 브라우저의 요청을 proxy가 받아 2대의 nginx 서버에 적절하게 요청한다.

• 사용한 프록시는 Haproxy

총 3개의 ubuntu 가상 머신 환경을 실행한다. 3개의 가상머신은 각각의 역할을 한다.

1. Haproxy를 실행
2. 첫번째 nginx 실행
3. 두번째 nginx 실행

1. Haproxy 설치

1) 설치와 설정

1. HAProxy 설치

   apt install haproxy

2. HAProxy 설정 파일을 열어 다음과 같이 작성

   listen stats
    bind *:9000
    mode  http
    option dontlog-normal
    stats enable
    stats realm Haproxy\ Statistics
    stats uri /stats

   간단하게 설명하면 HAProxy를 실행한 서버의 IP 주소:9000/stats를 브라우저에 입력하면 HAProxy 관리 페이지?로 접속됨

2. nginx 설치

2대의 컴퓨터에 동일하게 진행한다.

1. nginx 설치

   apt install nginx

2. 2대의 컴퓨터를 구별하기 위해 웹 페이지 파일을 수정

test.html 페이지 생성

touch /var/www/html/test.html

vi를 사용하여 server01, server02 입력

3. nginx 실행

systemctl restart nginx

HAProxy 서버를 통하여 nginx 접속

브라우저에 HAProxy를 실행한 컴퓨터의 IP 주소/test.html 입력

새로고침 연타하면 server01, server02가 번갈아 나오는 것을 볼 수 있다.

1. root 계정으로 접속하여 ip를 재설정한다.

vi /etc/netplan/00-installer-config.yaml

• addresses : 가상머신의 아이피 주소를 지정해 준다. 이때, 이 IP 주소는 사설 IP이다.

  • 192.168.30은 공유기를 찾아가기 위한 공유기 IP 주소
  • 102는 컴퓨터를 찾아가기 위한 IP 주소(사용자가 설정 가능한 부분)

• routes/vis : 가상머신이 연결된 가상의 공유기 IP 주소

192.168.30는 서브넷 마스크로 수정할 수 없는 주소이고 30뒤의 주소를 설정한다.

3. 수정한 파일 적용하기

   netplan apply

가상 머신의 공유기 주소 확인하는 방법

1. vm과 함께 설치된 virtual network editor 실행
2. subnetIP 확인
3. NAT setting 클릭 후 gatewayIP 확인

gatewayIP가 공유기의 IP 주소.

TRACE < DEBUG < INFO < WARN < ERROR

위의 오른쪽 순서대로 레벨이 높아진다. 기본 로그 레벨은 INFO이며 스프링 부트를 실행한다면 INFO 레벨에 해당하는 로그 메시지를 볼 수 있을 것이다.

로그 레벨을 WARN으로 변경한다면 로그는 WARN, ERROR 레벨의 메시지만 볼 수 있다.

반대로, DEBUG로 변경한다면 DEBUG, INFO, WARN, ERROR 레벨의 메시지를 볼 수 있다.

로그 레벨 변경하기

로그 레벨은 application.properties 에서 변경 할 수 있다.

1. 기본 로그 레벨을 변경하는 경우

logging.level.root=DEBUG

root의 로그 레벨을 변경 해주면 해당 프로젝트의 기본 로그 레별이 변경된다.

2. 특정 부분의 로그 레벨만 변경하는 경우

   logging.level.~

   level. 다음에 특정 폴더 또는 파일의 경로를 적어주고 로그 레벨을 입력하면 로그 레벨을 변경할 수 있다.

• Reqeut 요청 정보를 본문에 담아 서버로 전송하는 방법이다.
• 스프링은 json 으로 들어온 데이터를 자바 객체로 변환시켜 저장한다.

예시

클라이언트는 아래의 JSON 데이터를 서버로 전송한다.

{
  "email":"abc@naver.com"
}

매개변수에 String을 설정한 경우

JSON이 객체로 변환되지 않고 문자열 그대로 저장된다.

{
    "email":"abc@naver.com"
}

result

{"email":"abc@naver.com"}

https를 설정하였지만 http://도메인 으로 접속하면 그대로 http로 접속되는 것을 확인할 수 있다. 그래서 http요청이 https로 redirect 되게 해보자.

우선 나는 두가지 도메인으로 접속설정을 했다.

1. www.도메인.com
2. 도메인.com

위 두개의 http 요청을 https로 redirect 해보자.

nginx 설정에서 수정

nginx를 통해 http를 https로 redirect 하자.

현재 내가 사용하는 nginx의 설정 파일은 nginx.conf파일이다. 특정 버전 기준으로 설정파일이 다른 것으로 알고 있다.

sudo vi /etc/nginx/nginx.conf

vi 편집기를 열어 nginx 설정 파일을 수정해보자.

나는 http {} 내부에 아래처럼 설정 해주었다.

query-maker.com는 내가 구매한 도메인이다. 그래서 기본 query-maker.com과 www.query-maker.com을 별도로 설정해주어 http 요청이 들어오면 https로 redirect 시켜주었다.

이제 :wq을 통해 vi 편집기를 저장하고 나간다음 nginx를 reload 시켜주자

sudo service nginx reload

Let's Ecypt에서 발급받은 SSL 인증서는 3개월 마다 갱신을 해주어야 한다. 매번 갱신하기에는 번거롭기에 자동으로 갱신할 수 있도록 설정하자.

crontab

인증서 갱신 테스트 해보기

인증서가 제대로 갱신되는지 테스트 할 수 있다고 한다. 아래의 명령어를 입력해보자.

sudo certbot renew --dry-run

linux는 스케줄러를 지원하는데 이를 사용해서 자동화 설정을 해보자.

sudo yum -y install cronie

위 사진이 테스트가 성공했을 경우 화면이다.

자동화 설정하기

crontab이 설치되어 있지 않다면 위의 명령어를 통해 다운받아주자.

설치했다면 아래의 명령어로 스케줄러 편집기를 실행하자

sudo crontab -e

편집기가 열리면 아래의 명령어를 입력하자

0 0 1 * * sudo certbot renew --renew-hook="sudo service nginx reload"

매월 1일 0시 0분에 인증서를 재발급하고 nginx를 리로드하도록 설정하였다. 정규식이 맞는지 제대로 모르겠다. 매월 1일 0시 0분에 갱신이 되는지 확인해봐야 겠다.

현재 프로젝트는 도메인 연결까지 완성되었다. 이제 http를 https로 변경해보기로 한다.

SSL 인증서를 발급하기 위한 곳으로 Let's Encrypt를 이용하기로 했다.

• EC2 서버는 Aamazon Linux를 사용한다.

Let's Encrypt

Let's Encrypt는 무료 SSL 인증서 보급을 통해 https 사용 확산을 늘리는 목적으로 시작된 비영리 단체이다.

3개월 마다 인증서를 갱신해야 하지만 무료로 발급할 수 있고 자동 갱신 설정을 통해 매번 갱신하지 않도록 설정할 수 있다.

SSL 인증서 생성하기

Let's Ecrypt SSL 인증서 발급은 certbot을 이용한다.

sudo yum install certbot

sudo yum install python-certbot-nginx

https 인증서를 발급받기 위한 도메인 주소를 입력하자.

sudo certbot --nginx -d query-maker.com

그뒤에 여러 동의를 수락하면 인증서 발급이 되고, nginx의 설정에 들어가보면 자동으로 https 설정이 등록되어 진다.

현재 상황

1. aws ec2 서버에서 nginx를 통해 vue 빌드 파일들을 실행 시킴
2. 클립보드 기능이 동작하지 않음

해결 본인의 배포 주소가 http인지 확인한다. http일 경우 보안상 자바스크립트에서 제공하는 클립보드가 동작하지 않는다고 한다.

간단한 Sql 쿼리를 생성해 주는 프로젝트를 만들어 배포하였다. 지금까지는 EC2 인스턴스의 퍼블릭 IP 주소로 접속을 했는데, 도메인을 구매하여 EC2 인스턴스와 연결해보는 작업을 해보자.

도메인 구매하기

가비아가 할인으로 1년 16,000원에 구매가 가능하여 가비아에서 구매를 하였다.

도메인을 구매하고 My가비아 -> 서비스 관리로 이동하면 내가 구매한 도메인을 확인할 수 있다.

관리를 클릭하면 해당 도메인 관리페이지로 이동한다.

EC2 인스턴스와 도메인 연결하기

연결하는 방법은 내가 알기론 두가지가 있다.

1. 가비아 내에서 바로 퍼블릭 IP를 연결하는 법
2. AWS route53을 사용하여 연결하는 법

원래 route53을 프리티어도 무료로 사용할 수 있다고 하여 연결하였다가 알아보니 부가세?는 별도로 내야한다고...

그래서 route53를 삭제하고 다시 가비아 내 DNS 레코드 설정을 통해 EC2 인스턴스와 연결시켜줬다.

route53을 사용한 연결은 구글에 검색하면 매우 많은 블로그가 나오니 여기서는 다루지 않겠다.

가비아 DNS 레코드 설정하기

가비아 DNS 관리페이지에서 퍼블릭 IP를 연결하는 방법은 가비아 홈페이지에 매우 자세히 나와있다.

가비아 DNS 레코드 설정

가비아 홈페이지 설명 중 몇개만 가져와서 정리해보자.

1. 네임 서버가 가비아가 아닌 다른 업체의 네임서버인 경우 해당 업체 DNS 레코드를 설정해야 한다.

   route53을 사용한 블로그들을 찾아보면 route53을 통해 생성된 NS(네임서버)를 가비아의 도메인 관리자 페이지에서 기존 가비아 네임서버를 제거하고 route53의 네임서버를 등록하게 된다.

   이 경우는 가비아가 아닌 route53에서 DNS 레코드를 설정해야 한다.

2. A 타입 레코드 등록을 통해 특정 호스트.도메인이 EC2 퍼블릭 IP와 연결되게 설정 해 준다.

3. www.도메인과 기본 도메인 접속은 각각 따로 지정해주어야 한다. 위의 사진을 보면 www,와 @를 따로 지정해주 었다.

이렇게 레코드를 수정하고 잠시 기다리면 해당 도메인으로 내가 배포한 프로젝트에 접속할 수 있다. 늦으면 몇시간 걸린다고 하는데 보통은 몇 분 기다리면 바로 접속할 수 있는 것 같다.

date

ec2 콘솔에서 위의 명령어를 입력하면 UTC 표준 시가 나온다.

시스템 전역 timezone

시스템 전역 timezone은 /etc/sysconfig/clock에 정의 되어 있다. 한국 기준으로 재설정이 필요하다.

수정 전

ZONE="UTC"
UTC=true

수정 후

ZONE="Asia/Seoul"
KST=True

/etc/localtime 내용 확인

cat /etc/localtime

TZif2UTCTZif2 UTC0

기존(UTC) 삭제

/etc/localtime을 삭제한다.

rm /etc/localtime

한국 표준시간대 정보를 심볼릭 링크 설정

ln -s /usr/share/zoneinfo/Asia/Seoul /etc/localtime

변경 사항 확인

date

정말 간단한 프로젝트를 개발했는데 경험 삼아 배포까지 진행하기로 결정했다. 프론트 엔드는 vue를 사용했고, 백엔드는 spring boot를 사용했다.

vue를 배포하는 방법을 알아보니 여러가지 방법이 있는 듯 했다.

1. github pages, s3를 통한 웹 호스팅
2. nginx 웹 서버를 통해 실행하기

내가 알아본 방법 중 두가지가 대표적인거 같다? 아닐 수도 있음....

그래서 한참을 고민한 결과 아래와 같이 배포 하기로 결정했다.

• 하나의 EC2 인스턴스에 vue와 spring boot를 배포한다.
• nginx로 vue를 띄우고, proxy? 기능을 통해 spring boot의 API를 호출한다.

이제 천천히 배포를 진행 해 보자.

아래에 나오는 CLI는 WSL위에서 Ubuntu를 사용했다.

vue와 spring boot 코드 수정 하기

1) spring boot의 CORS 부분 수정하기

기존에 스프링 부트에서 vue 요청 시 발생하는 CORS를 해결하기 위해 개발 시 사용하는 포트 번호를 허락해주었다. 이제 vue를 ec2에서 실행하기 때문에 URL을 변경해주어야 한다.

이때, ec2의 퍼블릭 도메인:80 포트를 선택해준다. 왜냐? nginx의 기본 포트는 80 포트이다. 80포트는 생략 가능하다.

2) vue의 proxy, axios 부분 수정

1. vite.config.js의 server 부분을 수정한다. 원래 target이 http:localhost:8080 이었다.

2. axios의 디폴트 URL을 수정해주자.

EC2 인스턴스의 포트번호 열어주기

spring boot의 포트 번호를 열어주기로 하자. 8080 포트를 사용한다.

aws 콘솔에 로그인한다. -> ec2 서비스로 이동 -> 왼쪽 사이드바에서 인스턴스 클릭 -> 현재 실행중인 인스턴스를 선택하고 해당 인스턴스 창으로 이동 -> 보안 탭에서 보안 그룹 클릭

인바운드 규칙 편집 버튼을 클릭한다.

8080 포트를 열어주자. 근데 이렇게 하면 모든 IP에서 스프링 부트를 접근할 수 있는데 이게 맞는지 고민이 든다. 그래서 해당 포트를 열지 않고 CORS만 설정했을 때는 요청이 들어가지 않아서 일단 해당 포트 번호를 열어 주었다.

그래서 생각한 것이 포트번호는 접근가능하게 열어주고, 스프링 부트의 CORS를 통해 접근 IP를 제한해야 하는 건가? 라고 생각 중이다. 조금 더 알아봐야 겠다.

1. Spring Boot Build 하기

우선 배포를 하기 위해선 프론트, 백엔드 각각의 build 파일이 필요하다. Spring boot 부터 Build 해보기로 하자.

./gradlew build

스프링 부트 프로젝트로 이동해 위의 명령어를 입력하여 프로젝트의 Build 파일을 생성하자. 코드에 이상이 없고 테스트 코드도 모두 통과했다면 정상정으로 Build가 수행될 것이다.

정상적으로 수행되었다면 /build/libs 에 확장자가 .jar인 build 파일이 만들어져 있을 것이다. 이때 -plain.jar 파일도 있을 텐데, plain이 붙지 않은 파일을 실행 하자. 이제 해당 파일을 실행하여 스프링 부트를 띄울 수 있게 되었다.

참고로 .jar 파일을 실행하는 명령어는 아래와 같다.

java -jar {jar 파일 이름.jar}

2. vue Build 하기

다음으로 vue를 build 해보자. vue 프로젝트로 이동하여 아래의 명령어를 입력한다.

npm run build

위의 명령어를 입력하면 프로젝트에 dist라는 폴더가 생성되고 안에 assets와 index.html이 생성되어 있을 것이다.

이 파일들로 vue를 실행할 수 있게 되었다.

3. 인스턴스로 Build 파일들 전송하기

파일 전송 기본

이제 Spring boot build 파일과 vue buil 파일을 EC2 인스턴스로 전송해야 한다. 여기서는 SCP 명령어를 사용해서 데이터를 전송하기로 결정했다.

명령어는 아래와 같다.

scp -i "사용자 키페어" [전송할 파일 이름] [ec2 user]@[ec2 public IP]:[경로]

위의 명령어를 보면 전송할 파일 이름을 입력하고 마지막에 경로를 입력하면 EC2 인스턴스의 해당 위치에 데이터가 전송되어 진다.

이때, 당연히 명령어 실행 위치가 해당 파일이 위치한 곳이라면 경로를 붙일 필요가 없지만 같은 경로 상이 아니라면 파일 경로 까지 작성해주자.

폴더 내부 파일 전송하기

그리고 폴더 내부의 데이터를 모두 전송하고 싶다면 아래의 명령어로 입력하자.

spc -i "사용자 키페어" -r [전송할 폴더 이름] [ec2 user]@[ec2 public IP]

4. EC2 인스턴스 SSH로 접속하기

이제 전송된 Build 파일들을 EC2 인스턴스에서 사용하기 위해 원격으로 접속해보자. SSH를 사용해 접속 할 것이다.

명령어는 아래와 같다.

ssh -i "사용자 키페어" [ec2 user]@[ec2 public IP[

사용자 키페어 입력시 위치에 따라 경로를 붙여주자.

5. EC2 인스턴스 세팅 하기

1) java 설치

sudo yum install java-17-correto

현재 Aws Linux를 사용하고 있다. 위의 명령어를 입력해서 17 버전의 자바를 설치해 주자. 아래 명령어를 입력해서 자바 버전을 확인해주자.

java --version

2) nginx 설치

sudo yum install nginx

위의 명령어를 입력해 nginx 설치를 진행한다.

sudo service nginx start

위 명령어를 입력하고 퍼블릭 IP:80으로 접속하면 welcom 페이지가 나오면 정상적으로 실행된 것이다.

6. spring boot 실행하기

이제 로컬에서 전송한 .jar 파일을 실행하자.

java -jar [jar 파일이름.jar]

터미널이 종료되어도 spring boot 실행하기

만약 터미널이 종료되어도 실행되고 싶게 하고싶다면

nohup java -jar [jar 파일이름.jar] &

위의 명령어를 입력해서 실행시켜주자. 실행 중 모든 출력 로그들은 nohup.out에 저장된다고 한다.

7. Nginx 설정하고 실행하기

현재 Nginx는 80포트로 접속하면 기본 페이지를 출력하게 되어 있다. 해당 페이지를 vue 페이지로 변경해보자.

우선 설정 파일을 들어갈건데, 찾아본 바로는 sites-available이라는 폴더가 있다는데 현재 내 상황에서는 존재하지 않았다. 그래서 여러 블로그를 찾아본 결과 etc/nginx/nginx.conf를 수정하는 내용을 찾을 수 있었다.

다른 방법도 있겠지만 nignx.conf파일을 수정해보기로 하자. 아래의 명령어를 입력하자.

sudo vi /etc/nginx/nginx.conf

위 사진에서, listen은 해당 포트로 접속 할 경우를 말한다. root 파일을 /var/www로 설정해주고 우리가 로컬에서 전송한 dist 파일들을 해당 디렉토리로 전송해주자.

나는 www 디렉토리 구조를 assets, index.html 이렇게 설정하였다. 즉, www 디렉토리에서 ls -l 명령어를 실행하면 assets, index.html 이 출력된다.

그리고 /etc/nginx/nginx.conf.default 파일도 존재하는데 해당 파일을 /etc/nginx/nginx.conf에 incould 해서 사용할 수 있는 듯하다?

그래서 해당 파일의 server 부분도 수정해 주었다. 아래의 명령어를 입력하자.

sudo vi /etc/nginx/nginx.conf.default

root는 /var/www, index는 index.html으로 설정해주자.

이렇게 설정을 마친뒤 nginx를 실행해주자.

sudo service nginx start

위의 과정을 진행한다면 vue와 spring boot의 통신도 정상적으로 수행 될 것이다.

정리

1. spring boot와 vue 프로젝트에서 설정한 proxy, 요청 URL, CORS url을 수정해주었다.

2. 8080 포트를 EC2 인스턴스 보안 그룹에서 인바운드 규칙을 편집하여 열어주었다.

3. vue와 spring boot의 build 파일을 로컬에서 생성하고 ec2 인스턴스 서버로 전송시켰다.

4. .jar을 실행시키기 위해 java를 설치하고 webserver를 사용하기 위해 nginx를 설치하고 설정을 해주었다.

5. spring boot를 실행하고, nginx를 실행하여 vue 또한 띄어 서로 통신하게 만들어 주었다.

   고민해 볼 것

6. EC2 인스턴스에서 8080 포트를 여는 것이 올바른 방법인지 고민해 봐야할 것같다. 8080 포트를 열어 준다면 모든 IP에서 접근이 가능한데 나는 vue의 URL로만 접속하고 싶다. 이렇게 열어줘도 스프링 부트의 CORS를 통해 접근 제한을 걸었기 때문에 괜찮은 걸까?

7. vue와 spring booot는 같은 서버 내에서 실행되기 때문에 서로 localhost로 통신이 될수 있지 않을까? vue는 사용자가 보는 화면 단이기에 URL 도메인이 필요하고 퍼블릭 IP가 필요하지만, spring boot 서버의 rest API는 vue만이 접근 할 수 있도록 했다. 그렇다면 spring boot는 localhost:8080으로 개발 시 설정했던 것처럼 요청할 수 없을까?

8. nginx의 역할에 대해서 좀 더 알아볼 필요가 있을 것 같다. proxy를 통해 URL을 재설정 해준다는데 확실하게 알 수 있게 공부하자.

9. 무중단 배포도 공부해보자. 잠깐 알아봤는데 s3와 jenkins? 이라는 것을 통해 무중단 배포도 할수 있다고 한다.

10. 현재 프로젝트를 수정하면 재 빌드해서 로컬에서 ec2 인스턴스 서버로 직접 전송해주는 상황인데 로컬에서 프로젝트 수정 후 main 브랜치에 push 후 ec2 인스턴스에서 해당 프로젝트를 clone 하여 ec2 인스턴스에서 빌드하도록 하는 방법을 생각중이다.

11. 5번 처럼 git을 통해 빌드를 업데이트 한다면, 운영 브랜치와 개발 브랜치를 나누어야 할것 같다. 가끔 가다 블로그들을 보면 운영와 개발을 분리해야한다는게 이런 뜻일까?, 로컬 서버 URL들은 운영 URL와 다르고 이것 저것 세팅이 달라지다 보니 개발용으로 브랜치를 파는 것이 좋다고 생각이 들었다.

12. https를 적용하자 ssl 인증서를 통해 보안성을 높이도록 해보자. vue url와 spring boot url 둘다 설정을 해주어야 하는 건지 고민이 필요할 것 같다. ssl 개념도 정리해 둘 필요가 있다.

Control + z를 통해 백그라운드로 보낼 수 있다.

백그라운드에 실행 중인 프로세스 확인하기

• ps 백그라운드 프로세스를 확인한다.

• ps -e 모든 프로세스를 확인한다.

• ps -ef 모든 프로세스 + 상세 정보를 확인한다.

• ps -ef|grep www 'www'를 포함하는 프로세스만 확인한다.

백그라운드에서 실행 중인 프로세스 종료하기

kill -9 {프로세스 ID} 를 입력하여 프로세스를 종료 할 수 있다.

1. 탄력적 IP를 검색한다.

2. 탄력적 IP 주소 화면에서 우상단의 탄력적 IP 주소 할당을 클릭한다.

3. 이때 기본값 그대로 생성할 수 있다. 그룹 이름을 변경해도 되고 기본값을 사용한다면 할당 버튼을 클릭하여 탄력적 IP를 생성해주자.

   탄력적 IP는 생성하게 되면 유료이지만 하나 까지는 인스턴스와 연결시 무료라고 한다. 하나는 무료로 연결이 가능하다는 것. 하지만 연결이 되어 있지 않다면 요금이 나가게 된다. 주의!

생성된 탄력적 IP와 기존 EC2 인스턴스와 연결하기

1. 생성한 탄력적 IP를 선택하고 우상단의 작업 드롭버튼을 클릭해 탄력적 IP 주소 연결을 클릭하여 연결화면으로 이동한다.

2. 기존 생성되어 있는 인스턴스를 선택하고 제공되는 프라이빗 IP 주소를 선택한뒤 연결 버튼을 클릭한다.

3. 연결 뒤 기존 인스턴스의 요약 화면으로 이동하여(사이드바 -> 인스턴스 클릭 -> 기존 인스턴스 의 ID 클릭) 탄력적 IP 주소가 연결되어 퍼블릭 IP를 제공하는 것을 확인할 수 있다. 캡쳐가 되지 않아 보여주지는 못하지만 바로 찾을 수 있을 것이다.

1. 우선 AWS 콘솔에 로그인 한 후 검색창에 EC2를 검색한다.

2. 아래 사진의 빨간색 박스로 체크한 인스턴스 시작을 누른다.

인스턴스 시작을 누르면 아래와 같은 화면이 나온다. 이제 필요한 정보를 입력해보자.

이름은 본인이 생성할 EC2 인스턴스의 이름을 정한다.

3. 아래 사진은 AMI라고 EC2 인스터스로 돌아갈 운영체제를 선택해야 한다. 여러가지 종류가 있는데 프리티어 사용 가능 AMI가 있으니 그 중 원하는 AMI를 선택하자. 나는 Amazon Linux를 선택했다.

4. 여러 성능의 인스턴스가 있는데 프리티어인 경우 아래의 인스턴스를 생성 가능하다.

5. 키페어를 사용하여 인스턴스에 안전하게 연결할 수 있게 한다. 키페어는 필수로 사용하자. SSH로 원격에 접속할 때 필요하다. 그냥 무조건 사용하자. 키페어가 없다면 새로 생성하고, 파일을 저장할 수 있을 것이다. 무조건 저장하여 보관해야 한다.

6. 네트워크 설정을 한다. 퍼블릭 IP 자동 할당을 비활성화 하기 위해 오르쪽 편집 버튼을 클릭한다.

지금 기존에 인스턴스를 만든 상황이라 그런지 경고창이 나타는 것 같다. 일단은 이대로 진행하자.

여기서 SSH는 내 IP 만 접속 가능하게 하고 HTTP와 HTTPS는 모든 IP 접근을 허용한다.

7. 스토리지를 구성한다. 기본값이 8로 되어있는데 프리티어에서 사용할 수 있는 크기는 30GB이므로 30GB로 설정해 주자.

위의 순서가 기본적인 생성 방식인 듯 하다. 이제 오르쪽에 인스턴스 시작을 눌러 인스턴스를 시작하자.

탄력적 IP를 통해 고정 IP를 설정하는 방법은 따로 정리 해야겠다.

우선 스프링 프로젝트로 들어간다.

리눅스 기준 아래 명령어를 입력한다.

./gradlew build

빌드가 완료되었다면

cd ./build/libs

위의 경로로 들어가면 .jar파일이 생성되어 있는 것을 확인할 수 있다.

sudo yum install java-17-corretto

버전 확인

java --version