반응형


톰캣(tomcat)의 기본포트가 8080인 이유를 아시나요???


많은 분들이 WAS로써 톰캣(tomcat)을 사용하실텐데요. 


특히나 요즘은 스프링부트로 인한 임베디드 톰캣을 사용하실줄로 압니다.


톰캣도 그렇고 스프링부트의 임베디드 톰캣도 그렇고 그럼 왜 기본 디폴트 포트는 8080이냐???하는 의문이 생길 수도 있는데요...(저는 그랬습니다...)


간단히 설명을 드리자면 리눅스나 유닉스는 1024이하의 포트(well-known port)들은 일반 유저 권한에서 바인딩 할 수 없도록 되어 있습니다.


이유는 보안때문인데요~!



8080포트에 대한 특별한 이유는 없습니다. 그저 1024이상의 포트중 하나를 임의로 디폴트로 설정한 것 일뿐(이라고 저는 생각합니다.)


하지만 외부 서비스를 해야하는경우에는 80포트로의 접근이 필요한 경우가 있습니다.


단순히 naver.com:8080이라고 사용자들이 접속하게 된다면 불편할테니까요...


그래서 루트권한(sudo)로 톰캣 포트를 80으로 설정 후 어플리케이션을 기동시켜서 사용할 수 는 있습니다.


다만! 위에서 말씀드렸듯 보안 문제가 존재합니다.


애드센스 자동삽입 광고


톰캣서버는 구동시에 tomcat 유저 권한으로 구동되게 됩니다. 때문에 톰캣을 통해 서비스되는 웹을 통해 해킹이 되더라도


tomcat유저 권한에 해당하는 부분까지만 접근 가능하게 됩니다.


따라서 루트권한(sudo)로 80포트로 구동시키게 된다면 해킹당했을 경우보단 안전하다고 할 수 있습니다.




물론 이런 문제를 회피하는 방법은 iptables를 통한 포트포워딩 방식이나 WAS앞단에 웹서버(apache, nginx)를 둬서 해결할 수 있지만


저 경험상에 의해서 iptables를 통해 포트포워딩을 할 경우 문제가 있었던 경험이 있기에 톰캣 80포트 8080 포트로 포워딩 이슈 


앞단에 웹서버를 두시고 서비스하는 방법이 좋다고 생각합니다.

반응형
반응형

톰캣은 웹 애플리케이션을 어떻게 관리하는가?


톰캣은 한 번에 여러 개의 웹 애플리케이션을 실행할 수 있도록 설계되어 있다.

웹 애플리케이션은 배포 명세서 web.xml을 가진 WAR 파일로 정의되어 있다. 대개 서버는 하나의 톰캣 인스턴스를 실행하며 관련된 WAR 파일이 톰캣 인스턴스의 webapps 디렉터리에 설치된다. 이는 기본 설정이며 위치를 변경할 수 있다.


톰캣의 구성 요소들

톰캣은 몇 가지 구성 요소로 이루어져 있는데, 그중 하나가 서블릿 컨테이너와 JSP를 처리하는 것이다. 서블릿 컨테이너 구성 요소는 카탈리나(Catalina)라고 하며 JSP 구성 요소는 재스퍼(Jasper)라고 한다.


톰캠 사용 문서를 읽다 보면 이 이름들에 대한 참조를 쉽게 볼 수 있다. 예를 들어 결과 로그 파일의 기본 이름은 catalina.out이고, 톰캣 홈 디렉터리의 환경 변수는 $CATALINA_HOME이다.


기본으로 실행 중인 톰캣 인스턴스는 webapps 디렉터리에서 일어난 변화를 감지한다. 새 WAR 파일이 이 디렉터리에 저장되면 톰캣은 WAR 파일 이름에 대응하는 디렉터리에 파일 내용을 풀어놓고 컨텍스트의 애플리케이션을 해당 이름에 대응시킨다.


예를 들어 BookingApplication.war라는 WAR파일을 webapps 디렉터리에 배포하면 그 파일은 BookingApplication 디렉터리에 압축을 푼다. 톰캣은 WEB-INF 하위에 있는 web.xml 파일을 읽고 정의된 대로 애플리케이션을 실행하고 /BookingApplication 경로를 통해 클라이언트에게 제공한다.


