Activator /  Eclipse  로 Play2  실행하기 

          이 포스트는  Play2 를 Activator 를 이용하여 윈도우에서 설치하는 방법에 대해 말합니다. 

          Scala 기반이며 프로토타입 프로젝트는 나중에 AWS Beanstalk 에 올릴 예정입니다.

           * Windows  :  8.1

   * Play : 2.5.4           

   * Activator : 1.3.10

           * Java : 1.8 

           * Scala : 2.1  ( 여기서는 따로 설치할 필요 없음)

           * Eclipse : Mars 

                                                                      PlayFramework 조망도 

미리 설치해 두어야할것들 

          * Java 1.8  이상  ( java -version 을 통하여 확인하라)   Oracle’s JDK Site.

           설치후 JAVA_HOME 로 경로 설정 하세요.

           CMD 창 열어서 확인해 봅시다.

            java -version  // 1.8 이상

            javac -version // 1.8 이상 

        Downloading Activator    

           압축푼 디렉토리는 read/write 권한을 주세요.

           압축푼 디렉토리를  PLAY_HOME 으로 경로 설정 하세요.

              windows 8.1 ) 제어판 - > 시스템 -> 고급 시스템 설정 - 고급 - 환경 변수 

 변수 이름 : PLAY_HOME

 변수 값     : D:\work\Study\Play2\activator-1.3.10

     압축푼 디렉토리를 PATH  경로 설정 하세요.

       %PLAY_HOME%\bin;

        Activator   테스트 

            CMD 창에서  activator ui 를 입력하면 activator 가 브라우저로 뜹니다. 

      여기서 갈림길이.. ui 를 사용하지 않고 그냥 Play2 프로젝트를 만드려면 

      CMD 창에서 그냥 만들수도 있다. activator new testApp 처럼 ~

      즉 프로젝트 만들어서 이클립스에서 가져다 쓰려면 그냥 만드는게 편하다. 

      아무래도 웹보다는 이클립스에서 개발하는게 좋은점도 있으니~

       Activator   로 프로젝트 만들기 

        Play2 실행 

               브라우저에서 http://localhost:9000 와 같이 입력해서 확인합니다. 

          Activator 프로젝트를 이클립스로 Export 

          이클립스 ( Scala IDE ) 에서 Play2  Import 하기 

           이클립스 ( Scala IDE ) 에서 Play2 작동시키기 

             1.  CMD 창에서 프로젝트 폴더로 가서 Activator run 으로 서버를 실행시키고 

                 2.  브라우저를 띄운후 http://localhost:9000

                 3. import 된 프로젝트를 이클립스에서 변경한후  브라우저를 리프레쉬하면 적용 되 있습니다.

          이클립스 ( Scala IDE ) 에서 Play2  디버깅 하기 

              1.  CMD 창에서  ctrl+D 를 눌러서 서버를 멈추고 

    2.  activator -jvm-debug 9999 run  으로 다시 실행 시킨다. 
    3. 이클립스에서 Debug As, Debug Configurations -  Remote Java Application 

   에서 Port 를  9999 바꾸고 Debug 를 하라. 실행중인 어플리케이션에 접속할 것이다. 

Deploy Playframework (Play!) to AWS Elastic Beanstalk with Jenkins (번역) 

플레이프레임워크는 가볍고 높은 성능을 가진 웹어플리케이션 플랫폼으로써 상태를 갖지 않는 웹 티어에서 완벽하게 작동한다. AWS Elastic Beanstalk 에서도 환상적으로 작동되는데 이 포스트는 플레이프레임워크를 AWS Beanstalk 에서 작동시키기 위해 젠킨스를 이용하는 방법에 대해 말한다.  

플레이프레임워크 버전 2.3+ 과 2.3,2.4,2.5에서 테스팅 되었다.

Step 1: 플레이프레임워크 프로젝트를 준비하라

새로운  "Java SE" container types 타입을 이용하여 Elastic Beanstalk 상에 디플로이 하기 위해 우리는 우리의 플레이 프레임워크에 약간의 변경을 할 것이다. 먼저 dist 라는 이름의 디렉토리를 최상위에 만들어라. .ebextension 과 Procfile를 통해서 ElasticBeanstalk 에게 프로젝트를 런치하는 방법에 대해 알려줄것이다. 

