BIcOding

**개요 >서버의 종류 -웹 서버 -웹 애플리케이션 서버 -데이터베이스 서버 -파일 전송 서버 -메일 서버 -인쇄 서버 >운영 서버와 개발 서버 >CORS : 애플리케이션 간 출처(origin)이 다른 경우 HTTP 통신을 통한 리소스 접근이 제한됨. : 이를 제한하는 정책을 SOP(Same Origin Policy) 라고 함. : 다른 Origin 일 때, 선택적으로 접근 권한을 부여하는 정책을 CORS라고함. : SOP가 리소스 공유를 막지만 CORS로 설정하여 예외 조항을 두는 셈. >CORS 설정 -Spring Security 이용하기 -@CrossOrigin 설정하기 >CORS와 CSRF -CORS (Cross-Origin Resource Sharing) : 다른 출처에 대한 설정 -CSRF (..

>Nginx를 Reverse Proxy Server로 사용하기 : Spring Boot와 연결 : Nginx는 80 port, Spring Boot는 8080 port 사용 1. nginx 설치 (Stable version) 2. nginx 실행 (확인: 기본값 localhost:80 접속) 3. /conf/nginx.conf 수정 -proxy 경로 설정 : localhost:8080 -proxy_header 설정 4. nginx 재실행(nginx -s reload) 5. server 실행(localhost:8080; 서버 애플리케이션) 6. nginx 종료(nginx -s stop) //정확한 이유는 모르겠지만 nginx -s quit 명령어로 종료하는게 확실하게 종료가 된다. /* nginx 을 실행..

>Tomcat : Apache 사의 오픈 소스 웹 애플리케이션 서버(WAS, Web Application Server) : 서블릿 컨테이너만 있고, Spring Boot의 기본 내장 서버(자바 서블릿 컨테이너에 대한 공식 구현체) : 독립적으로도 사용 가능하고, 다른 웹 서버와 연동도 가능 : `spring-boot-starter-web`의 모듈에 `spring-boot-starter-tomcat` 모듈이 포함되어있음 //톰캣이 아닌 WAS를 통해 프로젝트를 실행할 수도 있음. >Jetty : eclipse 재단의 HTTP 서버이자 자바 서블릿 컨테이너(Tomcat 대신 사용가능) : 오픈 소스이며, 애플리케이션에 내장 가능 : 적은 메모리를 사용하여 가볍고 빠르기 때문에 소형 장비, 소규모 프로젝트에 ..

>서버 과부하를 방지하는 수평 확장 종류 1. 스케일업 : 서버의 물리적인 부품을 기존보다 고사양으로 바꾸는 작업 : 고성능으로 서버 과부하를 방지 : 하지만 최고 사양으로 맞춘 서버임에도 이를 뛰어넘는 수의 요청이 들어온다면 과부하걸림 2. 스케일아웃 : 서버의 갯수를 여러 개로 늘리는 작업 : 여러 서버로 요청을 나누어 받아 서버 과부하를 방지 >로드 밸런서 : 여러 서버로 나누어 전달할 요청들을 교통 정리하는 기술(혹은 프로그램) >로드 밸런서 구분 기준 : 어떤 계층에서 무엇을 바탕으로 교통 정리를 하는지에 따라 종류가 나뉨 >로드 밸런서 종류 -L2 : 데이터 전송 계층에서 Mac 주소를 바탕으로 로드 밸런싱 -L3 : 네트워크 계층에서 IP 주소를 바탕으로 로드 밸런싱 -L4 : 전송 계층에서..

>프록시 서버, Proxy Server : `Proxy`는 `대리인`이라는 의미 : 클라이언트가 서버에 바로 접근하지 않고 중간에 있는 대리인을 통해 우회하도록 만드는데, 여기서 대리인 역할을 프록시 서버가 함. >프록시 서버를 통해 우회하는 이유 : 캐시를 통해 더 빠른 이용 : 보안 : 분산 처리 >프록시 종류를 나누는 기준 : 요청, 응답 전달 과정에서 클라이언트와 서버 중 어디에 가까이 위치하는지에 따라 종류가 나누어짐. : 클라이언트에 가까우면 클라이언트 서버를 대신해주고, 백엔드 서버에 가까우면 백엔드 서버를 대신해주는 느낌이 있음. >프록시 서버의 종류(대표적인) -Forward Proxy : 클라이언트에 가까이 위치함. : 클라이언트는 포워드 프록시 서버를 통해 인터넷에 접속하기 때문에 외..

>수동 배포 1. 완성된 앱을 github에 올리기 2. EC2 인스턴스에서 github repo를 클론 3. 해당 앱의 빌드 결과물을 실행 4. S3 버킷을 통해 웹 사이트 호스팅 >자동 배포-파이프라인 1. github repo에 작업물을 push 2. 특정 브랜치에서 push를 감지 3. buildspec.yml 을 통해 빌드 결과물을 생성하고 S3에 저장 4. S3에 저장된 빌드 결과물을 가져와서 appspec.yml 파일을 읽고 EC2 인스턴스에 배포하고 실행 명령 >자동 배포-Github Actions 1. Github push로 github actions 실행 2. Github actions 작업을 작성해놓은 .yml 파일을 통해 코드 빌드, S3로 전송, 배포 명령 실행 3. appspec..

>배포 자동화 : 한 번의 클릭 혹은 한 번의 명령어 입력으로 전체 배포 과정을 자동으로 진행하는 것을 뜻함. //배포 과정 흐름에 대한 공부 >배포 자동화의 이점 -시간 절약 -휴먼 에러 방지 >배포 자동화 관련 용어 -파이프라인(Pipeline) : 소스 코드 관리부터 서비스 배포까지 일련의 과정 전체를 의미함. : 배포 자동화는 곧 파이프라인의 재실행을 의미. -스테이지(Stages) : 파이프라인을 단계적으로 쪼갠 단위 : 배포 자동화가 이루어지기 위해 스테이지가 순차적으로 이루어짐. : 대표적인 스테이지의 예시로 (1)Source stage (2)Build stage (3)Deploy stage가 있음. : 스테이지는 필요에 따라 더 세분화되거나 간소화될 수 있음. /* - 파이프라인 예시 (1..

>컨테이너 : 애플리케이션이 의존성, 네트워크 환경, 파일 시스템에 구애받지 않는 애플리케이션 상자. : Docker라는 기술 위에서 실행되도록 만들어짐. >이미지 : 애플리케이션과 애플리케이션 구성을 함께 담아놓은 템플릿. : 이미지라는 템플릿으로 컨테이너를 생성할 수 있다. : 같은 이미지로 여러 개의 컨테이너를 생성할 수 있다. 이게 곧 수평 확장이다. : 기본 이미지를 만들고, 기본 이미지에 필요한 부분을 수정하고 추가하여 새로운 이미지를 만들 수도 있다. : 예를 들면, 스프링부트 초기 세팅을 기본 이미지로 삼고, 내가 만든 애플리케이션을 추가/커밋하여 이미지화 시킬 수 있다. >레지스트리 : 이미지를 저장하는 공간을 레지스트리라고 한다. : Docker Hub, Amazon ECR이 대표적인 ..

>컨테이너 방식의 장점 -의존성 충돌 문제 해결 1. 개발과 배포 환경을 일치시킨다. 2. 수평 확장을 쉽게 해준다. 3. 각 서버에 새로운 내용을 배포하기 쉽게 만들어준다. (1) 개발과 배포 환경을 일치시킨다. -개발 문제 : 컨테이너 방식을 사용하지 않는다면, 애플리케이션을 개발하는 개발팀은 모두 같은 버전과 같은 개발 도구를 설치하여 개발 환경을 동일하게 구축해야한다. : 하지만 그럼에도 특정 변수에 의해 어떤 팀원의 개발 환경에서는 애플리케이션이 실행이 안될 확률이 있다. : 컨테이너를 사용하면 YAML 파일과 명령어로만 이러한 문제를 간단히 해결한다. -배포 문제 : 배포 문제 또한 개발 문제와 같이 사용자의 런타임 환경에 따라 문제가 발생할 수 있는 부분이다. : 하지만 이 또한 컨테이너 방..