웹 애플리케이션 로컬 배포

개념

서버와 클라이언트

서버와 클라이언트 개념

• 서버
  • 네트워크에서 다른 클라이언트에게 서비스를 제공하는 컴퓨터 혹은 소프트웨어
• 클라이언트
  • 서버의 서비스를 제공받는 대상

서버의 종류

• 서버가 제공하는 서비스에 따라 분류
  • Web Server
    • 웹 서비스를 제공하기 위한 서버 컴퓨터
    • Apache, IIS, NginX 같은 웹 서버 소프트웨어를 사용하여 웹 서비스 가능
    • 주로 정적 콘텐츠(HTML, css)를 제공하는 프로그램
  • Web application server
    • 웹 애플리케이션을 제공하는 서버 컴퓨터
    • Tomcat, WebLogic, WebSphere 같은 웹 애플리케이션 서버 소프트웨어를 사용하여 웹 애플리케이션 서비스 제공
    • 동적 콘텐츠(DB 조회나 비즈니스 로직을 처리하여 결과를 제공하는 것)를 처리하는 프로그램
  • Database server
    • 데이터베이스 제공을 위한 서버 컴퓨터
    • Oracle, MS-SQL, MySQL 같은 데이터베이스 소프트웨어 사용하여 서비스
  • 파일 전송 서버
    • 대용량 파일을 빠르게 주고받기 위한 서버
    • VS-FTPD, IIS와 같은 소프트웨어 사용
  • 메일 서버
    • 메일 서비스를 위한 서버
    • Send-mail, Microsoft Exchange Server 같은 소프트웨어
  • 인쇄 서버
    • 공간 제약 극복, 인쇄할 수 있도록 하는 서버
    • 인쇄기 제품과 구성에 따라 다양한 소프트웨어 사용
• 서버 사용의 목적에 따라 운영 서버와 개발 서버 분리
  • 프런트 개발자는 개발 웹 서버에 개발하고 백엔드 개발자는 개발 웹 애플리케이션 서버에 개발하고 데이터베이스는 개발 데이터베이스 서버에 반영을 한다.
  • 서버가 감당해야 할 트래픽을 분산하고 서버 장애에 대해 개별적으로 대응 가능
  • 개발 서버에 적용되어 내용이 결정되면 운영 서버에 내용 반영되어 클라이언트가 최신 서비스 사용 가능

서버와 클라이언트 통신

• 서버는 서비스를 제공하고 요청을 받고 응답한다.
• 클라이언트는 서비스를 제공받고 요청을 하고 응답받는다.

서버 구성과 서버 환경 설정

• 서버 구성
  • 서버 컴퓨터의 종류, 대수, 네트워크 정책, 서버 수요 인원 예측 구성
• 서버 환경 설정
  • 구성된 서버가 서비스를 제공할 수 있도록 환경을 설정
  • 웹 서버는 Apache, IIS, NginX를 사용하여 설정
  • 웹 애플리케이션 서버는 Tomcat, WebLogic을 사용하여 설정
  • 데이터베이스 서버는 Oracle, MS-SQL 같은 데이터 베이스 소프트웨어 설정

CORS

Cross-Origin Resource Sharing

• 애플리케이션 간 출처(Origin)가 다른 경우, http 통신을 통한 리소스 접근을 제한하는 정책
• CORS는 접근 제한의 예외로 서전 설정으로 리소스에 선택적으로 접근할 수 있는 권한 부여
• CORS 설정은 서버의 응답 헤더에 Access-Control-Allow-Origin에 요청하는 클라이언트 출처를 작성한다.

CORS 정책 동작 방식

• 프리플라이트 요청(Preflight Request)
  • 요청을 보내기 전 OPTIONS 메서드로 사전 요청을 보내 리소스에 접근 권한이 있는지 확인하는 방법
  • 응답 헤더의 Access-Control-Allow-Origin으로 요청을 보낸 출처가 돌아오면 실제 요청을 보내게 되고 요청을 보낸 출처가 권한이 없다면 CORS 에러를 띄우고 요청 전달이 되지 않는다.
• 단순 요청(Simple Request)
  • 프리플라이트 요청을 생략하고 요청을 보내는 것
