MacOS 환경에서 진행하였습니다.

이전 글들에서 ubuntu 환경에서 svn을 설치하는 방법과 이클립스와의 연동을 설명하였습니다. 이제는 svn 사용 방법 혹은 전략 설명입니다.

진행하기 앞서 용어 설명을 하자면,

1)trunk : 기둥이 되는 저장소(폴더)입니다. 즉, 나무로 따지자면 기둥이 되는 것입니다. 이것을 형상관리로 얘기하자면 첫 소스를 svn에 import할때, trunk에 업로드합니다. 그 이후에 나무의 기둥이되는 trunk에서 가지를 뽑아 수정을 하게되는 것이 braches라는 개념(하나의 프로젝트에서 수정되는 부분만 뽑는 것이 branche)입니다. branches들을 수정하였다면 이 수정된 소스를 merge하는 저장소가 trunk입니다. 모든 수정이 commit되면 최종이 되는 녀석이 trunk라는 기둥(저장소)이 되는 것입니다.

2)branches : trunk에서 수정이 되는 부분을 뽑아 내는 것이 branches입니다. 나무로 비유하면 가지가 되는 녀석입니다. trunk에서 branches들을 뽑아내어 수정을 완료하면 다시 trunk에 merge를 하게됩니다. 즉, trunk는 저장소에서 하나이지만 branches는 여러개가 될수 있습니다.(여러사람이 각자의 맡은 부분을 가지로 떼어내어 수정을 하기에)

3)tags : 쉽게 제품과 비교하면 맥북이 15년도 제품을 릴리즈하고, 그 다음 16년 제품을 릴리즈, 17년, 18년 제품들을 꾸준히 릴리즈합니다. 이 릴리즈되는 버전들을 하위버전에서 완전히 벗어나는 녀석들이 아닌 수정 및 보완, 혹은 기능추가 정도이겠죠. 즉, tags들이란 버전별로 릴리즈 할때 마다 하나씩 생기는 겁니다. 각 tag들은 branches를 가지지 않습니다. 즉 수정되는 애가 아니라는 뜻입니다. 왜 릴리즈하는 애들을 저장하냐? 만약 17년 버전 이후에 18년 버전이 나왔는데, 18년 버전들이 전량 다 불량이라면? 우선은 아무런 사용에 문제가 없는 17년 버전을 다시 내놓겠죠?(조금 억지...) 이런 개념입니다. 새로운 소프트웨어를 릴리즈했지만 버그 및 오류가 너무 심할 경우 이전버전을 다시 배포하여 우선 운영할 수 있는 환경을 갖을 수 있게 되는 겁니다.

<trunk, branches, tags 생성 방법>

생성과정은 svn이 올라가 있는 서버에서 직접생성한다는 가정입니다.

Solr&Zookeeper(솔라&주키퍼) cloud 환경 구성

Mac OS 환경에서 작성되었습니다.

solr와 zookeeper를 연동하여 cloud 환경구성하기 입니다.

우선 진행하기 전에 수정 혹은 생성 되어야할 설정 목록입니다.

1)solr.xml : solr cloud를 이루는 solr instance에 관한 설정파일입니다.

2)zoo.cfg : zookeeper 관련 설정파일입니다.

3)collection config file : solr collection들이 가지게 될 schema.xml,solrConfig.xml 등의 파일이 들어가는 config file입니다. 이 파일은 zookeeper에 upconfig하여 모든 solr                                         instance들이 공유하게 됩니다.

4)zooServer Dir : zookeeper들은 파일로써 data snapshot을 저장합니다. 그러한 snapshot파일과 zookeeper 식별 파일들이 들어가는 디렉토리입니다.

<solr.xml>

solr의 폴더의 위치를 편하게 $SOLR_HOME이라고 표현합니다.

$SOLR_HOME/server/solr

$SOLR_HOME/server/solr2

$SOLR_HOME/server/solr3

이렇게 3개의 폴더를 생성해줍니다.(solr는 원래 존재하는 폴더) 그리고 solr folder 밑에 solr.xml파일을 복사하여 solr2/solr3 folder 밑에 복사해줍니다.

총 3개의 solr.xml이 각각의 solr,solr2,solr3 폴더에 위치하게 됩니다. 보시는 것과 같이 service port 만 달라지게 됩니다. 이렇게 solr instance가 3개가 뜨게 되며, 각각 8983,8984,8985 port로 요청을 받게 됩니다. 여기서 인스턴스를 홀수개로 띄우는 이유는 리더선출에 관련되어 있습니다. 반드시 클라우드 환경에서는 홀수개의 인스턴스를 띄워줘야 합니다.

