포트폴리오 초간단 배포

배포 -> 애플리케이션을 사용자가 사용할 수 있는 상태로 만드는 것

✅ 개발 사이클 내에서의 배포

• 개발 서버를 배포 한 후 (개발서버에 여러가지 테스트 진행)
• 위에서 문제가 없다면 이제 운영서버에 배포를 진행

✅ 배포

• 자동 배포 : 실무에서 많이 사용함 ex) Jenkins -> CI/CD 툴
• 수동 배포

✅ 리눅스 기본 명령어

• pwd : 현재 작업중인 경로를 나타냄 (place working directory)
• cd : 현재 작업중인 디렉토리의 위치를 이동(변경)하는 명령어 (change directory)
• mkdir : 디렉토리(폴더)를 생성할 때 사용 (make directory)
• ls : 현재 위치나 특정 경로의 디렉토리 내용의 리스트를 출력하는 명령어(list)
• touch : 파일을 생성하는 명령어

💡 mkdir 과 touch 차이
mkdir 명령어로도 파일을 만들 수 있지만, ls 명령어로 확인하면 mkdir로 만든 파일은 파란색으로 나오는 것을 볼 수 있다. 즉 mkdir로 만든 파일은 디렉토리이며, touch로 만든 파일은 하얀색이며 일반적인 파일임

• cat : 파일들을 순서대로 읽고 순서대로 표준 출력하는 명령어(concatenate)
• vi : 리눅스와 유닉스에서 사용하는 편집기 명령어
  -> 입력 모드, 명령 모드, 마지막 행 모드로 총 3가지 로 구성
  -> vi 명령어로 접속시 명령모드로 접속됨

명령 모드
-> 방향키를 이용하여 커서를 이동할 수 있음 (한줄 삭제 및 한줄 붙여 넣기, 글자 삭제 등 가능)

입력 모드
-> 명령 모드에서 i나 a 를 입력해서 접속 가능 (자유롭게 코드나 글 작성 가능)
-> 명령 모드로 다시 돌아오려면 ESC 누르면 됨

마지막 행 모드
-> 명령모드에서 shift + ; 를 입력하면 화면 맨 밑단에 :______ 하며 입력할 수 있는 공간 나옴
-> 여기서 현재까지 작성한 내용을 저장하고 vi를 종료하려면 wq 입력
-> 저장 하지 않고 그냥 종료할거면 q 또는 q! 입력

• rmdir : 디렉토리를 삭제하며 비어있는 디렉토리가 아니면 삭제 실패
• rm : 파일이나 디렉토리를 삭제한다
  ex) rm -rf * // 현재 디렉토리의 모든것을 강제로 삭제
  옵션

  -r : 해당 폴더와 해당 폴더 안에있는 모든 파일, 디렉토리까지 제귀적으로 삭제.
  -d : 빈 디렉토리를 삭제하는 옵션
  -i : 각 파일 및 디렉토리를 삭제할 때 삭제여부를 묻도록 하는 옵션
  -f : 모든 오류를 무시하고 강제로 삭제하는 옵션

✅ 프론트 엔드만 있는 프로젝트 보여주기

• 깃허브에서 새로운 레파지토리를 만든 후 index.html 파일 부분 접속해서 해당 주소 링크 복사
• https://raw.githack.com/ 에 접속해서 복사 붙여넣기
• Use this URL in production 부분의 주소를 사용

단점 : 백엔드가 있는 프로젝트일 경우 불가능하며, 유지보수에 문제가 있음

프론트엔드에서 API를 호출하는 프로젝트를 위와 같은 방법으로 할 경우 -> CORS 에러가 발생

✅ CORS (Cross-Origin-Resource-Sharing)

• 사용자를 보호하기 위한 웹 브라우저의 보안 정책
• 쉽게말해 공유된 자원에 대한 렌더링이나 실행을 차단하는 것

• ajax 요청을 한 목적지와 프론트 페이지가 달라서
• 다른 origin이기 때문에 실행이 차단됨
• 요청은 잘 날라갔으나, 화면에 렌더링되지 않은 것임
  
  

만약 CORS 정책이 없다면? -> 정보가 유출되는 보안 문제를 막아줄 수 없음

API가 실행 되는 것 자체가 위험 한것이 아닌가?
-> 위의 예시는 GET 메서드의 방식임

GET 이아닌 POST PUT DELETE 와 같이 서버에 자원상태를 바꿀 여지가 있는 메소드들은 다르게 동작

preflights : 미리 보내는것 (사전 전달)

• 쉽게 말해서 서버로 바로 요청을 보내는 것과 다르게, 지금 보내는 요청이 유효한지 확인하기 위해
  OPTION 메소드로 예비 요청을 보내는 것
  
• 두 요청 중 preflight 가 먼저 날아가서 origin을 확인 한 것이며
  그 위 요청은 실질적으로 날아가지도 않은 것임

즉 POST PUT DELETE 와 같은 방식은 기본적으로 cross-origin 요청을 보내기 전에
OPTIONS 메소드로 preflights 를 전송

✅ CORS 이슈를 해결하는 방법

• API를 제어할 수 있는 환경에서 -> API 서버에 Access-Control-Allow-Origin 헤더 추가
• 프런트엔드 프레임워크 사용하는 경우 -> 클라이언트에서 프록시 사용 (프론트엔드 미들웨어)
• 서버측에서 프록시 사용(nginx) -> 서로 다른 프론트엔드와 백엔드 서버를 하나의 서버인것처럼 만듬

✅ CI/CD
Continuous Integration - 지속적 통합
Continuous Deployment - 지속적 배포

✅ http 와 https
http로 전송할 경우 -> 패킷에 있는 데이터가 네트워크상에 노출이 됨 (정보 유출)
https 는 인증서를 사용해서 암호화 통신을 할 수 있음

https 만드는 사이트 추천 : www.sslforfree.com