[Thymeleaf] 스프링에 타임리프 연동하기

매우 쉽습니다. ViewResolver만 바꿔주면 됩니다. 기존에 JSP뷰를 사용하고 있었다면 InternelResourceVewResolver를 사용해서 JSTL뷰를 설정한 다음 prefix와 suffix 정도를 설정해서 사용하고 있으실텐데요.

ThymeleafViewResolver로 바꿔주시면 됩니다. 그리고 ThymeleafViewResolver가 필요로하는 빈도 몇개 등록해야되구요. 아.. 그전에 메이븐 의존성부터 추가하셔야겠군요. 저는 스프링 자바 설정을 사용했는데 코드 보시면 XML 설정으로도 쉽게 설정하실 수 있으실 겁니다.

좋아~ 이제야 드뎌 서버 띄우지 않고 html만 작업하면서 뷰를 만든다음 서버 띄우고나서도 계속 사용할 수도 있겠군요.

아파치 httpd에 SSL 인증서 설치하기

먼저.. 준비물

  • abc.pem: 인증 기관에서 받은 인증서 파일
  • abc.key: 인증 기관에 줄 인증 파일 만들 때 생성한 키 파일
  • global-abc.pem: 글로벌 인증서 파일
  • 암호: 키 파일 만들 때 사용한 암호 문구
  • mod_ssl.so: apache/modules에 들어있나 확인

1. mod_ssl 로딩 설정하기

apache/conf/httpd.conf 파일 열고 mod_ssl.so 검색.

vim에서 :/mod_ssl.so 쳐보면 됨.

mod_ssl.so 로딩하는 부분이 없으면 다음과 같은 설정 추가.

LoadModule ssl_module modules/mod_ssl.so

여기서 중간에 있는 ssl_module은 일종의 변수명 같은데… 그냥 이대로 쓰지 뭐.

2. httpd.conf하고 apache/conf/extra/httd-ssl.conf 연결하기

httpd.conf에서 ssl_module이라고 검색하면 방금 위에서 설정한 LoadModule말고 <IfModule> 이라는 부분이 있다.. 없으면 추가.

<IfModule ssl_module>
SSLRandomSeed startup builtin
SSLRandomSeed connect builtin
Include conf/extra/httpd-ssl.conf
</IfModule>

그 부분에 저렇게 httpd-ssl.conf 설정을 추가하도록 설정. 아마도 httpd.conf 설정이 너무 복잡해 질까봐 이러식으로 분리하는것 같은데… 이게 더 복잡한거 같에. @_@;;; 어쩌겠어.. 이렇게 하라는데.. 흠냐..

3. httpd-ssl.conf 설정

위에부터 쭉 보면 Listen 443이라고 SSL 적용할 포트 설정이 있고 기타 여러가지 설정이 있는데 이 중에서 다음 설정을 현재 디렉토리 기준으로 잘 맞춰준다.

SSLPassPhraseDialog exec:/apache/conf/ssl/ssl.pass

/apache/conf/ssl/ssl.pass라는 파일은 없다. 이 작업 끝나면 만들꺼임. 파일 경로를 꼭 저렇게 할 필요도 없고.. 단지 실행 가능한 파일이어야 한다. 즉 x 권한이 있어야 한다. 이렇게 설정하지 않으면 기본값이 builtin인데 그렇게 해두면 httpd 띄울때마다 직접 인증서 키 파일 만들 때 사용한 암호를 입력해줘야해서 매우 번거롭다.

ServerName 도메인

인증서 발급받을 때 사용한 도메인을 입력해준다. 이 설정부터는 <VirtualHost> 안에 들어간다.

SSLProtocol -all ====
SSLCipherSuite ====

이건 인증서를 발금해준 인증 기관의 매뉴얼대로 설정해야 할 것 같다. 내가 받은 인증 파일 설명서엔 저렇게 되있던데… 흠.. 중요해 보이는 정보는 ====로 자막처리 했으니 상관없겠지.