그리고 $SOLR_HOME에 적절한 위치에 zookeeper에 upconfig할 config file folder를 위치시켜줍니다. 본인은 server folder와 같은 위치에 solr-config 라는 folder로 만듬. 그리고 이 solr-config 밑에는 conf라는 폴더가 위치해야하고 conf라는 폴더 밑에 upconfig를 위한 설정파일들이 위치해야함.

<zoo.cfg>

zookeeper가 위치한 폴더경로를 편하게 $ZK_HOME이라고 표현하겠습니다.

$ZK_HOME/conf 밑에 총 3개의 zoo.cfg,zoo2.cfg,zoo3.cfg 파일들을 생성해줍니다. 여기서 dataDir는 zookeeper의 식별자파일 및 data snapshot들이 저장되는 경로입니다. 3개의 zookeeper 인스턴스는 각각의 zoo.cfg를 갖습니다.(zookeeper도 동일한 이유로 홀수개의 인스턴스를 띄움). clientPort는 말그대로 zookeeper가 사용할 포트입니다. 그 밑에 server.1=~는 총개의 zookeeper의 인스턴스를 뜻하며 2개의 포트는 zookeeper들끼리 통신할 포트와 리더선출을 위한 포트로 사용됩니다.

<dataDir>

zoo.cfg에 작성한 dataDir와 동일한 위치에 디렉토리 구조를 잡아줍니다. 그리고 그 디렉토리 밑에 확장자가 없는 myid파일들을 각각 만들어줍니다.(~$vi myid) 그리고 각 내용은 상위 폴더와 같이 1/myid는 1이라는 숫자하나 2/myid는 2라는 숫자하나 3/myid는 3이라는 숫자하나만 넣어줍니다.(version-2 폴더는 필자가 cloud환경을 운영하다 생긴 폴더입니다. zookeeper의 data snapshot 파일등이 들어가있습니다. 별도로 생성할 필요 x)

여기까지 모두 세팅이 완료되었습니다.

zookeeper 실행

bin/zkServer.sh start conf/zoo.cfg

bin/zkServer.sh start conf/zoo2.cfg

bin/zkServer.sh start conf/zoo3.cfg 

zookeeper 종료

bin/zkServer.sh stop conf/zoo.cfg

bin/zkServer.sh stop conf/zoo2.cfg

bin/zkServer.sh stop conf/zoo3.cfg

solr 실행

bin/solr start -c -s server/solr -p 8983 -z localhost:2181,localhost:2182,localhost:2183 -noprompt

bin/solr start -c -s server/solr2 -p 8984 -z localhost:2181,localhost:2182,localhost:2183 -noprompt

bin/solr start -c -s server/solr3 -p 8985 -z localhost:2181,localhost:2182,localhost:2183 -noprompt

tomcat WAS에 spring(spring boot) 여러개의 war파일 배포(여러개 context)

Mac OS 기준에서 작성되었습니다.(tomcat이 설치되었다는 가정)

하나의 웹사이트가 여러개의 war파일로 되어있고, 그러한 war파일들의 통신으로 이루어지는 웹사이트일 경우의 was 배포입니다.(각 war의 was 포트를 다르게 가져갈 경우)

만약 배포할 프로젝트가 spring boot project라면 pom.xml에서 embbed was를 사용하지 않는 설정을 넣어주어야합니다.

<dependency>

            <groupId>org.springframework.boot</groupId>

            <artifactId>spring-boot-starter-web</artifactId>

            <exclusions>

                <exclusion>

                    <groupId>org.springframework.boot</groupId>

                    <artifactId>spring-boot-starter-tomcat</artifactId>

                </exclusion>

            </exclusions>

        </dependency>

        <dependency>

            <groupId>org.springframework.boot</groupId>

            <artifactId>spring-boot-starter-tomcat</artifactId>

            <scope>provided</scope>

        </dependency>

->임베디드 WAS를 사용하지 않는다.

tomcat이 깔린 디렉토리에 가면 webapps라는 폴더가 있습니다. 그 폴더 밑에 배포할 war 파일들을 넣어줍니다. 그리고 tomcat 디렉토리에 conf 폴더에 server.xml을 수정해줍니다.

