블로그 이미지
평범하게 살고 싶은 월급쟁이 기술적인 토론 환영합니다.같이 이야기 하고 싶으시면 부담 말고 연락주세요:이메일-bwcho75골뱅이지메일 닷컴. 조대협


Archive»


 

'Integration'에 해당되는 글 2

  1. 2018.03.01 gitHub와 Jenkins 연결하기
  2. 2009.07.29 EAI관점에서 본 SOA (6)
 

Jenkins와 gitHub 연동


조대협 (http://bcho.tistory.com)


가장 널리 사용하는 Jenkins와, 소스 코드 리포지토리 서비스인 GitHub를 연동하는 방법에 대해서 알아본다. 시나리오는 gitHub에 코드를 푸쉬하면 Jenkins가 이를 인지해서 자동으로 코드를 내려 받아서 빌드 스크립트를 실행하는 순서로 한다.


GitHub에서 Credential 생성


gitHub 자신의 계정으로 로그인 한 후 우측 상단의 자신의 사진이 있는 아이콘을 누르면 메뉴가 나오는데, 여기서 Setting > Developer settings 메뉴로 들어간 후에 아래와 같이 Personal access tokens 메뉴로 들어간다.

다음 우측 상단의 Generate new token 메뉴를 선택한다.



다음 토큰으로, 접근할 수 있는 범위를 설정한다. 접근 범위는 “repo”와 “admin:repo_hook” 을 선택한다.




선택이 끝나고 토큰을 생성하면 문자열로 된 토큰이 생성된다.


Jenkins에서 GitHub 연결 설정

앞에서 생성된 토큰을 Jenkin의 GitHub 연결 부분에 설정하도록 하겠다.

Jenkins 초기화면에서 Jenkins > Manage Jenkins > Configure System 메뉴로 들어가면 GitHub 계정을 설정하는 부분이 있다.



Name은 이 GitHub 연결 설정을 구별할 이름으로 정의하고 API URL은 default로 https://api.github.com 으로 설정되어 있는데 default 값을 사용한다.

다음 접속 credential을 설정해야 하는데, credentials 부분에서 Add 버튼을 눌러서 Credential 설정 메뉴를 실행한다.




위와 같은 메뉴가 나오면 Kind는 “Secret text”를 선택하고 Secret 에 앞에 gitHub에서 생성한 키를 입력한다. ID에는 본인 gitHub ID를 입력한다.  Credential 입력이 끝나면,  아래 그림과 같이 Credentials 메뉴 아래에 Test Connection 버튼이 있는데, 이 버튼을 눌러서 제대로 github와 연결이 되는지를 테스트 한다.




Jenkins 프로젝트 생성 및 설정

Jenkins와 gitHub 연결 설정이 끝났으면, Jenkins에서 프로젝트를 생성한다.

Git 연결 설정

프로젝트 설정에서 아래와 같이 Git 메뉴로 이동한다.



여기서 Repository URL을 입력한다. Repository URL은 본인 gitHub Repository에서 우측 상단의 녹색 “Clone or download” 버튼을 누르면 HTTPS 로 된 URL이 나온다. 이 URL을 입력하면 된다.



다음 이 repository에 연결할 연결 정보를 입력해야 하는데, Jenkins에서 credentials 메뉴로 들어간다.

이 메뉴에서 Kind를 “Username with password” 를 선택하고 Username에는 본인의 github id, Password에는 github 비밀번호를 입력한다.



빌드 트리거 설정

다음 어떤 조건에서 Jenkins 빌드를 실행할지를 설정하는데, GitHub에 코드가 푸쉬되면 빌드를 트리거링 하도록 설정을 할것이다. 아래 그림과 같이 Build Triggers 메뉴에서 GitHub hook trigger for GitScm Polling을 선택한다.




이렇게 설정하면 GitHub에서 코드 푸쉬가 될때 webHook 메세지를 Jenkins에 보내주는데, 이 WebHook 메세지를 받을 때마다 빌드를 하게 된다.


GitHub에서 WebHook 설정

Jenkins 가 GitHub 에서 보내는 WebHook에 의해서 Triggering이 되도록 설정했으면, 이제 GitHub에서 코드가 푸쉬 될때 마다 WebHook을 Jenkins에 보내도록 설정해야 한다.




GitHub Repository로 들어가면 우측 상단에 Settings라는 메뉴가 있다.

이 메뉴에 들어가서 좌즉에 Integration & Service 라는 메뉴를 선택한다.


Services 메뉴에서 “Add service” 버튼을 클릭한 후에 “Jenkins (GitHub plugin)” 을 선택한다.



다음 플러그인 설정에 Jenkins hook url에 Jenkins가 WebHook을 받을 HTTP 경로를 입력한다.

일반적으로 http://{Jenkins server의 URL}/github-webhook 이 된다.




이제 모든 설정이 끝났다.

제대로 작동하는 것을 확인하기 위해서 코드를 commit 한 후에 Push를 해보면 빌드가 자동으로 진행이 된다.

Jenkins의 해당 project에서 좌측의 “GitHub Hook Log”를 보면 WebHook을 잘 받았는지 확인이 가능하다. 아래는 실제로 WebHook이 발생한 내용을 확인한 화면이다.




본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요

EAI관점에서 본 SOA

아키텍쳐 /SOA | 2009.07.29 23:16 | Posted by 조대협

EAI관점에서 본 SOA

 

2009-07-29

Oracle Korea/Principal Consultant

Byungwook.Cho (byungwook.cho 골뱅이 oracle.com)

 

SOA(Service Oriented Architecture) 에 대한 접근 방법은 BPM을 이용한 비즈니스의 민첩성 확보나 비즈니스의 서비스화를 통한 재 사용성등에 초점이 맞추어져왔다.

 BPM을 통한 민첩성 확보등은 실제 비즈니스에서 그만큼 변화가 다양한 업무 요건을 필요로하고 BPM으로 구현할 만큼 긴 프로세스가 정리되어 구현될 프로세스가 많지 않다. [ 사실 BPM으로 전체 프로세스를 시스템화 한다는 것은 상당히 힘든일이다. 그만큼 변화나 융통성이 많이 필요하기 때문인데, “일례로 XX과장님 무슨 업무 처리 부탁드립니다.” 와 같은 이메일이나 업무 협조 요청등을 통해서 일어나는 정형화되지 않은 프로세스도 있기 때문에 업무 절차에 대한 정리가 선행되야 BPM 도입시 효과를 볼 수 있다. ]

또한 재사용에 대한 문제 역시, 소프트웨어 공학론에서 수십년 전에서부터 언급되어 온 만큼 쉬운일이 아니다. 인터페이스를 통일하고 비즈니스 단위로 서비스를 만들어서 재사용을 하려면 상당히 고도화된 수준의 디자인 노하우가 필요하다.

그렇다면 SOA를 도입하는 데 있어서 다른 장점은 없을까? 그 중 하나가 통일된 인터페이스를 이용한 애플리케이션간의 통합을 SOA를 통해서 구축할 수 있다.

 

EAI (Enterprise Application Integration)

먼저 전통적인 애플리케이션간의 통합 방식인 EAI에 대해서 살펴보도록 하자.

1990년대에 인터넷의 활성화와 비즈니스의 IT 시스템의 도입이 가속화되면서 기업의 업무들은 급속하게 IT 시스템으로 구축되었다. ERP,CRP,PLM 등등 업무 부서별로 또는 비즈니스 영역별로 시스템들이 구축되었다.

 구축이 완료되고 시스템이 운영되기 시작하면서 문제가 발생되기 시작했다. 업무 시스템들이 서로 분리가 되어 있고, 업무에 대한 데이터가 서로 다른 시스템에 분리되서 관리되었던 것이다.

 물류 와 구매시스템에서 발생한 회사의 수입과 지출 내역이 회사의 회계 시스템과 분리되서 관리되었고 이로 인해서 각 시스템간의 데이터를 맞추는 작업이 수작업이나 또는 기타 원시적인 방법으로 진행되었다. 그러한 과정에서 실수도 발생을 하고 효율과 경영 여건에 대한 민첩성도 떨어지게 되었다.

업무간의 연계를 위해서 각각의 업무시스템을 P2P 형식으로 연결하기 시작했지만, 방대한 데이터에 대한 안정성,성능 그리고 모니터링등 여러가지 문제가 발생하였고, 이러한 애플리케이션간의 연동만을 전문으로 하는 아키텍쳐와 솔루션이 필요하게 되었는데 그것이 바로 EAI이다.

분리된 각각의 IT 시스템을 연결할 수 있는 인프라를 제공함으로써 전체 IT 시스템들의 유기적인 결합을 가능하게 하는 개념이다.

 

EAI의 통합상 문제점

그런데 이러한 전통적인 방식의 EAI는 통합 방식에 있어서 몇가지 문제를 가지고 있다.

그 중 하나가 통합 인터페이스의 문제이다. 통합하고자 하는 애플리케이션의 인터페이스를 이용하기 때문에, 통합이 발생할 때 마다 별도의 통합 프로그램을 구축해야 한다.


예를 들어 3개의 시스템을 서로 통합하고자 할 때, 각 업무 시스템별로 하나의 인터페이스만을 가지고 통합한다고 해도, 시스템의 인터페이스 방식이 틀리기 때문에 총 3개의 연결이 필요하다. 업무가 4개로 늘어나면 6개의 형태의 인터페이스 타입이 5개로 늘어나면 10개로 업무 시스템의 개수가 늘어나고 통합하고자 하는 기능의 수가 늘어날수록 통합 프로그램의 수는 급격하게 증가하게 된다.

 이는 통합 프로그램의 구현에 드는 자원과 이에 따른 관리 문제를 만들게 되고 특히 업무시스템 담당 부서간의 커뮤니케이션에 드는 노력을 급격하게 증가 시킨다.

 EAI 프로젝트의 경우 통합 하고자 하는 양쪽의 시스템의 현업 담당자들이 서로 인터페이스를 협의하고 메시지 타입을 협의하고, 연동할 인터페이스를 구현해야 하며 이에 대한 테스트를 수행해야 한다. 이 과정은 송신 시스템,EAI 시스템,수신 시스템 3개의 업무 부서가 관여하기 때문에, 커뮤니케이션에 소요되는 시간과 비용이 통상적으로 예상할 수 있는 범위를 넘어선다.

 

또한 기존 시스템들이 교체 되었을 때, 교체된 시스템의 인터페이스를 전면 교체해야 하는 작업이 발생한다. 그리고 EAI 시스템은 별도의 시스템들을 Native 인터페이스를 이용해서 연결하는 것이기 때문에, 각 시스템에 대한 전문 지식과, 타 업무 부서와 일하기 위한 프로세스, 그리고 연동 프로그래밍에 대한 능력등을 갖춘 개발자가 필요하다. 즉 인력이 교체될 때 높은 Learning Curve 와 Education Cost가 필요하게 된다는 것이다.

 

 

이러한 EAI의 문제는 각 시스템간의 인터페이스가 통일되어 있지 않고 호환되지 않기 때문에 발생하게 되는 것이다.

 

SOA를 이용한 통합

 

그러면 전통적인 EAI가 가지고 있는 문제를 해결하자면 어떻게 해야할까? 앞에서도 언급했듯이 이런 문제는 인터페이스의 비호환성에서부터 발생한다. 즉 해결 방식은 인터페이스 방식을 통합하는 것이다.

 

웹서비스나 CORBA등의 통합된 인터페이스 방식을 이용해서 모든 시스템들이 통신하게 되면 시스템이 바뀌었을때도 동일한 형태의 인터페이스를 노출해주면 되고, 중간에서 연동을 하는 입장에서도 여러 플랫폼에 대한 기술을 이해할 필요없이 하나의 표준 인터페이스 기술을 사용하면 되기 때문에 인력 운용면이나 Learning Curve 면에서도 여러가지 장점을 가질 수 있게 된다.

 

SOA와 EAI의 융합

그러면 EAI 는 더 이상 쓸모가 없는 것 일까? EAI는 통합에 있어서 SOA와 다른 관점을 가지는 만큼 다른 장점 또한 제공한다.

 

Tightly Coupled 통합

EAI는 통합 대상이 되는 애플리케이션에 대한 Native 인터페이스를 이용하기 때문에, Tightly Coupled 된 통합이 가능하다. 이 말은 애플리케이션간의 분산 트렌젝션과 같은 저수준의 통합을 가능하게 해준다는 것이다.

 특히 여러 개의 애플리케이션을 묶어서 하나의 서비스 기능으로 도출하고자 할 때, EAI내의 work flow 기능들을 이용하여 대상 애플리케이션들을 composite 하고 이를 서비스 형태로 expose (노출) 시키면 애플리케이션간의 분산 트렌젝션이 연계된 형태의 서비스를 노출 시킬 수 있다.

 즉 SOA에서 EAI는 저 수준의 시스템간의 통합을 담당하고 이를 서비스로 노출 시키는 역할을 한다.

 이렇게 기존의 Legacy 시스템들을 표준화된 인터페이스로 expose 해주는 계층을 SOA에서는 Service Enablement Layer라고 하고, EAI는 그 중에서 단일 시스템에 대한 expose 보다 하나 이상의 Legacy를 통합하여 expose 하는 composite 기반의 Service Enablement 를 수행한다.

 

기존 업무 조직에 대한 기술적 차이에 대한 중계

SOA 프로젝트에서 문제점중의 하나가 기존의 기술 조직의 서비스 구축에 대한 기술적인 차이이다.

예를 들어 ‘A사의 ERP 솔루션을 이용해서 ERP를 구축한 회사가 있다고 하자. 이 회사는 SOA로 아키텍쳐를 전환하기로 결정했고, ERP 팀에 회사 표준 인터페이스 기반으로 서비스를 Expose 하도록 지시했다고 가정하자.

그런데 이 ERP 팀의 개발자들은 오직 ERP 시스템에서 사용된 언어만을 안다. 설사 웹서비스와 같은 기술이 제공되더라도 XML도 모르고, 웹서비스를 공부할만한 시간도 의지도 없다. 결국에는 재사용이 가능한 높은 수준의 서비스가 아니라 간신히 구현한 서비스가 나오거나 또는 업무팀의 반발로 데이터 베이스간의 연동으로 통합을 하게 되고, SOA에서 추구하고자 하는 원래의 목적은 허물어져 간다.’

이런 시나리오는 실제 SOA 프로젝트에서 발생하는 시나리오이다. 처음부터 전체 시스템을 다시 구축하는 회사면 모르겠지만 새로 세운 회사가 아닌 이상, Legacy 시스템은 존재한다. 또한 하나의 솔루션에 전문화되어 있는 현업 인력에게 웹서비스라는 새로운 기술을 들이 민다는 것도 쉬운일이 아니다.

 여기서 EAI가 사용될 수 있는데, 업무팀은 현재 사용하고 있는 솔루션의 기술을 이용하여 비즈니스 서비스를 구축하면 EAI에서 해당 솔루션에 대한 아답터를 이용하여 연결하고 웹서비스로 외부에 Expose 해주는 기능을 수행한다.

 EAI의 인터페이스 변환은 단순하게 프로토콜이나 사용기술의 변화뿐만 아니라 조직간의 기술 차이에 대한 중재 역할까지 수행하게 된다.

 

결과적으로 EAI를 SOA에 적용하면 Service Enablement Layer로써 다음과 같은 계층 구조를 가지게 된다.

 

결론

지금까지 간단하게나마 기업의 애플리케이션의 통합의 필요성과 EAI를 통한 통합 그리고 SOA에서 애플리케이션의 통합 방법에 대해서 알아보았다. Application Integration은 현재의 Enterprise Architecture에서 반드시 필요한 요구사항이다. EAI가 되었건, SOA가 되었건 어떤 방식이던지 통합이 필수적인 요건이다. 어떤 방식으로 구현하느냐는 해당 기업의 시스템의 아키텍쳐와 요구사항에 따라 틀릴 것이고 SOA를 이용한 통합 방식이 전통적인 EAI방식보다 몇몇 장점이 있다는 것을 살펴보았다.

 

사실 본 문서에서 언급한 인터페이스 통일을 통한 시스템의 통합 방식은 SOA의 발전 모델중의 첫번째 모델인 통합 중심의 Fundamental SOA에 해당한다. (참고 : http://www.slideshare.net/Byungwook/soa-overview )

 

그러나 SOA가 반드시 모든 통합에 적합한 것은 아니다. EAI방식의 통합이 적절할때가 있고 SOA방식이 적절할때가 있기 때문에 SOA중심의 통합은 EAI 를 흡수하는 형태로 상호 보완적인 통합이 되어야 한다.

그리고 SOA의 목적 자체가 통합 하나만이 되서는 곤란하다. 여러 목적 중의 하나가 통합이고 그외에 서비스의 재사용, 시스템의 유연성과 민첩성등이 반영되어야 진정한 SOA 라고 이야기 할 수 있다.

 

 


본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요

  1. 놀새~ 2009.07.30 10:10  댓글주소  수정/삭제  댓글쓰기

    개인적인 생각으로 SOA 자체 통합에 대한 요건은 근간에 많이 나오고 있는 이야기지만 iWay같은 WebService 방식의 어댑터를 이용하여 서비스 버스 레벨로 접근할 수 있는 방법으로는 성능적인 제약사항을 극복할 수 없다는 단점이 늘 존재해오고 있었지요.

    SOA는 말그대로의 아키텍처일뿐 재사용 가능한 컴포넌트의 입장(SOA의 원어적 의미:가트너 1996)으로 EAI를 구현해도 결국 나타난 결과물은 SOA가 될 수가 있다고 생각해요. 그래서 외국의 SOA 관련 리포트와 국내 소프트웨어 진흥원의 리포트를 봐도 SOA 프로젝트의 범주에 컴포넌트화된 EAI 솔루션을 이용한 프로젝트를 포함시키고 있는 실정이구요.

    "Dancing Around EAI 'Bear Traps'"이라는 보고서를 보게 되면 전세계 EAI 프로젝트의 70%가 실패한 것으로 나오네요. SOA를 하던 EAI를 하던 가장 고질적인 문제는 부서간 협업이 안되는 것, 전문가의 부재, 많은 부서 참여로 인한 요구 사항 중첩, 경쟁 체제 부서간의 시스템 폐쇄 등이 가장 큰 요인이라고 보고하고 있어요.


    아시다시피 벤더 SOA의 근원적 태생은 각 벤더의 EAI 솔루션이라는 걸 대부분의 사람들도 알고 있을 겁니다. 근본적인 문제는 쉽게 해결되지 않는 게 일반적이지요. ERP, SCM, CRM 등의 프로세스들이 이제서야 활성화되었는 데 사실 정착시키는데 40년이란 세월이 소요되었습니다. 이제 18살 먹은 EAI와 개념만 14살 먹은 SOA가 정착되려면 철들 나이가 되어야 하지 않을까 하네요.

    언제부턴가 신문에서 SOA이야기(벤더가 이야기하는 것 빼놓고..)가 슬슬 사라지고 있는 것도 실상을 이야기하는 반증이 아닐까요?

    • 조대협 2009.07.30 11:46 신고  댓글주소  수정/삭제

      대부분 맞는 내용같아요. SOA는 아키텍쳐 개념으로써 우수할지 몰라도 실제 구현하기에는 EAI의 사례에서 봤듯이 "사람"과 "소통" 이 중요하져. 그걸 형상화 시킨것이 "거버넌스" 이긴 한데. 쉽지 않은 것은 사실이지요.

      느리긴 해도, 언젠가는 SOA 형태로 시스템들이 점점 통합되어 가지 않을까 싶습니다. 그만큼 기술들이 따라와 주겠지요.

      사실 개념은 참 좋아요. ;)

  2. 고맙습니다 2009.08.25 17:42  댓글주소  수정/삭제  댓글쓰기

    찾던 자료인데 잘 보고 가요
    펌 했답니다

  3. 역시.. 2010.07.27 15:44  댓글주소  수정/삭제  댓글쓰기

    조대협님의 글은 퐌타스틱합니다.ㅎㅎ
    대협님의 jvm tuning문서와 how to package ejb는 정말 몇 번이고 보고 또 보고했습니다. ㅋㅋ
    감사합니다.

  4. 순팔 2011.10.15 04:07  댓글주소  수정/삭제  댓글쓰기

    글 잘쓰시네요 많은 도움이 됩니다.~~퍼갈게요^^