클라우드 컴퓨팅 환경에서 프로젝트를 생성하고 코딩하고 배포까지 한큐에 할 수 있는 서비스가 나왔다.

https://codenvy.com/

구글google이나 깃헙github 계정을 이용하여 signup하고 현재 서비스되고 있는 PaaS에 배포설정까지 가능하다.

codenvy.com 에서 지원하는 기술들이다. 선택하는 기술들에 따라서 배포가능한 PaaS가 달라진다.

[Java Spring] 기술을 선택한 뒤, 선택가능한 PaaS 서비스

[None]을 선택하고 application을 실행했다.

codenvycorp.com 에 앱을 생성하고 배포하여 테스트해볼 수 있다.

클라우드 컴퓨팅 환경에서 개발(협업)하고, git 을 이용하여 소스를 관리하고, PaaS에 애플리케이션으로 배포까지 할 수 있는 서비스.

이 서비스의 유료화 정책은 어떻게 될까?

정말 궁금하군. 

이메일 발송용 템플릿 엔진으로 사용하려고 Thymeleaf 를 찾았다.

전 프로젝트에서는 StringTemplate3를 사용했었는데, StringTemplate4로 바뀌면서 그 사용법이 많이 바뀐 탓에 새로 익혀야할 것 같아 찾다보니 몇몇 사람들의 추천하는 글을 보고는 덜컥 시도를 해본다.

ㅡ_-);; 주된 삽질의 끝은 오탈자였다. 하아...

Spring에서 사용하는 예제 : http://www.thymeleaf.org/springmail.html

<!-- THYMELEAF: Template Resolver for email templates --> 

<bean id="emailTemplateResolver" class="org.thymeleaf.templateresolver.ClassLoaderTemplateResolver"> 

  <property name="prefix" value="mail/" /> 

  <property name="templateMode" value="HTML5" /> 

  <property name="characterEncoding" value="UTF-8" /> 

  <property name="order" value="1" /> 

</bean> 


<!-- THYMELEAF: Template Resolver for webapp pages   --> 

<!-- (we would not need this if our app was not web) --> 

<bean id="webTemplateResolver" class="org.thymeleaf.templateresolver.ServletContextTemplateResolver"> 

  <property name="prefix" value="/WEB-INF/templates/" /> 

  <property name="templateMode" value="HTML5" /> 

  <property name="characterEncoding" value="UTF-8" /> 

  <property name="order" value="2" /> 

</bean> 


<!-- THYMELEAF: Template Engine (Spring3-specific version) --> 

<bean id="templateEngine" class="org.thymeleaf.spring3.SpringTemplateEngine"> 

  <property name="templateResolvers"> 

    <set> 

      <ref bean="emailTemplateResolver" /> 

      <ref bean="webTemplateResolver" /> 

    </set> 

  </property> 

</bean> 

<!-- THYMELEAF: View Resolver - implementation of Spring's ViewResolver interface --> 

<!-- (we would not need this if our app was not web)                              --> 

<bean id="viewResolver" class="org.thymeleaf.spring3.view.ThymeleafViewResolver"> 

  <property name="templateEngine" ref="templateEngine" /> 

  <property name="characterEncoding" value="UTF-8" /> 

</bean> 



내가 적용한 코드

<!-- THYMELEAF: Template Resolver for email templates -->

    <bean id="emailTemplateResolver" class="org.thymeleaf.templateresolver.ClassLoaderTemplateResolver">

        <property name="prefix" value="META-INF/template/mail" />

        <property name="suffix" value=".html"/>

        <property name="templateMode" value="HTML5" />

        <property name="characterEncoding" value="UTF-8" />

        <property name="order" value="1" />

        <!-- Template cache is true by default. Set to false if you want -->

        <!-- templates to be automatically updated when modified.        -->

        <property name="cacheable" value="true" />

    </bean>

    

    <!-- THYMELEAF: Template Engine (Spring3-specific version) -->

    <bean id="templateEngine" class="org.thymeleaf.spring3.SpringTemplateEngine">

        <property name="templateResolvers">

          <set>

            <ref bean="emailTemplateResolver" />

          </set>

        </property>

    </bean>

이렇게 설정을 해놓으니 계속 

org.thymeleaf.exceptions.TemplateInputException: Error resolving template "email-test", template might not exist or might not be accessible by any of the configured Template Resolvers

TemplateEngine에서 템플릿 파일을 찾지 못한다는 오류를 뿌린다. ㅡ_-);;