이 접근 방법은 개발 방향을 빠르게 전환하는 데 상당히 유용하다. 지속해서 배포 할 수 있는 방법을 갖게 할 뿐만 아니라 접근할 수 있는 서버에 단위 테스트를 완료해 빌드된 WAR 파일을 자동으로 배포할 수 있으며 통합 테스트를 준비할 수 있기 때문이다. 테스트 범위가 충분하고 팀의 개발 프로세스가 가능하다면 실제 환경에도 자동으로 배포되게 할 수 있다.


# Reference - 자바프로그래밍 면접 이렇게 준비한다.

반응형
반응형

 


 안녕하세요. 이번에는 최근에 읽은 '아파치 톰캣 7 따라잡기' 책에 대해 정리를 해보도록 하겠습니다. 처음에 회사에 왔을 때 아파치, 톰캣에 대한 지식이 많이 부족해 어려움들을 많이 겪었는데요. 서점에서 우연히 책을 보다가 해당 책의 제목을 발견하고 여전히 부족한 지식을 채우는데 도움이 될 것같아 일치의 망설임 없이 사서 읽게 되었습니다. 읽은지는 한 달정도 됬는데 한 번 읽고 넘기니 내용이 금방 가물가물 해지더라구요. 이참에 정리도 해놓고 틈틈히 보도록 해야겠다는 마음에 정리를 하게 되었습니다.


# 제가 몰랐던 내용이나 좀 더 확고히 하고 싶은 내용들에 대해서만 정리하기에 일목요연하지 못한점 양해 부탁드립니다.


ˇ 톰캣 bin 디렉터리에는 version.sh라는 스크립트가 있는데, 이 스크립트를 이용해 톰캣 버전과 시스템 정보를 확인할 수 있다. 

 


˚ 스크립트 설정 변경을 확인할 수 있도록 아주 유용한 스크립트 configtest.sh도 제공(톰캣 bin 디렉터리) 한다. configtest.sh 스크립트는 시스템 설정을 검토하고 에러를 찾아낸다. 


˚ 톰캣 설정파일인 conf 내부의 파일들에 대해 알아보자

  - catalina.policy : 톰캣 7의 보안 정책 권한을 설정하는 파일. JVM이 웹 애플리케이션에 어떤 보안 정책 권한을 적용할지를 결정한다.

  - catalina.properties : 이 파일은 서버를 시작할 때 검색하는 서버, 공유로더, JAR 등의 공유 정의를 포함한다.

  - server.xml : 톰캣의 중요 설정 파일 중 하나로 IP 주소, 포트, 가상 호스트, 컨텍스트 경로 등과 같은 중요 정보를 포함한다.

  - tomcat-users.xml : 역할에 기반한 정의에 따라 인증, 승인에 사용하는 파일이다. 이 파일은 데이터베이스의 사용자/암호/역할을 이용한 인증과 컨테이너로 관리되는 보안 구현에 사용된다. 이 파일을 고쳐서 사용자를 추가/삭제하거나 기존 사용자에 역할을 할당/비할당할 수 있다.

  - logging.properties : 톰캣 인스턴스의 로깅 프로퍼티(스타트업 로그 같은)를 정의한다.

  - web.xml : 톰캣 인스턴스가 시작될 때 모든 애플리케이션(톰캣 인스턴스로 로딩되는)의 기본 값을 정의한다. 웹 애플리케이션의 자신만의 배포 디스크립터를 포함하면 기본 디스크립터의 설정을 애플리케이션의 디스크립터의 설정으로 바꾼다.

  - context.xml : 애플리케이션을 실행할 때 이 파일의 내용을 로드한다. context.xml에는 세션 저장, 코밋 연결 추적 등과 같은 설정 파라미터가 있다.


˚ JDBC : 자바 데이터베이스 연결 JDBC, Java Database Connectivity은 자바 기반 데이터베이스 접근 기술로 클라이언트가 서버 데이터베이스에 접근하는데 필요한 API를 제공한다. JDBC는 관계형 데이터베이스에 맞게 만들어졌으며 데이터베이스 질의, 갱신 기능을 제공한다.


˚ JNDI : 자바 네이밍과 디렉터리 인터페이스 JNDI, Java Naming and Directory Interface 서비스는 자바 프로그래밍 언어를 사용해 만들어진 애플리케이션에 네이밍, 디렉터리 기능을 제공하는 자바 플랫폼 API다.