<Service name="Catalina">

  <Connector port="8038” protocol="HTTP/1.1" 

   maxThreads="150" connectionTimeout="20000" 

   redirectPort="8443" />

  <Connector port="8009" protocol="AJP/1.3" redirectPort="8443" />

  <Engine name="Catalina" defaultHost="localhost">
   <Realm className="org.apache.catalina.realm.UserDatabaseRealm"
    resourceName="UserDatabase"/>

   <Host name="localhost"  appBase="webapps"
    unpackWARs="true" autoDeploy="true"
    xmlValidation="false" xmlNamespaceAware="false">

   <Context path=“/context1” docBase=“ contextName1” />
   </Host>

  </Engine>
 </Service>

<Service name="Catalina2">

  <Connector port=“8028” protocol="HTTP/1.1" 

     maxThreads="150" connectionTimeout="20000" 

     redirectPort="8443" />

  <Connector port="8009" protocol="AJP/1.3" redirectPort="8443" />

  <Engine name="Catalina" defaultHost="localhost">

   <Realm className="org.apache.catalina.realm.UserDatabaseRealm"

     resourceName="UserDatabase"/>

   <Host name="localhost"  appBase=“webapps”

    unpackWARs="true" autoDeploy="true"

    xmlValidation="false" xmlNamespaceAware="false">

   <Context path=“/context2” docBase=“contextName2” />

   </Host>

  </Engine>

 </Service>

<Service name="Catalina3”>

  <Connector port=“8018” protocol="HTTP/1.1" 

     maxThreads="150" connectionTimeout="20000" 

     redirectPort="8443" />

  <Connector port="8009" protocol="AJP/1.3" redirectPort="8443" />

  <Engine name="Catalina" defaultHost="localhost">

   <Realm className="org.apache.catalina.realm.UserDatabaseRealm"

     resourceName="UserDatabase"/>

   <Host name="localhost"  appBase=“webapps”

    unpackWARs="true" autoDeploy="true"

    xmlValidation="false" xmlNamespaceAware="false">

   <Context path=“/context3” docBase=“ contextName3” />

   </Host>

  </Engine>

 </Service>

이렇게 서비스를 3개를 등록해주고 각 서비스마다 WAS가 넘겨주는 포트를 다르게줍니다. 이러면 하나의 WAS에 서비스가 3개가 올라가게 됩니다.

그리고 tomcat의 bin 폴더의 ./startUp.sh를 실행하면 war파일이 풀리면서 was에 배포가 되게 됩니다. 만약 하나의 war를 배포한다면? 해당 프로젝트의 서비스를 하나만 등록하면 됩니다.

mac os x 에서 진행하였습니다.

*이클립스에서 help>Eclipse Marketplace 에서 svn을 검색하여 "subversive"를 install 해줍니다.

*설치가 끝난 후에 restart된 후에 Marketplace 같은 창이 떠서 svn kit을 설치하라는 창이 뜬다면 kit을 받아주고

만약 그러한 창이 뜨지 않는다면 preference>Team>SVN 에서 SVN Connector tab을 눌러줘서 설치를 해줍니다(select 창 밑에 Get ..어쩌고 떴던 기억이)

설치가 된후에 Open perspective(우측상단) 에서 svn 창을 하나 열어줍니다.

그리고 SVN Repository view 에서 새로운 connection을 생성해줍니다.

*url-> svn://server_ip를 입력한 후에 등록한 사용자 아이디와 패스워드를 입력한 후에 엔터를 탁 쳐줍니다.

이경우는 웹서버에 따로 올리지 않았을 경우. (svn protocol을 사용)

*그런데 만약 커넥션이 되지 않는다면 몇가지 경우가 있는데, 

*1) kit이 제대로 받아지지 않은 경우(필자는 여기서 애먹음) 

*2) url이 틀려서 location 에러가 뜬경우(여기서도 많이 애먹음 다른 블로그에서는 svn://server_id/projectName(사용자지정)이었는데 필자는 /projectName을 빼고 넣으니 됬음. 아마 필자가 놓치고 있는 부분이 있는듯함) 

*3)사용자 계정정보가 틀린경우

*1)번 같은 경우는 수동으로 설치하는 방법이 있습니다.

*help>new install software 에 work with tab에 밑의 url을 넣고 plug-in을 수동으로 받아줍니다.

*http://community.polarion.com/projects/subversive/download/eclipse/6.0/update-site/