SSLCertificateFile “abc.pem 파일 경로”

여기에 abc.pem 파일 경로를 풀로 적어준다.

SSLCertificateKeyFile “abc.key”

여기에 abc.key 파일 경로를 풀로 적어준다.

SSLCACertificateFile “global-abc.pem”

여기에 global-abc.pem 파일 경로를 풀로 적어준다.

나머지 설정은 그냥 기본값 그대로 둔다. 설마.. SSLEngine on이라는 설정이 off로 되어있진 않겠지..

4. 암호 파일 만들기

위에서 SSLPassPhraseDialog 설정을 추가했었는데 거기서 지정한 파일을 다음과 같이 만든다.

#!/bin/sh
echo 암호

즉 이 파일을 실행하면 암호가 입력되도록 하는 것이다. 서버 실행할 때 마다 귀찮지 않게…

아. 그리고 이 파일 만든 다음에 꼭 실행 권한을 주도록 하자.. chmod 755 ./ssl.pass 같은 식으로.. 그래야 httpd가 이 파일을 실행해서 암호를 입력 받을 수 있지… 그렇지 않으면 httpd가 아에 안뜬다.

5. 서버 띄우고 확인

이제 apache/bin으로 가서 ./apachectl start 등으로 아파치를 실행하고 netstat -na | grep 443으로 443번 포트가 동작하는지 확인하고 웹 브라우저에서 https://도메인 입력해서 확인한다. 끝.

Thymeleaf 죽이네.

“백리향 잎사귀”

http://www.thymeleaf.org/doc/Natural%20Templating%20in%20Spring%20MVC%20with%20Thymeleaf%2020120217.pdf

뭔지 알고싶다면 위에 있는 발표자료를 쭉 훑어보시면 됩니다.

일단.. 저는 뷰 만들 때 프리마커나 벨로시티같은 템플릿 엔진을 쓰지 않습니다. 그냥 JSP + JSTL + Spring Tags를 사용합니다. 사이트매쉬나 타일즈같은 레이아웃 엔진도 쓰지 않습니다. 그냥 JSP 태그파일을 씁니다. 랜더링 속도가 전체 앱 성능에 얼마나 영향을 준다고 그 불편한 문법과 설정을 적용하며 애플리케이션에 덕지 덕지 붙이지 싫습니다. 성능이 문제면 차라리 varnish 같은걸 추가해서 캐싱을 하죠 뭐. 잡다구리한걸 잔뜩 붙이고 싶지 않아요.

그런데 진짜 괜찮은 템플릿 엔진이 있군요… 타임리프라.. 캬.. JSP 개발도 마찬가지고 프리마커나 벨로시티를 쓸때도 마찬가지인데.. 뭐냐면..

보통 뷰 만들 때 HTML로 프로토타입을 만들기 나름이죠. 이때는 편하게 HTML로 만들어서 서버를 띄우지 않고 브라우저에서 바로바로 확인하면서 HTML/CSS/JS 코딩을 합니다. 어느정도 됐다 싶으면 그걸 JSP로 변경합니다. 그럼 이제부턴 지옥입니다. 매번 서버를 실행해야지만 뷰를 변경할 수 있죠. 이게 아주 짜증입니다. 그런데 타임리프는 안그래요. 일단 파일을 변경할 필요없이 HTML 그대로 두면 되고 그 상태 그대로 서버를 띄우고 보면 템플릿이 적용되고, 서버를 띄우지 않고 웹 브라우저에서 그냥 열어도 작업이 가능한 HTML 그대로 보여줍니다. JSP나 프리마커 뷰로 바꾼뒤부터는 그렇게 안되기 때문에 거기에 비해서 타임리프 뷰는 개발이 훨씬 편하겠죠.

어떻게 그런지는 안갈쳐 드리죠. 위에 있는 PDF를 보세요. 이 기능을 이름하여 내츄럴 템플릿이라고 하더군요. 이름 참 잘 지었네요.