https://github.com/Enalmada/play-beanstalk  (만들어져있는 프로젝트) 

Procfile파일을 만들어서 넣고./bin/ajmoss 의 ajmoss 자리에 build.sbt  에 정의되어있는 네 프로젝트 이름을 넣고-Dconfig.file=conf/live.application.conf를 추가하라 아래처럼 ~

web: ./bin/ajmoss -Dhttp.port=5000 -Dconfig.file=conf/live.application.conf

좋다. 이제 ElasticBeanstalk 에 Deploy 하기위한 준비는 끝났다. Java SE containers 는  nginx  를  reverse proxy 역할로 사용하는데 기본 프록시는 5000번 포트를 사용한다. 만약 커스텀 설정이 필요하면 가능하고 다음을 살펴보라  customize the reverse proxy using these instructions.

Step 2: 젠킨스 만들고 설정하기 

만약 AWS 안에 젠킨스 인스턴스가 없다면 이것을 참고해서 설치하자. install jenkins as outlined in this article.   Oracle JDK 8  젠킨스는 이것도 필요하다. OpenJDK 버전은 지원하지 않는다. 

다음으로 Playframework 프로젝트를 빌드하기위해 아래 처럼   Typesafe Activator 를 인스톨하자:

sudo cd /opt/
sudo wget https://downloads.typesafe.com/typesafe-activator/1.3.7/typesafe-activator-1.3.7-minimal.zip
sudo unzip typesafe-activator-1.3.7-minimal.zip
sudo ln -s activator-1.3.7-minimal activator
sudo touch /etc/profile.d/activator.sh
sudo chmod +x /etc/profile.d/activator.sh
sudo echo 'export PATH=$PATH:/opt/activator/' >> /etc/profile.d/activator.sh
sudo source /etc/profile.d/activator.sh
sudo chown jenkins /opt/activator/activator
sudo chgrp jenkins /opt/activator/activator

이제 activator 는 인스톨되었고  AWS Elastic Beanstalk Deployment Plugin. 를 인스톨 한다.

이제 젠킨스 job 을 만들 준비가 되었다. 당신의 리포지토리에 접속하기위한 소스코드 매니지먼트를 셋업한다. 나는 github +  Git Plugin 을 체크아웃하기위해 사용한다.

다음으로 빌드 스텝을 만드는데 프로젝트 분산을 위해 .zip 파일로  프로젝트를 만든다.  
"Execute Shell" bash 커맨드로 아래와 같이 한다 : 