기타 사용법은 추후에 업로드하도록 하겠습니다...:)

aws ec2(ubuntu) 기준으로 진행하였습니다.

~$ svn

The program 'svn' is currently not installed. You can install it by typing: sudo apt-get install subversion

->설치가 되지 않은 것입니다. 설치를 해줍니다.

~$ sudo apt-get install subversion

->설치 후 잘 설치가 되었는지 버전을 확인해봅니다.

~$svn --version

->만약 문제 없이 버전이 잘나온다면 설치가 잘된 것이겠죠.

~$mkdir svn

->폴더를 하나 만들어줍니다.(원하는 위치에 하시면 되지만 저는 일단 $HOME에 생성했습니다.)

~$cd svn

~svn$svnadmin create --fs-type fsfs repos

->저장소를 생성해줍니다.

~$cd repos/conf

~$vi svnserve.conf

anon-access = none =>익명사용자 사용불가

auth-access = write =>인증사용자 읽기/쓰기

password-db = passwd =>아이디/패스워드가 담길 파일

authz-db = authz 

->요놈들을 바꿀것은 바꾸고 주석을 풀어줍니다.

~$vi passwd

[users]

yeoseong = 1234 =>아이디/패스워드를 저장해줍니다.

~$vi authz

[groups]

team = yeoseong

[/]

*=r

@team=rw

[repository:/]

@rnbchatbot=rw

->team이라는 그룹에 권한을 넣어주는 설정(나중에 사용자가 여러명이라면 "," 으로 사용자를 추가한다 ex. team=yeoseong,kiseok,wonhyeok)

~$cd /etc/init.d

~/etc/init.d/$vi svnserve

#! /bin/sh
### BEGIN INIT INFO
# Provides:          svnserve
# Required-Start:    $local_fs $syslog $remote_fs
# Required-Stop:     $local_fs $syslog $remote_fs
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: Start svnserve
### END INIT INFO

# Author: Michal Wojciechowski <odyniec@odyniec.net>

PATH=/sbin:/usr/sbin:/bin:/usr/bin
DESC="svnserve"
NAME=svnserve
DAEMON=/usr/bin/$NAME
DAEMON_ARGS="-d -r /home/svn/repos"
PIDFILE=/var/run/$NAME.pid
SCRIPTNAME=/etc/init.d/$NAME

[ -x "$DAEMON" ] || exit 0

[ -r /etc/default/$NAME ] && . /etc/default/$NAME

. /lib/init/vars.sh

. /lib/lsb/init-functions

do_start()
{
    start-stop-daemon --start --quiet --pidfile $PIDFILE --exec $DAEMON --test > /dev/null \
        || return 1
    start-stop-daemon --start --quiet --pidfile $PIDFILE --exec $DAEMON -- \
        $DAEMON_ARGS \
        || return 2
}

do_stop()
{
    start-stop-daemon --stop --quiet --retry=TERM/30/KILL/5 --pidfile $PIDFILE --name $NAME
    RETVAL="$?"
    [ "$RETVAL" = 2 ] && return 2
    start-stop-daemon --stop --quiet --oknodo --retry=0/30/KILL/5 --exec $DAEMON
    [ "$?" = 2 ] && return 2
    rm -f $PIDFILE
    return "$RETVAL"
}

case "$1" in
  start)
    [ "$VERBOSE" != no ] && log_daemon_msg "Starting $DESC" "$NAME"
    do_start
    case "$?" in
        0|1) [ "$VERBOSE" != no ] && log_end_msg 0 ;;
        2) [ "$VERBOSE" != no ] && log_end_msg 1 ;;
    esac
    ;;
  stop)
    [ "$VERBOSE" != no ] && log_daemon_msg "Stopping $DESC" "$NAME"
    do_stop
    case "$?" in
        0|1) [ "$VERBOSE" != no ] && log_end_msg 0 ;;
        2) [ "$VERBOSE" != no ] && log_end_msg 1 ;;
    esac
    ;;
  restart|force-reload)
    log_daemon_msg "Restarting $DESC" "$NAME"
    do_stop
    case "$?" in
      0|1)
        do_start
        case "$?" in
            0) log_end_msg 0 ;;
            1) log_end_msg 1 ;; # Old process is still running
            *) log_end_msg 1 ;; # Failed to start
        esac
        ;;
      *)
        # Failed to stop
        log_end_msg 1
        ;;
    esac
    ;;
  *)
    echo "Usage: $SCRIPTNAME {start|stop|restart|force-reload}" >&2
    exit 3
    ;;