추가로..

  • 스프링 바인딩 지원
  • 스프링 PE 지원
  • 스프링 EL 지원
등 스프링과 아주 합이 잘 맞는 템플릿 엔진인듯 합니다.

앞으론 이걸 한번 써봐야겠습니다.

[스프링 3.2] 비동기 서블릿 지원 맛보기

https://github.com/SpringSource/spring-framework/pull/69

https://github.com/rstoyanchev/spring-mvc-async-sample

흠냐.. 맨 위에껀 스프링 3.2에 작업중인 코딩 내역이고 아래 링크는 실제로 어떻게 사용할 수 있는 보여주는 예제 프로젝트입니다. 로센이 작업했네요. 멋쟁이.

예제 프로젝트를 받아서 돌려봤는데 매우 깔끔하게 동작합니다. 뷰를 Thymeleaf라는 것을 사용했는데… 흠.. JS랑 맛물리는 뭔가가 있는것 같기도 하고 첨보는거라 뷰가 어떻게 돌아가는지 몰겠네요. 어쨌든 HTML 파일 하나를 사용하고 있습니다.

자바스립트는 두개를 사용하는데 하나는 제이쿼리, 하나는 넉아웃.js 그리고 제이쿼리 플러그인으로 하나더 jquery-stream.js이라고 있기는 한데… 소스코드를 봐도.. 크롬 개발자 도구로 봐도.. 사용하진 않는것 같습니다.

스프링 설정은 자바 설정으로 만들었는데 굳이 설정 파일은 루트와 웹을 나눴으면서 애플리케이션 컨텍스트는 나눠서 등록하지 않는 모습이 이번에도 보이는데… 왜 CCL을 사용하지 않고 DS만 사용할꺼면서 빈 설정은 나누는지 잘 모르겠네요. 그럴꺼면 걍 웹용 설정 파일만 만들어도 될텐데 말이죠. web.xml도 없고 톰캣7 기능을 사용해서 자바 웹 설정으로 web.xml을 대신합니다.

서론이 길었군요. 스프링 3.2부터는 @RequestMapping이 붙은 메서드에서 리턴할 수 있는 타입이 두개가 더 생깁니다. 비동기 서블릿과 관련된 리터타입이죠.

  • 스프링에서 만들어 둔 DeferredResult
  • 자바 컨커런시에 있는 Callable

지금 데모용 프로젝트에서는 DeferredResult를 사용하고 있습니다. DR을 사용하는 부분만 보겠습니다.

[클파: 인사이드] 어떻게 만들었나?

http://www.slideshare.net/derekcollison/design-of-cloud-foundry

http://www.infoq.com/presentations/Cloud-Foundry-Inside-the-Machine

몇몇 핵심 요소들이 있는데…

  • 커널 (CloudFoundry OSS): 핵심 PaaS 시스템
  • 커널과 오케스트레이터(Orchestrator) 쉘: IaaS 상단의 레이어
  • 오케스트레이터: IaaS 생성, 관리 및 관장(?)

커널이라고 부르는건 VCAP이라는 이름으로 오픈소스로 공개한 핵심 패스 시스템을 말하는 것 같고.. 오케스트레이터 쉘은 뭔지 잘 몰겠넹;; 설명도 좀 짧고. 나중에 여러 계층과 어떻게 소통하는지 자세히 설명하겠다는군요.

오케스트레이터는 라이프사이클 관장으로 이 부분이 꽤 어려운 문제를 해결하는 부분이라고 합니다. 멀티 노드 설치 스크립트 등을 만들고 사용하는건 그리 어려운 부분이 아니라네요. 그런 부분보다는 “동작중인 시스템”을 만드는 것입니다. 즉.. 애플리케이션은 계속 돌면서도 그 밑단의 시스템이 죽었는지.. 전부 새로 껐다 켰는지 알 수 없게 만드는거라고 얼핏 이해했는데… 흠냐.. 맞겠지?.. 그렇게 하는게 어려운거라고 하고.. 이걸 어떻게 할 수 있게 했는지 설명하겠다고 하네요.