/opt/activator/activator clean dist
mv target/universal/*.zip target/elasticbeanstalk.zip

이제 우린 AWS Elastic Benastalk 를 위한 추가 빌드 스텝을 추가 할 것이다.  작은 전처리 작업이 필요하다 

Step 3: AWS  권한 을 만들라 

AWS 상에 젠킨스를 접근하고 Elastic Beanstalk 리소스를 제어할 수 있는  key/secret key 페어가 필요하다. S3 버킷을 프로비전해야하고 버킷에 우리의 빌드/리소스를 업로드할 것이다.  가장 간단한 방법은  S3 Bucket 에 직접적으로 권한을 주는것이다 다음 예와 같이 :

{
    "Version": "2008-10-17",
    "Id": "Policy1400141113811",
    "Statement": [
        {
            "Sid": "Stmt1400141111261",
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::603736890550:user/jenkins"
            },
            "Action": [
                "s3:DeleteObject",
                "s3:GetObject",
                "s3:PutObjectAcl",
                "s3:PutObject"
            ],
            "Resource": "arn:aws:s3:::ajmoss-artifacts/*"
        }
    ]
}

노트 : 이 예제는 나의  S3 bucket 이다 이름은 'ajmoss-artifacts'.

Step 4:  AWS Elastic Beanstalk 빌드 스텝을 설정한다.

Jenkins 를 설정하며   "AWS Elastic Beanstalk"  을 위한 빌드 스텝으로 각 섹션을 설정할 것이다.

"AWS Credentials and Region" 에  access key / secret key 를 넣자.

"Application and Environment" 에 EB 리소스의 이름을 넣자. 

"Packaging" 은 root object 를 설정한다 다음과 같이  target/elasticbeanstalk.zip

"Uploading"  업로드 하기위한 S3 bucket 를 설정하며  "S3 Key Prefix"  는 젠킨스를 위한  디렉토리이다. 

"Version and Deployment" 각 빌드의 이름을 설정한다.

나는 ${GIT_COMMIT}-${BUILD_TAG} 를 사용하는데  git commit hash plus the build tag from Jenkins 를 사용한다

Step 5: Kick Ass

이제 Elastic Beanstalk applications 을 손쉽게 할 수 있게 됬다.

현재 웹서비스를 Play 랑 스프링중 무엇으로 만들지 고민하던 중에 발견한 글을 공유합니다. 

https://www.quora.com/Which-is-better-Play-Framework-or-Spring-MVC-How-should-I-decide-what-to-use 번역을 했으며 . 2016년 7월 현재 이 글이 쓰여진 시점하고 무엇이 얼마나 달라졌는지 혹은 무엇이 잘못된 정보인지를  댓글로 보충해주시면 많은 분들에게 도움이 될듯합니다. 저의 아주 한정된 지식보다는 모든사람이 힘을 합치는게 좋겠죠.  Collaborative intelligence!!

Play Framework vs Spring MVC  

답변 1 Play2 scala 광전사님) 

링크드인은 Spring MVC 를 사용하다 몇년후에, Play Framework 로 바꿔 버렸는데 .  주요 이유는 다음과 같다.

1. 개발자 생산성 :  스프링은 시작하고 변경을 확인하는데 꽤 오래 시간이 걸리며, 그 때 재시작을 해야하며 그것은 큰 프로젝일 경우 수십분이 걸릴 수 있다. API 들은  무겁고 거추장스럽다. 모던 app 을 빌드하기위해 필요한 내장된 부가기능이 거의 없다. 사실, 규모가 있는 어떤 회사의 스프링 개발자와 대화해 보아도 더티한 면을 많이 보게 될것이다. 허접한 커스텀 프레임워크를 스프링 MVC 위에 쏟아붙고 관리도 제대로 안되고 있다. 링크드인도 예외는 아니었다. 헬~ 심지어 스프링소스에 있는 그 녀석 스스로도 스프링 MVC 위의 또다른 레이어를 빌드하고 자빠져있다. 그것은 스프링 부트라고 불린다. 
   
   왜 그러냐고 ?  스프링 MVC 는 그 자체로 맛탱이 간 놈이기때문이지.  반면 Play 는 hot-reload 변경이 가능하고, 그 덕분에 너는 환상적인 코딩-리프레쉬-코딩-리프레쉬 사이클에 따라 리듬을 탈 수 있게되는거지. 코딩하는게 아니라 리듬에 몸을 맡긴다고나 할까? API 들은 또 얼마나 파워풀하고 함수형 프로그래밍이 주는 구성력 덕분에 얼마나 좋은가 말도 못하지. 그리고 이 현대적인 프레임워크는 대부분의 유명인사들을 자체적으로 지원하고 있어, JSON,Web Sockets, DB access, Web Service calls 등등 말야 
   
   
2. Non-blocking I/ON :  스프링은 블럭킹이지. 의미가 뭐냐고?  니가 I/O (사용자로부터의 request, remote servcie call ) 를 할때마다  쓰레드로 떠 받치고 있어야한다는거야. 대부분의 현대 어플리케이션은 그들의 대부분의 시간을 I/O 하는데 사용하거든 , 그때마다 아까 팠던 진지 덮고 또 파고 ~  삽질하고 있다는거지.
   Play 는 완전한 non-blocking 이라 서비스지향 아키텍처 (마이크로서비스라는 멋진말로 불리기도 하지) 에는 엄청 좋은 성능을 보여줘 그리고 웹소켓도 지원하고, 스트리밍도 지원하고  (이걸 보라~ Play Framework: async I/O without the thread pool and callback hell).  이것은 엄청난 가능성을  열어 놓는건데 , 특히  BigPipe 스타일의 스트리밍에서 말이지.(이걸 보라고  Composable and Streamable Play Apps and Ping-Play: Big Pipe Streaming for the Play Framework).
   
   
3. 함수형 프로그래밍 :  스프링은 변경가능한 아슬아슬한 객체,어노테이션,XML 설정파일, 그리고 몇가지 마술들 로 이루어져있는데, 이것들은 처음엔 OK 된것으로 보여도 먼가 잘못되기 시작하면 넌 먼가를 해야하지만 그것들이 일으키는 부작용 (부수효과)의 파도에 넌 그대로 익사하고 말꺼야.  간단히 말해서 대부분의 스프링 MVC 어플리케이션은 헝크러진 실타래의 더미라고 봐도 무방.  니가 실타래 풀 수 있을까?  그냥 남들 안보는곳에서 가위로 삭둑하는게 보이네;; 반면 Play 는 함수형 프로그래밍 코어로 만들어져서 함수형 프로그래밍의 장점을 가지고 있지. 그것들은 쩌는 타입시스템을 사용하며 (타입세이프 클래스뿐만아니라 타입세이프 라우트,템플릿,빌드시스템 등등 더 많이) 이것들은 코드를 더 쉽게 이해하고 구성되고 새로 이용되게 해주고 디버그 문제도 쉽게 해결할 수 있게 해주고 커스텀 플러그인도 쉽게 만들어주지. 등등 너무 많다.  
   
   
4. 쩌는 오류 리포팅  :  스프링 가지고는 거대하고 이해 할 수 없는 스택 트레이스만 보았을꺼야. 그거 이해 하기 힘들었다고? 스프링님은 쩌는데 내가 실력이 없어서 어려웠던거라고 제발 생각하지마 ~ 스프링이 구린거니깐.
   플레이님은 말이지 굉장히 명쾌한 오류메세지만 브라우저 상에 잘못된 코드 조각과 보여줄거야. 타입시스템의 더 나은 사용예라고 말 할 수 있을거 같아. 대부분의 에러는 컴파일 타임 에러들 이거든 런타임이 아니라.  
   
   

더 많은 정보는 다음을 살펴보면되

The Play Framework at LinkedIn. 왜 LinkedIn 이  Play 로 갈아 탔는지 말해주는 영상 

2013. 6. 26 

Node.js vs Play Framework.  Node 와  Play 를 예로 보여주는 영상 

Composable and Streamable Play apps.  non-blocking I/O 와 functional programming 의 파워를 BigPipe-style streaming in Play 를 통해 알려주고 있는 영상 

답변 2 비둘기님)

제 생각엔 적재적소라는 말이 맞는거 같아요. 자신의 상황에 적합한 툴을 선택하는 거죠.

Play 는 어떤 상황에는  맞게 잘 만들어졌어요. 그리고 스프링은 다른 상황에 적합하죠. 둘이 겹치는 부분에서 조금 헷깔릴 수 도 있지만 무엇을 선택했다고 해서 나중에 망했다~ 라고 까지 할 만한 건 없을거에요. 

사실 Play 를 저는 깊게 파보진 못했지만 웹싸이트를 만들기 위한 툴이란걸 알고 있습니다. 아마 당신이 SOAP 나 REST 서비스를 하면서 주요 목적이 웹싸이트를 만드는것이라면 뭐 전형적인 웹어플리케이션 말이죠 Play 는 당신의 친구가 되어 줄겁니다.

스프링 MVC 는 스프링이라는 거대한 플랫폼의 한 부분이에요. 스프링에는 MVC 말고도 엄청난 프로젝트들이 있습니다. Spring MVC 그 자체는 스프링 어플리케이션에 MVC 행위를 하는 컴포넌트를 추가한것일 뿐이에요. 그 말은

스프링의 진정한 가치는 그 많은 컴포넌트들을 가지고 적재적소에 사용할 수 있다는 것입니다. 

이런 상황에서 스프링은 빛을 발할것입니다. 만약 Play 라면 한계가 있으며 당신에게 이미 만들어진 바퀴를 또 만들라고 강요할거에요. 

Updated Oct 4, 2015 · View Upvotes