• 인증정보를 포함한 요청(Credentialed Request)
  • 요청 헤더에 인증 정보를 담아 보내는 요청
  • 출처가 다를 경우 별도 설정을 하지 않으면 쿠키를 보낼 수 없다.
  • 프런트, 서버 양측 모두 CORS 설정이 필요

CORS 정책 설정 방법

• Global 설정 클래스를 이용해 특정 도메인에 모두 적용하는 방법
  • Spring Security를 사용하여 SecurityConfigurationi 클래스를 만들어 cors 정책 적용
• 애너테이션을 이용해 컨트롤러에 적용
  • @CrossOrigin 애너테이션을 이용해 컨트롤러나 메서드에 설정
  • 세부 옵션으로 origins=”…”을 통해 설정 추가 가능

CSRF(Cross-Site Request Forgery)

• 다른 사이트일 경우 설정해야 한다.
• 사이트 간 요청을 위조하는 공격을 의미
  • 신뢰할 수 있는 사용자를 가장하여 원하지 않는 명령을 보내는 방식
• Spring Security에서 기본적으로 설정을 하지 않으면 CSRF 공격을 방지하기 위해 클라이언트로부터 CSRF Token을 수신 후 검증
  • 이런 경우 403 에러를 마주할 수 있어 disable 처리 후 진행

Tomcat 수동 배포

Jar vs War

공통점

• JAR와 WAR 모두 애플리케이션 배포 및 동작할 수 있도록 만든 압축 파일

차이점

• JAR의 경우 JRE만 있어도 쉽게 실행 가능하지만 WAR는 웹 관련 자원을 포함하는 웹 애플리케이션 압축 파일로 기본적으로 별도의 웹 서버가 필요하고 JAR 보다 더 넓은 범위를 압축하는 포맷
• Spring boot에 내장되어있는 톰캣(내장 컨테이너)을 기본적으로 사용하여 JAR로 패키징하여 사용 가능
• JAR(Java ARchive)보다 WAR(Web Application Archive)로 패키징한 경우 더 다양한 설정과 웹 환경 구성 가능
• WAR를 통해 하나의 톰캣 서버로 여러 도메인이 각각의 웹 애플리케이션 환경을 구성하는 virtual host 기능 사용 가능

JRE 및 톰캣 설치

JRE 설치 과정

• Open JDK 11버전은 JRE(Java Runtime Environment)를 제공하지 않고 런타임 환경 구성
• JRE는 JAVA 애플리케이션을 생성 및 실행하기 위한 구성 요소로 톰캣을 직접 설치하고 웹 애플리케이션을 실행하기 위해서 JRE가 설치되어야 한다.
• azul 홈페이지에서 운영체제와 버전에 맞게 .msi로 받아서 설치
• 환경 변수로 JRE_HOME을 이름으로 값은 설치 경로(C:\Program Files\Zulu\zulu-11-jre)를 작성

톰캣 설치

• 톰캣 공식 사이트에 접속하여 9 버전을 설치
• JDK 11 버전은 Tomcat 9 버전과 호환성이 높다.
• installer 형식(GUI 환경에서 설치)의 다운로드 파일과 바이너리 파일(톰캣 구동 파일 압축) 존재
• 바이너리 파일 다운 및 설치
  • MacOS에서는 tar.gz, Windows에서는 .zip 파일
  • 접근하기 편한 경로로 이동하여 설치
• 압축 해제하면 여러 폴더 생성
  • bin - 톰캣을 실행, 종료할 수 있는 스크립트 파일
  • conf - 서버 설정 파일이 존재
  • webapps - 톰캣 위에서 실행할 웹 애플리케이션 기본 저장 경로
    • .war 파일을 여기에 이동시키거나 설정 파일에서 경로 변경 가능

서버 실행 및 종료

명령어

• Windows
  • cmd 창을 통해 명령
  • bin 파일 경로에 가서 .\startup.bat을 실행하면 톰캣 실행
  • .\shutdown.bat을 실행하면 톰캣 종료
• Mac
  • 해당 bin 디렉터리에 가서 ./startup.sh로 톰캣 실행
  • ./shutdown.sh로 톰캣 종료
