정적파일배포 + 동적 파일 배포 분기시키기!
터미널 종료하면 실행되고있는 프로그램 눈에는 안보이지만 종료되어 사이트 접속안됨. 쉘이 벡그라운드에서 계속 실행중이도록 도커를 활용하기
가장 간단한 방법은 한번에 EC2에서 yarn start 하는것.LB,CDN 필요없이 방화벽만 풀어 사용하면된다!
단 트래픽이 많으면 컴퓨터가 많이 필요하고, 용량을 늘린다면 유지비와, 용량에대한 비용까지 많이든다.
Docker => 배포를 위해 사용되나, 개발환경 같이 세팅하는 환경통일용으로도 사용된다.
브라우저 에서 DNS로가 DNS에서는 CDN으로 가는데 여기서 분기가 이루어진다.
1일차에는 스토리지로 올리는 부분,
2일차에는 LB에서 타겟그룹안의 VM으로 동적페이지 올리는 부분을 했다.
오늘은 이것을 분기처리해 연결하는 작업을 하는것이다.
CDN이 분기점이기에 여기에 SSL인증서를 설치했었다.
(Certificate Manager 통해)
-https로 접속가능하게 하기위한 과정..
대규모의 경우를 가장해 트래픽이 많이 모이는것이라고 생각하고 분기한것.
지금 현재 정적 페이지는 CDN으로 스토리지에 연결해놨기에 내 도매인 주소를 입력하면 접속이 되었다.
동적 페이지의 경우 로드벨런스를 통해 접속한다.
EC2 -> 인스턴스실행중(running) 해당 메뉴에서 얘랑 연결되어있는 로드벨런서에 접속
인스턴스 아이디 클릭해 들어감
-> 연결(connect)을 클릭,SSH(시큐어 쉘) 즉, 터미널에 접속하는 것. 다시 연결을 클릭
-> 터미널 접속 -> ps -ef
ps 는 프로세스의 약자이고, e는 enviroment(환경)의미한다.
기존에 실행시켜놓은 yarn start가 있는지 보는 명령어인데, 즉 그 프로세스의 환경을 보고싶다 라는 명령어.
프로세스?
하나의 컴퓨터.
쓰레드?
프로세스 안에서 실행되고있는것
이렇게 입력하면 많은 것들이 뜬다. 따라서 범위를 좁혀 node로 실행되는게 있는지 본다.
ps -ef | grep node
| 는 파이프 라고 부르는데, 앞의 명령어의 결과에서 다른 명령어를 조합하고싶을때 사용한다.
이렇게 했더니 현재 실행되고있는 것이 없는것으로 나왔다.
만약 현재 실행되고 있는 node프로그램이 있다면 일단 수업진행을 위해 죽여주고
--> 진짜 명령어가 kill이다
ps -ef | grep node
이 결과에서 나온 맨앞의 숫자부분(프로세스 아이디) 를 사용해 kill한다.
kill -9 해당프로세스아이디
ls 로 만들어둔 폴더가 있는지 확인후 들어가 실행할 폴더로 최종이동
=> yarn start로 하면 노드 실행기로 실행된다. 실제 실행하고있다면
ps -ef | grep node
로 잡힌다.
지난시간에 build는 이미 했으니 yarn start만 하면 된다.
혹, 소스코드가 바뀌었다면 build부터 다시해야한다.!!!!
yarn start
이제 실행해놨으니 LB -> 아래쪽 name의 A레코드 라고 써있는것 복사해 접속하면 접속이된다.
LB에는 SSL인증서 없기에 주의요함으로뜨는것을 볼 수 있다.
이제 분기 처리에 들어간다.
엔드포인트에 따라 정적 페이지의 경우에는 스토리지로, 동적페이지면 LB로 보내준다.
CDN에서 분기처리
- CDN과 LB연결하기
- CDN에서 주소에따라 분기처리
AWS의 CDN인 CloudFront로 이동한다.
id를 클릭해 들어가
-> Behaviors(행동)을 클릭
-> Path pattern(경로) *로 되어있다.
즉 모든 경로를 S3로 가게 한것!
/boards/* 는 LB로 가라 등은 추가 필요하다. => 동적페이지에 대한 분기
여기서 Origin 이라는것이 필요하다. 현재 origin있는것은 S3의 것. 여기에 LB의 것이 필요하다.
origin에 LB 준비!
위에 원본(origin)을 클릭
-> 처음에 만든 S3는 기본적으로 만들어 있었고... 지금은 이것만 있기에 모든 주소가 S3(스토리지)로 가고있는것!
이제 원본(origin)에서 LB를 추가하고 행동(Behavior)에서 위치에따라 LB로 갈 수 있게 한다.
Origin -> create origin 클릭 -> LB를 my-alb라는 이름으로 생성했으니 목록에서 해당이름을 찾아 적용해주면된다.
-> http-only(만 가능) / https-only /Match viewer 이렇게 세가지가 아래에 나와있다.
우리가 https로 접속했을때, DNS A레코드는 CDN과 연결되어있다.
CDN에는 SSL인증서가 설치되어있어 여기서 나눠질때의 모든 최초 접속은 https로 들어가게된다. 즉, 보내지는게 http이건 https이건 어차피 CDN을 통하면 https로 들어가니 딱히 선택할 필요까지는 없다.
일반적으로 첫번째 입구에 https를 붙이고, 그다음 뒤쪽으로 들어가는 것들은 http로 한다.
https라는 것은 시큐어 알고리즘이라는것이 들어가는것인데,전부 https로 하면 이 시큐어를 푸는것때문에 시간이 오래걸려 느려진다.
물론 서비스 특성마다 다르다고하셨다. 내부적으로 보안이 중요한 그런 경우에는 느리더라도 다 s 를 붙인다.
이때 CDN으로 받을때 이때 SSL인증서가 들어갔는데 만약 뒤쪽에도 예를들어 LB부분에들어갈때 https로 하고싶다면 SSL인증서가 이 LB에도 필요하다.
즉, 들어오는쪽에 인증서가 필요하다는 말이다.
방금
http-only(만 가능)
https-only
Match viewer(뷰어일치)
이 부분은 CDN에서 LB로 보내주는 데 http로 갈래, https로 갈래? 라는 부분이다. 만약 https로 가려면 LB에도 SSL인증서를 설치해야한다.
상관없기에 그대로 http가 선택되어있는것은 두고, 포트도 80 http기본 포트로둔다. 이제 분기후에는 CDN을 통해 들어가기에 https로 접속되어 '주의요함'이 아니라 자물쇠 모양이 나올것이다.
create origin(원본생성) 클릭
-> 원본이 생성되었다. 확인해보면 이전것까지 총 두개가 나온다.
-> Behavior(동작)
->create Behavior(동적생성)
-> path pattern 에 /baords/* 을 추가한다.
boards 안에있는 파일들은 전부 LB로 보내겠다는 말!
viewer에는 Redirect http to https를 선택해 혹시나 http 로 접속했다고 하더라도 https로 바꾸어 접속이 가능하게한다.
-> (Allow methods)메서드는 전부 가능하게 맨 아래꺼 모든 메서드가 적힌것을 선택하고,
-> origin and origin group 으로 원본그룹을 선택해야한다.
즉, 경로 패턴을 적었는데 그 경로로 오는것은 어디로 보낼 것인가!
동적페이지 부분이니 LB로 보내야하기에 my-alb(생성한 LB이름)를 선택한다.
->create behavior(동작생성)!
이제 boards폴더 내부 애들은 다 LB로 보내는 분기처리가끝났다.
같은 방법으로 내 포트폴리오에 /market/* 으로 추가해 상품폴더 페이지 내부 파일은 LB로 가도록 설정해주었다.
해당 경로로 가는 것은 LB로! , 그 외는 S3(스토리지)로!
이제 동적페이지로도 가지는데, EC2를 끄면 확실히 알 수 있다. 터미널을 끄고 /boards/qqq 로 들어가보면 어? 접속이된다.
저장되어이쓴ㄴ 캐시때문!!
CloudFront의 invalidations(무효화) 클릭
-> create invalidation(무효화생성)클릭
-> /* 를 적어주고, 모든 페이지를 저장하지 말라고 설정해준다.
-> create invalidation(생성) 클릭
처음 한번, 접속하면 임시저장해놓고, 다음 접속시 저장한것을 보여주어 빠르게 보여준다.
실 배포시에는 좋지만 지금은 실습중이기에 모든 캐시를 무효화하며 확인해보도록한다.
원래 적용하지 않으려했으나 한번해보려다가 ...지우지를 못하고있다. 나중에 찾아봐야겠다
브라우저자체에도 캐싱되어있는데 새 시크릿창으로 접속해 확인해본다.
안된다면 캐시를 지우거나, qqq가 아니라 저장되어있지않은, 즉, 입력하지 않았던 다른것을 적어 확인해본다.
502 에러가 뜨는 것을 확인할 수 있다. 즉, 동적페이지는 LB를 통해 EC2로 들어가는데, 해당 쉘을 껐으니 접속이 안되는것!
이것을 통해 동적페이지는 LB로 잘 가고있다는것을 확인할 수 있었다.
그런데, 원래 실습용 파일에
게시글 아이디 :{router.query.boarId} 라고해서 동적파일에 접근하면 해당 게시글 아이디가 보여야한다.
근데 EC2를 다시 켜서 접속했는데 페이지는 보이나, 게시글 아이디 부분이 비어있다
정상적으로 진행되고 있지 않는다는 말!
네트워크 창을 살펴보면 받아오지 못하는 스크립트가 있는것이 확인된다. 다운로드 위치Request url 을 보니 ~~/_next폴더에서 받아오는 것이었다. (_next폴더 앞부분에는 도매인이 생략되어 있는것이라고 할 수 있겠다..)
=> 스토리지의 _next라는 폴더에서 받아오는것!
그럼 어떻게 해야할까?
1.로드벨런서에 정적파일 폴더를 만들어 그쪽으로 우회시키기, 또는
2. yarn build 하면 최적화 되며 앞축되는데 이때 .next폴더가 생기고 이것이_next폴더가 되는것이다. 이 폴더를 스토리지폴더와 로드벨런스 폴더를 일치시키면된다!
build id라는 것을 주면 된다고 한다.
yarn build하신것을 살펴보니, yarn build하면 .next 폴더 생성되고, 아 언애 static폴더에 생성된 id폴더와 (LB -> EC2에서 build했을때의 id이다) , 그리고out폴더의(이부분은 yarn build:ssg 라고 스토리지에 빌드할때 생성된것) _next의 static안의 아이디 폴더가 다르다는 것을 알 수 있다.
해당 id는 build시마다 달라지는 아이디이다. 즉, 동일한 파일을 다운로드 받아오지 않는다는것!
따라서 build아이디가 즉, id폴더명인데 해당부분을 통일하는것이 제일 쉬운방법이다.
이렇게 통일을 시키면,
각각의 id가 통일되어있기에 어디로 접속해도 같은 소스코드를 받아올 수 있다.
build id통일하기
-> 어디서 build하더라도 졸더명이 같기에 어디서 받아오던지 다 가능함.
즉, 어디서 build하더라도 똑같이 _next폴더 나올 수 있게하기!
VS code접속
-> next.config.js
-> generateBuildID : () => "원하는 폴더명"
이 폴더명은 아무거나 해도되는데 내 도매인 이름과 기수로 만들어봤다.
같은 이름으로 포트폴리오랑, 실습용에 둘다 적용해주었다!
이렇게되면 static의 id가 항상 이 지정한 것으로 변하게된다.(build를 여러번 한다고해도 이id이름이 바뀌지 않는다는것!!)
yarn build:ssg하면 out 이라는 폴더가 생성된다.이 안에 _next폴더가 있고, 그 안에 다시 들어가면 지금 만들었던 이름의 폴더가 생성되어있는것을 볼 수 있다.!!
빌드를 다시 했으니 해당 out폴더를 다시 스토리지에 변경해 넣어야한다. S3로 가서 기존것 다 지우고 out폴더 내부의 것들로 업로드를 다시하고,
-> 완료 후 Action(작업) 에 들어가서 Make public using ASL(퍼블릭으로 만들기)를 클릭한다. -> 다시한번 클릭하면
-> 폴더들이 합쳐져 접속이되고,
이제 같은 작업을 EC2에도적용하면된다.
-> git push까지 진행한 후,
기존에 ,git clone을 했으니 변경된 사항으로 다시 받으면 되기에
->git pull origin master
로 변경된 사항만 받아본다.
->EC2로 가서 yarn build, yarn start를 다시 진행하면 된다.
그래여 여기도 바뀐 _next폴더로 다시 업그레이드 되기때문!!
-> EC2로 들어가 -> 서버 연결에 들어가 쉘을 열고, git pull origin master
-> yarn build
-> ls -al하면 숨김파일까지 다 보는 명령어.
이 명령어로 보아야 .next폴더까지 나온다.
그 안에 들어가보면 static폴더가 있고 그 안 .next폴더 안으로 들어가서 ls로 리스트를 보면,
내가 build id 로 지정한 이름의 id폴더가 보이는 것을 확인할 수 있다.
이제 메인 폴더로 들어가 다시 yarn start
동적 페이지를 다시 확인해 보면
게시글 아이디: '이 부분' 이 제대로 나오는것이 확인이 된다.
네트워크에서 확인해보면
내도매인/_next/static/이 부분에 해당 아이디폴더명이 들어간다!
그런데 정적페이지에서는 해당 아이디폴더명이 내가 지정해 준것이 아니었다.
일정기간 캐싱되어있기에 그 시간이 지나면 잘 나올것이라고 한다.
서버사이드 랜더링(SSR)
서버사이드 랜더링 ->
어떨때 적용하는가?
다이나믹 라우팅으로 제작한 페이지는 실제 주소가 존재하지 않아 직접 접근이 불가능합니다.
그렇기 때문에 다이나믹 라우팅은 SSR 배포를 통해서 접근이 가능하도록 코드를 작성하여야 합니다.
--> 이렇게 자료에 나와있었다.
그런데 만약 서버사이드 랜더링을 하는 페이지가 있다면 이 부분때문에 아얘 빌드가 안됨을 볼 수 있다.
export const getServerSideProps = () => { // 만약 서버사이드 랜더링을 한다면?? =>out 폴더로 생성 불가.즉 자예 build안됨 => next.config.js에서 exportPathMap으로 // 서버사이드 랜더링되는 현제페이지 제외시키기 };
next.config.js 에서 exportPathMap을 적용한다.
// getServerSideProps 들어있는 페이지는 제외하고 빌드시켜줘! exportPathMap: () => ({ "/": { page: "/" }, "/boards": { page: "/boards" }, "/404": { page: "/404" }, }), };
각각 메인 페이지와, boards페이지, 404페이지만 빌드해달라는 명령어다!
즉 exportPathMap 에는 서버사이드랜더링이 적용되지 않는 페이지만 적어 해당 페이지들만 빌드를 해주고 서버사이드 하는 페이지는 제외하는것!
Docker
회사에서 컴퓨터를 제공하면 (요즘엔 거의 맥북) => 환경세팅만 하면된다.
옛날.. 회사에서 컴퓨터를 제공하지 않아 윈도우, 맥북, 리눅스 등 다양한 것들을 사용 -->
신입사원들은 해당 회사에서 사용하는 프로그램을 일일이 설치해야했다.
지금은 yarn install로 node 패키지는 설치되는데. 회사에거는 노드 버전맞추고 그 외 필요한 것들을 설치해야한다.
그런데 안된다? 그럼 운영체제에 문제 있는것.
운영체제에따라 달라지는 환경이 가장 큰 이유이다.
컴퓨터안에 가상머신을 다운받아 실행하면, (이 가상머신에는 docker, vmware등이 있다) 운영체제 설치가 되어있지 않은 가상의 컴퓨터가 내 컴퓨터 안에 생긴다.
그래서 여기에 운영체제를 설치 하는 것이다.(Mac-OS, Linux, Window)
-> 이렇게 하면 새 컴퓨터를 실행 할 수 있다.
이렇게 가상머시느이 운영체제의 버전을 통일해 사용하고, 설치 해야하는 것들을 하나씩 설치한다 --> 다만, 컴퓨터 안에 컴퓨터가 있어 좀 느리다. 부팅 & 꺼지는 것 전부다. 느림.
그래서 도커라는 것을 사용하게 된것이다.
도커?
운영체재ㅐ가 어차피 밖에 있으니까, 같이 쓸 수 있는 부분은 공유하자.
즉, 운영체제의 핵심기능(커널이라고 한다)은 공유하는것.!
그렇게 훨씬 빠른 가상머신이 되었다.
=> 훨씬 빠르고 가벼워졌다.
다시말해, os전체를 새로 설치하지 않아도 된다는 말이다
물론 VMware을 사용해도 되고, 아직도 VMware을 사용하는 회사가 있으나 도커를 사용하면 더 빠른 속도고 할 수 있게 되는것이다.
도커가 기본적으로 리눅스 배이스이니 리눅스를 설치 한다고 하면 리눅스는 당연히 리눅스와 공유되고, 맥과 리눅스는 같은 Unix계열이라 같은 부모를 가져 명령어가 비슷하니까 공유되고,
윈도우와 리눅스? 이 경우는 둘이 너무 다름. 따라서 윈도우에서 사용이 가능함 리눅스 기능들을 사용위해
WSL이라는 것이 설치가 필요한데 최근에는 업그레이드 버전으로 WSL2가 나왔다. 즉 이것은 윈도우 서브 시스템 리눅스 의 약자로 이거를 윈도우에서
깔아야 도커 사용이 가능하다는것!
도커의 장점1 이 속도가 빠르고 가볍다는 것이면,
장점 두번째는 다른 프로그램들이 설치된 도커도 만들 수 있다는점이다
이제 회사에서 이미 세팅되어있는 도커 파일을 받게되고, 이것을 실행하면 자동으로 이것들이 깔린 도커가 만들어진다.
yarn install로는 노드로실행되는 애들인 노드 패키지만 실행되는 것이고,
Dockerfile 는 운영 체제를 위한 npm이라고 보면되는데, 이 안에서 node, mysql 등이 포함된 운영체제를 만들어 준다.
노드 패키지가 아닌 다른건들을 한방에 설치한 운영체제를 만들어 주는 것이다.
=>여러 프로그램이 있기에 npm보다는 큰 개념이라고 할 수 있다.
이제 Dockerfile만 실행하면 끝!!
이렇게 도커로 운영체제가 리눅스로 통일되니 충돌도 없고, 이미설치할 목록이 세팅되어있어 하나하나 설치할 필요가 없다
물론, 여기까지는 VMware와 동일하다.
도커만의 장점은 앞에서 언급했던것과 같이
빠르고, 가볍다는것이다!
개발/ 배포 환경을 통일할 수 있다.
개발자들과의 환경들, 개발환경,배포환경을 통일 시킬 수 있다.(운영체제도 도커의 리눅스로 통일할 수 있고, 그 외 다른 프로그램들도 통일할 수 있다.
통일을 시켜야 장애가 발생하지 않는다.
내컴퓨터에서는 됐는데, EC2에서는 안된다. 이렇게 되면 장애가 일어나게된다!!(서버 문제생김)
Docker
- 개발 /배포환경 통일함!
- 프로그램미리 설치함!
- 가벼움!
도커실습하기
docker.com 에서
도커를 설치하면 docker --version으로 설치된 도커 버전을 알 수 있다.
VS코드에 도커를 적용할 폴더에 Dockerfile이라는 파일을 만든다!
->Dockerfile에 작성한다.
FROM ubuntu :22.04 리눅스 우분투 22.04버전을 받겠다는것.
그러면 어떤식으로 도커에서 다운받는것일까?
npm에서 라이브러리등을 받아올때 npm이라는 명령어나 yarn 이라는 명령어로 npm install,yarn ... 이런 명령어를 사용해 설치 하기에 yarn 과 npm이 필요했다.
그리고 npm publish 라는 명령어로 내가만든 라이브러리등을 올릴수도 있다.
간단히 console.log찍는것을 만들어서 올려도 된다. 해당 방법을 인터넷에 쳐보고 적용해보기...
또 git 에서 받아올 시에는 git clone 해당주소 와 업데이트본을 받는 git pull origin master .. 등의 명령어가 있다.
git관련 명령어를 사용하기 위해서는 당연히 git이 설치되어 있어야한다.
그리고 git push로 내 소스코드를 올리기도 한다.
그렇다면 도커는??
당연한것은 docker가 기본적으로 깔려있어야하며,
docker pull이라는 명령어로 docker을 받아오고, docker push로 내가 운영체제를 만들어 올리는것이 가능하다.
물론, 실제로 맥 OS나, 리눅스나..그러한 운영체제 만드는 것은 어렵다.
운영체제를 만들어 올린다는 말은 일단 있는 운영체제를 다운받고, 특정 내가 필요한 기능을 다운받고서 그 다운받은것까지 적용해 다시 올릴 수 있다는것이다. 즉, node.js를 설치해 node.js가 설치된 운영체제를 만들어 올릴 수도 있다는 말이다.
우리는 이미 노드, yarn, npm 이 다 설치된 우분투가 있기에 이것을 받아오면 된다.
원래 오리지널 방법
FROM ubuntu:22.04 ==> 이 우분투 안에
RUN curl -sL https://rpm.nodesource.com/setup_14.x | sudo bash ==> 노드설치 명령어 부분, 여기서 가져온다.라는 의미
RUN sudo yum install -y nodejs ==> 노드를 설치한다.
RUN sudo npm install -g yarn ==> -y를 안넣는다면 yes/no 선택하는 부분이 나오니 자동적으로 yes가 되어 체크된다.
노드를 설치하면 자연스레 npm이 설치된다.
거기에 yarn 까지 설치한다면
RUN sudo npm install -g yarn
이것을 실행시키면 하나의 운영체제가 실행되고, 그 안에서 node.js가 설치되며 yarn 까지 설치된다.
따라서 yarn install도 가능, yarn --version도 가능하다.
그런데 일일이 적어주지 않아도 가능한 방법이 있다고 한다!
도커허브(dockerhub) 에서 node를 깔면 다 되어있다!!
도커허브에서 node.js를 검색하면 나온다.
터미널에서도 검색이 가능하다. 물론 도커는 설치되어있어야한다.
docker search ubuntu -> OFICIAL 부분이 [OK]라면 신뢰할 수 있다는것이라는 의미이다.
docker search node.js
검색시 나오는것들 하나하나들을 하나의 압축된(최적화된) 이미지 라고 한다.
그럼 우분투를 설치하지 않고 노드를 설치해보자
FROM node:14
이것을 실행하면 하나의 컴퓨터가 실행되고 이 안에 우분투, 노드, yarn 까지 설치되어있음을 알 수 있다.
이 안에서 프로그램을 실행한다.
무엇을? --->> 현 폴더의 파일을 가지고 가 실행시킬 것이다.
이 파일들을 가상컴퓨터에 복사해 넣어야한다.
내컴퓨터의 실행시킬 폴더를 --> 도커 컴퓨터 폴더에!!!
COPY . /class_build/ => 현 위치의 모든 파일들을 class_build라는 폴더에 넣어줘!!
이얘기는 class_build라는 도커컴퓨터의 폴더에 내 컴퓨터의 지금 Dokerfile이 있는 현재 위치의 모든 파일을 옮긴다는 의미이다. class_build라는 이름이 아니라 원하는 폴더명으로 적어주어도 된다. 그런데, 지금 도커컴퓨터에는 해당 폴더가 없다.
RUN mkdir 폴더명 이렇게 폴더를 만들어주고 해당 폴더로 현위치의 파일들을 다운받아도 되지만,
COPY 시 해당 폴더가 없다면 자동으로 생성하고 진행하기에 mkdir을 해주지 않아도 된다.
현재 카피할 위치의 즉, 도커의 폴더가 class_build라는 이름이니 해당 부분에서 작업을 진행한다.
WORKDIR /class_build/ ==> 여기서 작업할 것이니 여기로 이동해줘(커서깜빡이게 해줘)
RUN yarn install 도커의 class_build라는 폴더에 yarn install되는것!
RUN yarn build
RUN yarn start
실행명령중 RUN과 CMD가 있다. 따라서
CMD yarn start 도 가능하다는 말.
그럼 둘의 차이가 무엇일까?
CMD명령어는 한번만 사용이 가능하다. 따라서 보통 마지막에 한번 사용한다.
왜??
실제 실행시키면 우분투안에 노드가 깔려져있는 프로그램을 도커허브에서 다운받아오는것이다.(1.도커허브에서 node설치된 우분투 운영체제를 다운로드 받아옴)
---> 시간이 걸린다.
다운받아와야 운영체제가 설치되고...
2. COPY진행하며 폴더를 만든다. => 내 컴퓨터에 있는 파일들을 토커컴퓨터에 복사하는것
3. 커서를 해당폴더로 위치하고 yarn install, yarn build 실행
- 최종 프로그램 실행(yarn start) --> 실행시킬때마다 이 과정을 다 거치나?
실제 매번 이렇게 하지는 않는다.
한번만 하고 저장해놓는다. => 이 파일을 이미지 라고한다.(여기서 이미지는 사진을 의미하는 그 이미지가 아니라 최적화된 압축파일을 얘기하는것이다.)
=> 그 후 저장한 이미지를 불러와 실행시킨다.
무엇이 저장되나?
RUN 명령어로 실행시키는 애들이 저장대상이다.
CMD는 저장에서 제외된다. => 즉,저장한것을 꺼내와 실행할때 사용하는것!
FROM node:14
COPY . /class_build/ => 도커의 이 폴더에 현 폴더 파일들 복사. 도커에 해당 폴더가 없다면 만들고 복사
WORKDIR /class_build/ => 이 폴더로 커서 이동.
RUN yarn install
RUN yarn build
여기까지가 저장되어 1번이 실행된다.
이후부터는 저장한것 가져와 저장된것을 가져와 실행된다.
CMD yarn start
이 부분은 저장된것을 가져와 실행된다는 말이다.(저장되지 않는 부분. 그때 그때 실행됨)
실제로는 도커 하나만으로 실행하지는 않는다. 도커도 여러개가 있을 수 있고, 이 여러개를 한번에 ON/OFF 하는것도 가능하다.
이렇게 그룹핑하여 한번에 실행시키는 도구를 도커 컴포즈 라고 한다.(docker-compose)
VS코드로 이동!! =>
docker-compose.yaml 파일 생성.
=> yaml파일,이 파일은 탭(띄어쓰기)가 아주 중요한파일이다.
지금하는 과정은 docker-compose로 도커들을 감싸는 과정이다.
Docker-compose로 도커들 감싸기
version: "3.7" => 버전은 3.7로 services: ==> 도커를 만들어진 컴퓨터 하나하나를 의미
class_build: ==>컴퓨터 이름 (아무거나로 해도됨) build: ==> 빌드할 즉, 최종적으로 저장될 파일 위치 의미 context: . ==> 현 위치를 의미 dockerfile: Dockerfile ==> 도커파일은? :Dockerfile이라는 것. 이 파일에 컴퓨터에대한 설명이 들어있다.이부분이 여러개 생기는 것이다.
----그럼 yaml파일은 하나만 있어도 되는건가?....
현 폴더에서 docker-compose build하면 저장까지 진행된다.
dockerfile위치를 찾아가서(context부분에 나와있음) Dockerfile을 실행시키고 RUN build까지 하여 이미지를 저장,
==> 용량이 1G 정도 된다고한다.(용량큼)
이후에 docker-compose up하면 저장된 이미지를 실행하는 것이다
이미지를 가져오고 CMD를 실행(CMD yarn start)
docker ps =>현재 실행되고있는 도커프로세스(프로그램)이 나온다.
지금실행중인 컴퓨터 하나 이부분을 컨테이너라고 한다.
이 컴퓨터 안으로도 접속할 수 있는데 docker-exec -it 이라고 하면 수정하고 볼수있게해줘 라는 명령어다.
ps 라는 명령어로 실행되고있는 프로세스가 컨테이너에 나오면, 그 앞에 포트 번호가 보이는데 그 부분을 활용한다.
docker-exec -it 포트번호/bin/bash
==> 커서를 깜빡거려달라는 의미가 bash..
bash쉘 이라고 하는데, 이렇게 bash쉘을 입력하면 도커안에서 bash쉘이 만들어진다.(즉, 커서가 해당 컴퓨터 안으로 들어가게된다)
--> 이렇게되면 해당 컴퓨터 안으로 들어가게되어 쉘이 바뀐다.
명령어 치는 부분의 앞부분을 보게되면 이름이 달라진것이 보일것이다.
쉘이 바뀌었다면 도커컴퓨터 안으로 들어온것이다.!
확실하게 확인하려면 해당 쉘에서 mkdir로 폴더를 하나 생성해보고 ls로 확인해보자. 그리고 내 폴더를 살펴보며 비교해보자.
분명 ls로는 폴더가 만들어져 있는데 내폴더. 그러니까 실제 내 컴퓨터 상에는 만들어진 폴더가 없다.
도커 컴퓨터에 생성했기때문!!
안으로 들어왔으니 이제 바깥으로 나가보자.
exit
쉘이 원래대로 돌아왔다.
docker-compose up까지 치고 켜져있는 상태에서 나온 주소인 localhost:3000에 접속하려하면 접속이 안된다.
--> 가상머진이기에!
localhost는 내 컴퓨터를 의미한다. 그래서 내 컴퓨터 안에서 3000번 포트로 실행된 프로그램을 찾는데, 지금은 내 컴퓨터 안 가상머신인 도커에서 실행되는것이기에 그러니까 도커에서의 3000번 포트에서 실행중이라 못찾고 있는것이다
도커 컴퓨터로 들어갈 수 있는 입구를 만들어주고 해당입구를 3000번 포트에서 실행시키자
브라우저 :localhost:3000 -> 3000번 타고 도커입구로! -> 도커에 접속하고, 도커내 컴퓨터안에서 3000번 찾아서 연결한다.
포트포워딩
실제 도커내에서 실행중인 프로그램 포트는 3000번.
이와 관계없이 입구를 2000 번으로 하면 브라우저는 2000번으로 접속해 도커로 들어가 도커에서는 3000번으로 포워딩한다.
2000번으로 들어왔다 --> 이 포트를 3000번으로 보내줘!
이부분을 포트포워딩이라고 한다.
yaml 파일로 돌아간다.
ports를 추가한다.
version: "3.7" services: class_build: build: context: . dockerfile: Dockerfile ports: - 3000:3000
- 3000번 포트로 들어오면 : 3000번 포트로 보내즐거야 라는 의미이다.
=> 포트 포워딩을 적용한것이다.
만약 ports:
- 2000:3000
이라면 브라우저에서 2000번으로 접속하면 3000번으로 내보내 달라는 것. 이렇게 2000 번으로 접속해 실행하면 도커의 3000번 포트로 열리게된다.
localhost:2000 접속 -> 도커가 2000번으로 열려져있는 것이니 찾아들어가 3000번으로 바꿔실행한다.
AWS에 적용하기
EC2
내 눈앞에서 실행되는것을 포그라운드실행(foreground) 라고한다.
-> 그런데 쉘을끄면(컨트롤 + c 또는 브라우저를 끄면 꺼진다) 같이 꺼질수 있어 좋지 않다.
백그라운드에서 실행하도록 해야한다.
도커를 사용해 벡그라운드에서 실행되게 할 수 있다.
docker-compose up -d
기존 docker-compose 를 실행하는 명령어인 docker-compose up 에
-d 이 부분을 붙이면 백그라운드에서 실행된다.
docker ps 하면 실행되고있는 것을 볼 수 있고
벡그라운드 실행을 끄려면
docker-compose stop
이라는 명령어를 사용하면 된다.
수업은 수업대로 먼저 진행하고 후에 도커를 깔았다.
docker.com에 접속해 도커 다운로드 받기!
클릭해 받으면 docker와 docker-compose가 같이 설치된다.
내 컴퓨터에는 클릭해 설치한다고해도 가상컴퓨터인 EC2에는 어떻게 설치 하나??
따로따로 설치하는 수밖에 없다.
노드버전에따라 yarn install의 결과가 달라졌다.
따라서 이 경우에 도커를 기준으로 yarn install해야한다.
그렇다면 밖에서 (내 컴퓨터를 의미) 노드 모듈즈와 밖에서 build된 것들이 못들어오게 막아야한다.
vs코드에서 새 파일을 생성한다
.dockerignore 파일생성
-> 이 안에 node_modules
.next 이 두가지를 적어주고 저장한다.
node_modules .next
그러면 도커를 실행할때 적어준 파일들은 못들어오게된다.
그런데 이렇게 진행했을때 전체적으로 약간의 문제가 있다.
만약 소스코드가 바뀔경우, 도커에서는 이미지를 만들어 저장해 놓는데, 바뀌었기에 지금 도커안에는 저장된 내용이 없다.
따라서 build를 다시 진행해야한다.
이때 docker-compose build가 금방끝나지 않는다.
도커는 위에서부터 한줄 한줄 실행하며 캐시에 저장해놓는다.
소스코드가 바뀌면 바뀐소스코드로 build가 새로 필요하다. 캐시에 없는것을 발견하면 그것부터 아래 전부 모든것을 캐시에서 안가져오고 새로 실행된다.
그러니까 현재 입력한 파일을 살펴보면
FROM node:14 COPY . /class_build/ WORKDIR /class_build/ RUN yarn install RUN yarn build CMD yarn start
소스코드가 바뀐다는것은 COPY부분이 바뀐다는 것이다. 따라서 해당 부분부터는 캐시에서 가져오지 않고 새롭게 캐싱해 오래걸린다.
해결: yarn install 부분을 위로 올린다.
이렇게되면 package.json이 바뀌지 않는 이상에는 기존에 저장되어있는것을 가져오게된다.
먼저 package.json과, yarn.lock을 복사해 도커 폴더로 들고온다.
그다음 해당 폴더로 커서를 옮기고, 거기서 yarn install을 진행한다.
그다음 파일들을 복사해오고 build, 후에 start를 한다면 코드가 바뀐다면 이 부분부터 새로 시작되어 훨씬 빠르게 진행된다.
FROM node:14 COPY ./package.json /class_build/ COPY ./yarn.lock /class_build/ WORKDIR /class_build/ RUN yarn install COPY . /class_build/ RUN yarn build CMD yarn start
===> 소스코드 하나 바뀔때마다 yarn install되는것을 방지하는 전략이었다.
DNS는 도메인에 맞는 IP를 안내하는 일종의 네트워크의 114와 같은 서비스.
앞서 지정한 A레코드, CNAME 등은 모두 DNS 레코드의 일종이며, 처리할 방법에 따라 분류가 달라진다.
1) A
IP와 도메인 매핑 시 사용합니다. 1개의 도메인에 다수의 대상 서버 IP를 등록할 수 있습니다.2) AAAA
A레코드의 확장입니다. IPv6으로 매핑 시 사용하지만, IPv6이 아직 대중적으로 사용되지 못하고 있기 때문에 실제 사용은 저조합니다3) CNAME
서브도메인을 운영할 때 사용합니다. 서브도메인 ⇒ 주 도메인 ⇒ 대상 서버 IP 의 흐름으로 대상지를 찾습니다.4) MX
도메인과 연동된 메일 서버를 확인할 때 사용되는 메일 서버 레코드입니다.5) NS
도메인에 대한 네임서버를 확인할 수 있도록 하는 레코드입니다.6) SOA
도메인에 대한 상세 정보가 기록되어 있는 레코드입니다.