˚ DataSource : JDBC API를 이용해 관계형 데이터베이스에 접근할 때 사용하는 자바 객체다. 


˚ 톰캣의 배포, 설정 과정에서 흔히 발생하는 문제

  1. 

  [ 문 제 ] 


 ˚  사용자가 애플리케이션을 배포한 다음에도 여전히 예전 코드가 보인다고 불평


  [ 해결과정 ] 


 ˚  doc 베이스의 파일이 최근 파일인지 확인한다.


 ˚  톰캣 7의 logs 디렉터리에 있는 catalina.out을 통해 특정 WAR 파일명이 배포되었는지 확인한다


 ˚  이전 두 가지 모두 확인했는데도 문제가 해결되지 않으면 톰캣 서비스를 중지하고 다음 명령어를 이용해 work/Catalina/localhost 디렉터리에 있는 temp 디렉터리의 컨텐츠를 삭제한다. work/Catalina/localhost 디렉터리에 는 temp 디렉터리의 컨텐츠를 삭제한다.


cd /opt/tomcat/temp

rm -rf ../temp/*


cd /opt/tomcat/work/Catalina/localhost/

rm -rf ../localhost/*
 

 ˚ 톰캣 서비스를 재시작하고 사용자에게 다시 애플리케이션을 확인하도록 한다.



  2.

  [ 문 제 ] 


 ˚ 사용자가 한 노드에서는 현재 배포된 코드를 볼 수 있지만 다른 노드에서는 여전히 예전 코드가 표시된다고 불평


 [ 해결과정 ]


 ˚ doc 베이스의 파일이 최근 파일인지 확인한다.


 ˚ 톰캣 7의 logs 디렉터리에 있는 catalina.cout을 통해 특정 WAR 파일명이 배포되었는지 확인한다.


 ˚ 이전 두 가지 모두 확인했는데도 문제가 해결되지 않으면 node2의 톰캣 서비스를 중지한다. node1의 코드를 복제하도록 설정하고 다음 명령어를 이용해 work/Catalina/localhost 아래의 temp 디렉터리의 컨텐츠를 삭제한다. 


cd /opt/tomcat/temp

rm -rf ../temp/*


cd /opt/tomcat/work/Catalina/localhost/

rm -rf ../localhost/*


 ˚ 톰캣 서비스를 재시작하고 사용자에게 애플리케이션을 확인하도록 한다. 또한 node1과 node2가 복제 모드로 동작하는지 데이터베이스 상태를 확인한다.

 ˚ 양쪽 노드에서 데이터베이스에 연결한다.


  3.

  [ 문 제 ]

 ˚ server.xml을 고친 이후로 톰캣 인스턴스가 실행되지 않는 현상이 발생했다.


  [ 해결 과정 ]


 ˚ 톰캣 bin 디렉토리로 이동한다.


 ˚ configtest.sh를 실행한다.


 ˚ 출력된 내용들 중에 에러 메시지를 보면 톰캣이 이미 실행 중임을 알 수 있다. 따라서 웹 서버를 중지하고 temp 디렉터리를 비운다.


 ˚ 서비스를 다시 시작한다.




˚ 톰캣 7의 커넥터 종류 


 : 커넥터란 요청을 수락하고 응답을 리턴하는 교차점을 가리킨다. 톰캣에는 자바 HTTP 커넥터, 자바 AJP 커넥터, ARP(HTTP/AJP) 커넥터 세 가지 종류의 커넥터가 있다. 애플리케이션은 자신의 요구사항에 맞는 커넥터를 사용한다.


 1. 자바 HTTP 커넥터 


 : HTTP 프로토콜을 기반으로 하는 자바 HTTP 커넥터는 HTTP/1.1 프로토콜만 지원한다. 톰캣은 자바 HTTP 커넥터를 이용해 독립형standalone 웹 서버로 동작 할 수 있으며, jsp/서블릿 호스트 기능도 제공할 수 있다.



 2. 자바 AJP 커넥터


 : 자바 AJP 커넥터는 AJP(아파치 JServ 프로토콜)와 AJP를 통한 웹 서버 통신을 기반으로 한다. 자바 서블릿 컨테이너를 인터넷에 노출하고 싶지 않을 때 AJP 커넥터를 사용(다른 프론트엔트 서버를 이용)하며 톰캣 7에서 SSL 터미네이션을 처리하지 않는 상황이라면 AJP 커넥터를 매우 유용하게 활용할 수 있다. AJP 구현 예제로 mod_jk, mod_proxy 등이 있다.



 3. APR(AJP/HTP) 커넥터


 : ARP(Apache Portable Runtime)은 확장성, 성능, 다른 웹 서버와의 협력 작업 상황에서 능력을 발휘한다. 



 

오늘 정리는 여기서 마치도록 하고 정리 하지 못한 내용은 part.2로 포스팅하도록 하겠다.



반응형
반응형

 

 안녕하세요. 오늘은 전에 특정 서비스를 기존 빌드 서버에서 다른 빌드 서버로 이전하는 작업을 진행하면서 경험했던 삽질에 대해서 얘기해보도록 하겠습니다. 해당 서비스는 jdk1.7로 빌드가 되어야 하는데 옮기는 서버에는 jdk1.7이 아닌 jdk1.6이 깔려있어 서버에 jdk1.7을 설치하면서 겪었던 에로사항들에 대해 지금부터 포스팅하도록 하겠습니다.


1. 문제 상황

 


 해당 빌드 서버에 프로젝트를 이전하고 빌드를 수행했는데 다음과 같은 에러가 떴다. 살펴보니 서버와 해당 프로젝트 jdk버전이 맞지 않았던 것이다. (프로젝트 jdk1.7 서버 jdk1.6이 설치된 상황) 따라서 문제를 해결하기 위해 서버에 jdk1.7을 설치해야 하는 상황이었다. 



2. wget을 이용한 jdk1.7다운 그리고 또 다른 문제 발생

 jdk1.7 다운로드 페이지에 가서 wget을 하기 위한 url을 얻어와 서버에서 당연하게 wget http://download.oracle.com/otn-pub/java/jdk/7u67-b01/jdk-7u67-linux-x64.tar.gz 을 수행했다. 하지만 문제는 다음 그림과 같았다.

 

 빨간색 라인을 보면 해당 명령어를 수행했고 그 결과 나는 노란색 네모 상자와 같은 에러문구를 받게 되었다. 



ERROR: certificate common name `www.oracle.com' doesn't match requested host name `edelivery.oracle.com'.

To connect to edelivery.oracle.com insecurely, use `--no-check-certificate'. Unable to establish SSL connection.




 3. 문제 해결

wget으로 jdk1.6까지는 그냥 저런 식으로 다운받을 수 있지만 jdk1.7과 jdk1.8을 받기 위해서는 다음과 같은 명령어를 통해 다운 받을 수 있다.

 

  수행 명령 : wget --no-check-certificate --no-cookies --header "Cookie: oraclelicense=accept-securebackup-cookie" http://download.oracle.com/otn-pub/java/jdk/7u67-b01/jdk-7u67-linux-x64.tar.gz
 위와 같은 명령을 통해 다운이 되는 것을 알 수 있었다.
'--no-check-certificate'와 '--no-cookies -header'가 추가된 것을 볼 수 있는데 --no-check-certificate같은 경우에는 서버의 상당수가 self-signed인증서를 가지고 있는데, 이 경우 증명된 인증서가 아니라고 해서 문서를 읽어오지 못할 때 --no-check-certificate 옵션을 주어 해결할 수 있고 쿠키 값을 disable한다는 --no--cookies 옵션을 주어야 한다고 한다.

JDK 8을 받고 싶다면
RPM의 경우
​wget --no-check-certificate --no-cookies --header "Cookie: oraclelicense=accept-securebackup-cookie" http://download.oracle.com/otn-pub/java/jdk/8u5-b13/jdk-8u5-linux-x64.rpm

TAR.GZ의 경우
​wget --no-check-certificate --no-cookies --header "Cookie: oraclelicense=accept-securebackup-cookie" http://download.oracle.com/otn-pub/java/jdk/8u5-b13/jdk-8u5-linux-x64.tar.gz
JDK 7의 경우
TAR.GZ
​wget --no-check-certificate --no-cookies --header "Cookie: oraclelicense=accept-securebackup-cookie" http://download.oracle.com/otn-pub/java/jdk/7u60-b19/jdk-7u60-linux-x64.tar.gz



이상 포스팅을 마치도록 하겠습니다.






반응형

+ Recent posts