2시간 정도 삽질을 한 결과를 알아냈다.

<bean id="emailTemplateResolver" class="org.thymeleaf.templateresolver.ClassLoaderTemplateResolver">

        <property name="prefix" value="META-INF/template/mail" />

...

</bean>

의 항목을

<bean id="emailTemplateResolver" class="org.thymeleaf.templateresolver.ClassLoaderTemplateResolver">

        <property name="prefix" value="META-INF/template/mail/" />

...

</bean>

으로 바꾸니까 된다.

미묘한 차이인데, 발견했는가? ㅡ_-)?

예제의 '/' 하나를 무시한 결과가 나의 3시간 삽질의 차이를 낳았다. Orz.

ihoneymon@ihoneymon-desktop:/workspace/git-repositories/never-ending-study$ git push origin develop

ssh_exchange_identification: Connection closed by remote host

fatal: Could not read from remote repository.


참고 페이지 : https://github.com/nodester/nodester/issues/346


git pull --rebase

후 git pull origin develop 정상동작

첨부파일 : 

20130515_Vagrant_chef.md


동일한 개발환경을 지닌 가상머신(인스턴스) 의 배포를 손쉽게할 수 있다면, 얼마나 좋을까! 라는 생각을 구현한 멋진 서비스가 아닐까? 서버 리소스를 스케일업하는 클라우드 컴퓨팅 환경에서 인스턴스 관리를 위한 도구로 사용할 수 있지 않을까라는 상상을 잠시 해본다. 사용하려는 서버환경을 구축한 후에 이것을 box로 만들어 확장하는 서버 이미지를 대신하도록 만들어두고, 처음 가동할 때 chef에 의해서 기본적인 추가작업(내가 우분투를 설치하고 로그인하여 처음 실행하는 sudo apt-get update; sudo apt-get upgrade; 도 자동화할 수 있겠지.)이 실행되도록 할 수 있으니, 증설한 서버에 대한 반복적인 작업이 확실히 줄어들 것이다. 스터디가 진행될수록, 개발PC 가상머신을 배포하기 위한 용도보다는 클라우드 컴퓨팅에서 사용할 인스턴스 배포용으로 적합할 것 같다는 생각을 가지게 되었다.


Vagrant

  • 사이트 : http://www.vagrantup.com/
  • 동일한 서버 개발환경 꾸미기
    • 개발과 실서버의 일치를 위해 로컬 가상머신을 손쉽게 관리하자.
    • 로컬 개발서버를 가상머신으로 관리하나? ㅡ_-)? 그러고보니, 전에 몇번 그랬던 적은 있다.
  • 관련 정보
    • 작성자 : @mitchellh
    • 오픈소스 MIT 라이센스
    • Ruby로 작성됨
    • 현재 1.0.5
    • 사용OS : ubuntu 12.04까지 나왔심.
  • Vagrant Command Line Interface
    • package : 지금까지 구성된 인스턴스를 vox로 만들어서 배포
    • halt : shutdown
    • provision :
    • up : start!
  • 실행방법
    1. vagrant box add <config.vm.box name> http://files.vagrantup.com/<box-image>.box
    2. vagrant init <config.vm.box name>
      • 선택적으로 config.vm.box 에 지정되는 value를 지정할 수 있다.
      • <config.vm.box name>을 지정하지 않으면 base로 기본등록된다.
      • 이 명령이 실행된 위치에 Vagrantfile 라는 설정파일이 생성된다.
    3. vagrant up : 실행!!

      Bringing machine ‘default’ up with ‘virtualbox’ provider…
        [default] Setting the name of the VM…
        [default] Clearing any previously set forwarded ports…
        [default] Creating shared folders metadata…
        [default] Clearing any previously set network interfaces…
        [default] Preparing network interfaces based on configuration…
        [default] Forwarding ports…
        [default] – 22 => 2222 (adapter 1)
        [default] Booting VM…
        [default] Waiting for VM to boot. This can take a few minutes.
        [default] VM booted and ready for use!
        [default] Configuring and enabling network interfaces…
        [default] Mounting shared folders…
        [default] – /vagrant
        ihoneymon:vagrant ihoneymon$

      • 실행이 완료된 후 vagrant ssh 를 입력하면 실행된 가상머신에 터미널로 접속가능하다.
      • port forwarding : 22 => 2222
    4. vagrant halt : 가상머신 끄기
  • 기타명령
    • package
      • vagrant package –help
        • VirtualBox에 이미 등록되어 있는 가상머신을 vagrant box로 패키징하여 바이너리 파일로 만들어 배포가능하도록 만든다.
      • vagrant package –base vagrant_1368646716 –output ubuntu-lucid32.box
        • ubuntu-lucid32.box
    • vagrant package 로 box 만들기

      • vagrant package –base vagrant_1368621809 –output ubuntu-lucid32.box

      ihoneymon:temp ihoneymon$ vagrant package –base vagrant_1368621809 –output ubuntu-lucid32.box
        [vagrant_1368621809] Clearing any previously set forwarded ports…
        [vagrant_1368621809] Creating temporary directory for export…
        [vagrant_1368621809] Exporting VM…
        [vagrant_1368621809] Compressing package to: /ihoneymon/temp/ubuntu-lucid32.box
        ihoneymon:temp ihoneymon$ ls
        vagrant_lucid32.box

      package로 생성한 ubuntu-lucid32.box를 test라는 이름으로 추가하고 확인

      • vagrant box add test ./ubuntu-lucid32.box

      ihoneymon:temp ihoneymon$ vagrant box add test ./ubuntu-lucid32.box
        Downloading or copying the box…
        Extracting box…te: 200M/s, Estimated time remaining: –:–:–)
        Successfully added box ‘test’ with provider ‘virtualbox’!
        ihoneymon:temp ihoneymon$ vagrant box list
        lucid32 (virtualbox)
        test    (virtualbox)
        ihoneymon:temp ihoneymon$


