서버 shutdow.sh진행하면 protocol이 제대로 종료되지 않는 상황을 확인
server.xml에서 연결된 Connector가 두개가 존재하고 있다는 사실을 파악 후 웹서버를 사용하고 있지 않기에 AJP를 주석으로 처리했다.
위의 작업을 진행하면서 확인한 사항들이다.
1. tomcat에서 확인된 문구
❓ multi service on tomcat protocol handler initialization failed tomcat
원인은 AJP Connector 취약점 문제로 AJP Connector 속성의 secretRequired 설정이 필요해졌다.
해결 방안 1 : server.xml 에서 secretRequired를 false로 변경.
<Connector protocol="AJP/1.3"
address="::1"
port="8009"
redirectPort="8443"
secretRequired="false" />
https://tomcat.apache.org/tomcat-9.0-doc/config/ajp.html
해결 방안 2 : Apache, Tomcat의 secret Key를 추가해준다.
//Tomcat server.xml
<Connector protocol="AJP/1.3"
address="0.0.0.0"
port="8009"
redirectPort="8443"
secret="oingdaddy" />
//Apache workers.properties
worker.example.host=192.168.0.1
worker.example.port=8009
worker.example.secret="oingdaddy"
하지만 취약점을 보완하기 위해서 설정된 true 설정을 임의로 false로 바꾸는 행위를 진행해도 괜찮은 것인가...?
Tomcat 문서를 확인해보면 아래와 같은 이유로 trusted Network에서 접속하는 상황이 아니라면 변경을 권장하지 않는다.
당연하다 보안은 폐쇄적일 수록 좋다. (현재 상황은 0.0.0.0)이다
그리고 workers.properties는 무엇인가?
https://tomcat.apache.org/connectors-doc/reference/workers.html
중요한 부분은 대기중인 Tomcat 인스턴스라는 부분이다. 흔히 알듯이 [Apache : 웹 서버, Tomcat :WAS], 웹 서버가 tomcat process(the worker)로 전달하는 기능을 진행해준다.
해당 시나리오와 같이 Tomcat Worker을 특정 웹 서버를 대신해서 서블릿을 제공하게 Tomcat Woker을 설정할 수 있다. 쉽게 말하면 하나의 톰탯에서 여러개의 서비스를 구동시킬 때 로드 밸런싱을 진행해준다.
-> 그럼 결과적으로 Apache를 설치해서 웹서버 + WAS의 형식을 갖춰야 한다는 것.... (하지만 웹 서버를 설정하지 않겠다고 결정 됐다.)
+ 그럼 AJP는 무엇인가?
Apache JServ Protocol (AJP)
웹서버 뒤에 있는 WAS로 부터 웹서버에서 받은 요청을 WAS로 전달해주는 프로토콜이다.
아파치와 톰캣을 연동하디 위해서 AJP를 통해서 서로 통신한다.
아파치는 이를 사용하여 80포트로 들어오는 요청은 자신이 받고, 이 요청중 서블릿을 필요로 하는 요청은 톰캣에게 전달하여 처리한다. ( httpd.conf의 JMount설정 )
해당 프로토콜(ajp)는 다양한 WAS에서 지원한다.
ex) 아파치, 톰캣, 제우스, 웹로직, 웹스피어 등...
현재 개발 서버 status, apache 상태
그럼 우선 내 서버의 스펙, 상태를 점검하자
https://yjshin.tistory.com/108
1. Apache 버전 확인
# httpd -v
2. Apache 상태 확인
# systemctl status httpd
# service httpd status
3. Apache 시작
# systemctl start httpd
# service httpd start
# apachectl start
4. Apache 중지
# systemctl stop httpd
# service httpd stop
# apachectl stop
5. Apache 재시작
# systemctl restart httpd
# service httpd restart
# apachectl restart
이 이후는 추가 작업을 위해 남겨두는 글이다.
https://kkamagistory.tistory.com/37
방법은 [tomcat connector(mod_jk), mod_proxy, reverse_proxy]가 존재한다.
설정을 진행할 때 mod_jk보다는 mod_proxy를 사용하는 것이 설정도 간단하고 ngnix 같은 차세대 웹 서버로 이전하기가 쉬우니 mod_proxy 사용을 권장한다.
mod_proxy : reverse proxy로 동작하는 모듈.
위의 동작은 보안상 문제가 발생할 수 있기에 reverse proxy를 숙지하고 진행하는 것을 권장한다.
https://www.lesstif.com/system-admin/forward-proxy-reverse-proxy-21430345.html
프록시 [Forward, Reverse]
아파치 web server은 mod_proxy를 통해서 forward proxy, reverse proxy 두가지 기능을 제공한다.
Forward Proxy
사용자의 도메인 요청을 포워드 프록시 서버가 요청을 받아서 요청한 도메인으로 연결하여 그 결과를 클라이언트에 전달 (forward)를 진행한다.
> forward proxy는 주로 캐싱 기능이 존재하며 정해진 사이트만 연결하게 설정하는 등 웹 사용 환경을 제한 할 수 있기에 보안에 매우 중요한 기업 환경에서 주로 사용한다.
Reverse Proxy
사용자가 리버스 프록시에 요청을 보내면 리버스 프록시응 이요청을 받아서 내부 서버(WAS)에서 데이터를 받은 수 해당 데이터를 사용자에게 전달하는 방식이다.
대부분의 WAS는 Web Server 기능을 제공하므로 Reverse proxy가 없이 내부 WAS가 직접 서비스를 제공해도 되지만 이렇게 구성하는 이유중 여러가지가 있습니다.
그럼 Reverse Proxy를 사용하는 이유는 무엇인가?
1. 보안
2. 속도의 안전성(ex : cloudflare, akami와 같은 CDN도 Reverse proxy로 동작하는 캐시 서버)
3. 신뢰성 증대 : 프록시를 cluster로 구성하는 사용성을 높일 수 있으며, 사용자의 증가폭에 따라서 상황에 맞게 Web Server, WAS를 유연하게 늘릴 수 있다는 장점이 존재한다. 리버스 프록시 앞에 L4 또는 load balancer 붙이면 Round Robin, Least Connection등 상황에 맞는 분배 알고리즘을 적용해 서비스 신뢰성을 높일 수 있다.
'개발 > 서버' 카테고리의 다른 글
WAS - WEB 연결하기 (with. mod_proxy) (0) | 2024.05.12 |
---|---|
Linux Apache Tomcat 연동 (동일 서버 설정) (0) | 2024.05.11 |
[Linux] 서버 로그 관리해보자! (0) | 2022.07.16 |