하드웨어 하드웨어고, IaaS 대충 알겠고, 오케스트레이터가 매우 중요하고 어려운 부분인데. 아마도 여기에 nats가 매우 중요한 역할을 하고 있을 것 같고.. CF Kernel이라는게 vcap일꺼고.. clients는 뭐.. http over json으로 통신하는 CLI나 STS 플러긴이나 웹앱이겠지.

클파의 기반 전제(Basic Premises)

  • Fail Fast
  • Self Healing
  • Horizontally Scalable Components
  • Distributed State
  • No Single Point of Failure
  • Should be as simple as possible

한글로 옮기기도 어렵고 이해하기도 어려운  용어들만 써있네. 덴장 ㅋㅋ 무학의 통찰이 필요해.

제대로 동작하지도 않는 상황에서 최적화 로직을 돌릴 필요는 없으니까 Fail Fast를 시키고 그래야 빨리 복구 시킬 수 있다. 실제로 자살하는 앱을 만들어서 배포한담에 얼마나 빨리 복구되는지 실험도 해봤다. 수평확장이 가능하기 떄문에 한 인스턴스로 4천 TPS 정도가 가능하다면 4만 TPS도 문제가 아니다. 분산 시스템이란게 본래가 복잡한데.. 가능한 단순하게 만들려고 노력한다.

기반 패턴

  • 이벤트 드리븐
  • 비동기(애싱크로너스)
  • 논 블락킹
  • Independent(인디페넌), Idempotent(아이뎀포던)
  • Message Passing
  • Eventually Consistent

클파의 신경 시스템(널브 시스템)에 대해서 이야길 많이 할텐데.. 그게 가능케 하는게 바로 idempotent하기 때문이다. 메시징 시스템은 내가 직접 만들었고.. 나머진 잘.. 몰겠네 블라블라

기반 설계(Basic Design)

  • 모든 컴포넌트는 loosely coupled 시킴
  • 메시징 기반
  • JSON 페이로드
  • HTTP 또는 File/Blob 데이터 전송

커널 특징

  • 모두 동적으로 발견한다.
  • 무작위로(? in any order) 실행하고 확장한다.
  • 필요에 따라 빠지거나 추가할 수 있다.
  • HTTP와 JSON을 사용해서 모니터링
  • Location independent

“모두 동적으로 발견한다”는 말은 신경 시스템으로 메시지를 보내서 모든 컴포넌트다 나는 어딨고 나는 무슨 타입이고 실행된지 얼마나 됐고 내 모니터링 풀은 여깄다 등등을 알수있다. 애플리케이션이 돌고 있는 IP와 포트를 알아낼 수 있지만 사실 애플리케이션이 돌고 있는 곳과 아무런 의존성이 없다.

커널 구성요소

  • 라우터
  • 클라우드 컨트롤러
  • DEA
  • HealthManager
  • Service Provisioning Agent
  • Messaging System

커널의 구성요소가 어떻게 구성되어 있는지 보여주는 논리적인 뷰인데.. HTTP REST 요청은 모두 라우터를 통해서 들어오기도 하고 일부는 애플리케이션으로 바로 들어오기도 한다. 이것은 즉 애플리케이션에 적용하는 모든 원칙을… fault tolerance, high availability, scaling을 커널 구성요소에도 그대로 적용한다는 뜻이다. DEA 풀은 매우 클수도 있고 매우 작을 수도 있다. 헬쓰매니저는 이곳에서 유일하게 싱글톤이다.

이건 아키텍처인데 녹색은 HTTP, 파랑은 메시징, 보라는 뭐지..? 왜 말을 안해;;;

오늘은 여기까지. 20분 48초.