• 실행
  • localhost:8080으로 확인(기본 포트 8080)
  • 오류 발생 시 tomcat 폴더 우클릭, 속성, 보안에 편집을 누르고 Users를 선택해서 모든 권한 체크하고 적용(톰캣 폴더가 읽기 전용으로 설정된 경우)

톰캣으로 웹 애플리케이션 실행

• JAR → WAR 포맷 변경
  • build.gradle 수정
  • plugins{ ... id 'war' //추가 }
• @SpringBootApplication이 붙은 클래스 수정
• @SpringBootApplication public class TomcatPracticeApplication extends SpringBootServletInitializer { //extends SpringBootServletInitlaizer를 상속 public static void main(String[] args) { SpringApplication.run(TomcatPracticeApplication.class, args); } //configure 메서드를 override해서 builder.sources로 해당 클래스를 설정하고 리턴 @Override protected SpringApplicationBuilder configure(SpringApplicationBuilder builder) { return builder.sources(TomcatPracticeApplication.class); } }
• ./gradlew build 명령어로 프로젝트를 빌드하면 .war 파일 생성 확인
  • 이 파일을 톰캣의 webapps 디렉터리에 옮겨놓으면 톰캣이 실행될 때 해당 애플리케이션 실행
  • .war 파일의 이름이 ROOT인 경우는 바로 실행 가능하지만 이름이 다른 경우 conf에서 server.xml 파일에서 추가 설정해야 한다.
• server.xml 파일 수정
  • Host 내부에 Context 설정 추가

  <Host name="localhost"  appBase="webapps" unpackWARs="true" autoDeploy="true">
          <Context path="/" docBase=""  reloadable="false" > </Context>
          <!-- Context 설정 추가 docBase에는 프로젝트 이름 설정 -->
  
          <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs"
                 prefix="localhost_access_log" suffix=".txt"
                 pattern="%h %l %u %t &quot;%r&quot; %s %b" />
  </Host>
  

  • 톰캣을 실행하면 .war 파일을 압축 해제해서 webapps에 동일한 이름 디렉터리 생성
• 톰캣 포트 변경
  • server.xml 파일 수정

  ...
  <Connector port="8080" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="8443" />
  ...
  <!-- 기본 설정된 8080 포트를 다른 포트로 변경 -->
  

Ngrok을 사용해 로컬 서버 실행

Ngrok

개념

• 네트워크 설정을 하지 않아도 방화벽을 넘어 외부에서 로컬 환경에 접근할 수 있게 해주는 터널링 프로그램
• 무료 플랜의 경우 연결 세션 2시간 유지되고 개발 목적으로 임시 도메인을 발급받아 테스팅하기 유용(AuthToken 등록 시 시간제한 없다)

사용 목적

• 개발 영역이 나누어져 있는 환경에서 통신 테스트할 때 유용
  • 프런트와 백엔드 사이의 통신을 할 때 사용 가능
• 하나의 컴퓨터에 작업을 몰아두어 로컬로 테스트하거나 클라우드에 배포하고 진행할 수 있지만 모든 세팅이 필요하거나 지속적인 관리가 필요하다는 단점이 존재
• ngrok을 설치하고 특정 포트를 실행하면 임시 도메인이 할당되어 외부에서 로컬 환경에 접근 가능

설치

• Ngrok 설치 페이지에서 해당 운영체제에 맞게 다운로드

실행

• ngrok 프로그램을 실행시키고 ngrok.exe http 8080을 실행하면 8080 포트로 임시 도메인을 연결하여 외부 접근하도록 설정 가능
• 출력된 화면에 Forwarding 부분에 임시 도메인 확인 가능
• 외부 컴퓨터에서 임시 도메인으로 접속 가능

Token 등록

• Ngrok 홈페이지에서 회원가입 후 발급되는 Auth Token을 등록할 수 있다.
  • 1회 세션 지속시간이 24시간으로 증가
  • 토큰 등록 전에는 웹 브라우저를 통해 임시 도메인에 연결 시 HTML이 보이지 않지만 토큰 등록 후 이용 가능