Chef

  • vagrant up 실행시 최초실행되는 매크로(간단하게 말하면, 스크립트를 조건에 맞춰서 자동실행하는 것이랄까?
  • 운영체제에 종속적인 편이다.
    • 스터디 중에 능력자가 운영체제를 식별하여 실행환경에 맞는 명령을 수행하는 것이 하지 않을까 하는 이야기를 나누었지만, 그런 수고스러운 삽질을 하는 것을 권장하고 싶지는 않다. 운영체제에 맞춰서 작성하면 간결하고 깔끔하겠다는 개인적인 생각을 했다.
  • Chef Solo Provisioning
    • Chef Server 없이 미리 opscode-cookbooks organization 에서 설정하려고 하는 운영체제에 맞춰서 receipe를 내려받은 후 가상머신 실행 후 추가명령 실행을 지원하는 기능이다. 이걸 잘 설정해두면, 여러 개의 인스턴스를 만들어서 실행할 때, 서버의 업데이트 상태를 최신상태로 갱신하고 사용하는데 필요한 패키지를 설치하도록 만들 수 있다.


참고자료


  2013 Google I/O에서 Android Studio(http://developer.android.com/sdk/installing/studio.html#download)를 소개했습니다.

  이클립스에 적재하여 배포하던 Android IDE를 더이상 개선할 수 없는 한계에 다다랐다고 판단하는 순간, 잽싸게 새롭게 인기를 끌기 시작하고 있는 인텔리제이IntelliJ로 갈아탄 거죠. 아직 인텔리제이 환경에서 안드로이드 애플리케이션 개발을 한 경험은 없습니다. ㅡ_-); 안드로이드 앱 개발을 안한지 어느정도 시간이 지나고 나니 하나도 모르겠습니다. Orz... 

  이번  2013 Google I/O extends Gangnam 행사에서도 안드로이드 앱을 가이드라인에 맞춰서 개선하는 과제가 주어졌지만, 걍 손을 놓고 키노트만 열심히 봤습니다. ^^;;


[New Project...]를 누르면 바로 안드로이드 프로젝트를 생성합니다.





첫 실행화면은 좀 밋밋합니다. 그래서 Colors & Fonts를 기본적제된 Darcula로 변경했습니다. 

기본 앱을 실행시켰습니다. Android Device Manager를 이용해서 에뮬레이터를 하나 만들고 실행시켰습니다.

기본 프로젝트로 실행한 앱화면!

다른 무엇보다 관심이 가는 것은 build.gradle  입니다. 얼마 전까지 메이븐으로 빌드할 수 있다고 이야기하는 걸 들었는데, 어느새 gradle로 처리를 해두었네요. @_@)

결국 gradle도 익혀야만 하는 운명을 타고나게 된 듯 합니다. 

흐트러졌던 마음을 다잡고 안드로이드 앱 만들기 공부를 다시 시작해야겠습니다.

우선은 가이드라인 탐독부터... 응?

+ Recent posts