esac

exit 0

svnserve 를 서비스로 등록시켜주기 위해 이 파일을 작성해줍니다.(부팅시에 해당 서비스가 자동으로 시작됨. 관리자가 수동으로 실행시켜줄 필요없음)

위에서 

DAEMON_ARGS="-d -r /home/svn/repos"

이부분만 자신의 환경에 맞게 작성해주면 됩니다.

~$sudo chmod 755 /etc/init.d/svnserve

~$sudo update-rc.d svnserve defaults =>서비스로 등록해줍니다.

# service svnserve start
# service svnserve stop
# service svnserve restart

svn://server_ip/reposName 으로 접속해주면 됩니다.

svnserve -d -r /home/ubuntu/svn/repos/

mac os 기준입니다.

우선 아마존에 접속하여 회원가입을 한 후에 인스턴스 하나를 생성해줍니다.(이 과정에서 다운받은 key file을 원하는 위치에 저장해줍니다.)

우선 키 파일을 이용하여 ssh 접속을 하기위해서는 파일 권한을 400으로 설정해주어야 합니다.

$chmod 400 "key파일이 저장된 디렉토리"/key.pem

이렇게 권한을 변경해준 후에야 키파일을 사용할 수 있습니다. 만약 권한을 변경해주지 않고 사용하게 되면 어떠한 메시지가 콘솔에 떠서 접근할 수 없게 됩니다.

이렇게 권한을 설정해준 이후에 ssh 접속 명령을 쳐줍니다.

$ssh -i "keyfile저장디렉토리"/key.pem ubuntu@"ec2 접근 ip" 

작업을 모두 끝마친 후 접속을 종료하려면 "exit" 명령만 쳐주면 됩니다.

출처:https://www.slideshare.net/arawnkr/spring-camp-2013-java-configuration

1.StaticApplicationContext

-코드를 통해 빈 메티정보를 등록하기 위해 사용한다. 거의 사용되지 않는 구현체이다.

2.GenericApplicationContext

-실전에서 사용할 수 있을 정도로 왠만한 컨테이너기능을 다 가진 녀석이다. 빈 설정을 불러오기 위해 reader를 이용해야 한다.

-코드 레벨에서 직접이용하는 경우는 드물지만 우리는 테스트를 위한 프레임워크인 JUnit을 사용할 때 종종 사용하곤 한다.

=>자동 빈 주입되는 ApplicationContext의 구현체가 GenericApplicationContext 녀석이다.

3.GenericXmlApplicationContext

-GenericApplicationContext는 reader까지 생성해서 설정파일을 읽어오는 코드까지 사용자가 직접 작성해야 한다. 그래서 나온 녀석이 이녀석이다.

-이 구현체에는 reader까지 포함된 녀석이다. xml을 이용하는 루트 컨텍스트를 만들 때만 사용할 수 있게 만든 편리한 클래스이다. 세밀한 컨텍스트 설정을 위해서는 GenericApplicationContext를 이용해야한다.

4.WebApplicationContext

-ApplicationContext를 확장한 인터페이스이다. 즉, 이 인터페이스를 구현한 클래스를 사용하게 되는 것이다. 이름 그대로 웹 환경에서 사용할 때 필요한 기능이 추가된 애플리케이션 컨텍스트이다.

-XmlWebApplicationContext, AnnotationConfigWebApplication 등을 사용하며, 디폴트는 XmlWebApplicationContext이다.

스프링의 IOC가 적용된 애플리케이션을 작동시키는 방법은 반드시 초기화된 ApplicationContext의 메소드를 호출함으로써 기동되는 것이다. 위의 예제들에서 getBean이라는 메소드를 호출함으로써 기능들이 시작되듯이 말이다. 하지만 WebApplicationContext 처럼 웹환경에서 애플리케이션을 작동시키는 방법은 조금다르다. 웹환경에서는 main()를 호출하기 쉽지 않기다. 이러한 역할을 하는 녀석이 스프링에서 제공하는 DispatcherServlet이라는 녀석이다.

디스패처서블릿은 미리 초기화된 ApplicationContext에 대한 빈정보를 하나 가져온다. 그리고 클라이언트의 요청이 있을 때, 미리 받아온 빈정보를 이용하여 메소드를 호출하고, 그러므로써 애플리케이션이 실행되는 것이다.