'분류 전체보기'에 해당되는 글 48건

  1. 2019.04.04 [스파크(Spark)] #1. 개요
  2. 2019.04.04 아키텍처의 출발점
  3. 2019.03.22 Docker : Dockerfile 실습 편
  4. 2019.03.22 Core/Context 모델

[스파크(Spark)] #1. 개요

[스파크(Spark)] #2. 용어 및 개념

[스파크(Spark)] #3. 구조적 API 개요 및 기본 연산

 

빅데이터 처리 분야에서 아파치 스파크(Spark)가 빠르게 확장되고 거의 표준이 되어가고 있다. 

앞으로 대용량 데이터의 가공이나 실시간 처리 및 분석에 필요하다고 판단되어 알아보게 되었다. 

스파크 관련 책 및 공식 문서를 보고 진행하기로 한다. 

등장배경

이전에 CPU 등 하드웨어 성능은 해를 거듭할수록 수치적으로나 체감으로도 눈에 띄게 발전하였다. 보통 2년마다 데스크탑을 조립해서 바꿨을 정도였다. 하지만 2005년쯤부터는 물리적인 한계로 인하여 성능향상은 점점 둔화하게 된다. 이때부터 하드웨어 엔지니어들은 모든 코어가 같은 속도로 동작하는 병렬 CPU 코어를 추가하는 방향으로 선회하였다. 

반면 데이터를 저장하는 비용은 1년마다 약 절반씩 줄고 있고, 웹캠이나 센서 등등 데이터 수집하는 장비 비용도 점점 저렴해지고 있다. 결과적으로 데이터 수집 및 저장 비용은 극히 저렴해졌지만, 데이터를 처리해야 하는 양은 점점 거대화되어 간다.

전통적인 처리 방법으로는 처리가 늦어지고 점점 불가능해짐으로써 새로운 처리 엔진과 프로그래밍 모델이 필요했다. 

이런 문제를 해결하기 위하여 아파치 스파크가 탄생하게 되었다. 

아파치 스파크란?

여러가지 명칭이 있지만 통합 컴퓨팅 엔진으로 정리하면 될 듯 하다. 

  • 클러스터 환경에서 데이터를 병렬 처리하는 라이브러리 집합
  • 분산 클러스터 컴퓨팅 프레임웍
  • 대용량 데이터를 처리하는 인메모리 기반 고속 처리 엔진

철학

철학은 통합과 컴퓨팅 엔진으로 구분된다. 

통합

 

"빅데이터 애플리케이션 개발에 필요한 통합 플랫폼을 제공하자." 가 핵심 목표이다. 

데이터 읽기, SQL 처리, 스트림 처리, 머신러닝까지 다양한 작업을 같은 연산 엔진과 일관성 있는 API로 수행할 수 있도록 설계되었다. 

즉  "스파크 하나로 모든 처리를 마무리하자!" 이런 철학이 스파크의 큰 장점이다.

컴퓨팅 엔진

 

스파크는 영구 저장소 역활은 수행하지 않고 데이터를 연산하는 역활 수행한다. 

즉 "처리에만 집중하자!"

대신 클라우드 스토리지 및 파일시스템(HDFS), Key-Value Store(카산드라), 메시징 서비스(Kafka) 등 다양한 스토리지를 지원한다. 

 

역사

2009년 UC버클리 대학교에서 Spark : Cluster Computing with Working Sets 내용으로 연구가 시작되었고, 2010년 논문 발표로 알려진다. 

  • 2013년 스파크 1.0 발표, 아파치 프로젝트 선정
  • 2014년 스파크 2.0 발표, 아파치 최상위 프로젝트 선정
  • 2019년 스파크 2.3.3 released

1.0 과 2.0 사이에서는 연산처리 성능 개선과 DataSet과 DataFrame API 병합으로 인한 ETL이 주요 초점이었다.

라이브러리

오픈소스 기반이기 때문에 자체 라이브러리 포함 외부라이브러리 지원한다. 

아래 4종류의 자체 라이브러리를 가지고 있고, 자세한 부분은 차차 알아보도록 한다. 

  • Spark SQL
  • Spark Streaming
  • MLlib
  • GraphX 

지원언어

프로그래밍을 지원하는 언어는 Scala, Java, Python, R이다. 

익숙한 Java로 스파크 공부를 진행하려 했으나 코드가 다른 언어보다 길어 Python으로 진행하기로 한다. 

실행환경

실행할 수 있는 환경은 하나의 노드부터, 수천 대의 서버 클러스터까지 가능하다. 

스파크는 인 메모리 기반의 병렬 처리가 특기이므로 클러스터 환경에서 실행하는 것이 유리하다. 

 

아키텍처

 

스파크 아키텍처를 논리적으로 도식화 해보았다. 

  • Storage : 스파크가 연산을 실행해야 할 데이터 저장소 연결
  • Management : 클러스터 실행 환경 관리
  • Engine : RDD, DataFrame, DataSet에 연산을 명령하여 데이터를 처리하는 작업을 수행
  • Library : 스파크 자체 라이브러리
  • Programing : 지원언어

사례

넷플릭스 (Netflix), 야후 (Yahoo), 이베이 (eBay)와 같은 회사에서 8,000개 이상의 노드 클러스터에서 여러 페타바이트의 데이터를 종합적으로 처리하면서 대규모로 스파크를 사용하고 있다. 

마치며

스파크의 기본적인 개요에 대해서 알아보았다. 

다음에는 스파크가 기본 기능에 대해서 살펴본다. 

 

 

Posted by 사용자 피랑이
TAG Spark

댓글을 달아 주세요

변화경영연구소의 소장이셨던 고 구본형 선생의 유명한 책인 '익숙한 것과의 결별'에서는 다음과 같은 내용이 있다.



비전을 제대로 이해하기 위해서는 건축물을 연상하는 것이 가장 완벽한 동질성을 부여한다.

 

비전은 '미래의 설계도'라고 말하는 사람들이 많다.

그러나 나는 그 생각에 강하게 반대한다.

그것을 설계도라고 해석하는 데서부터 많은 오류가 발생한다는 것을 알고 있기 때문이다.

 

설계도는 전문가들을 위한 것이다.

보통 사람은 설계도를 보고 그 건물의 전체적 모습을 떠올릴 수 없다.

그것은 판독하기 어려운 수치와 기호일 뿐이다.

 

비전은 이해관계자 모두가 쉽게 그 모습을 머릿속에 떠올릴 수 있어야 하며,

그 모습의 아름다움 때문에 마음이 설레야 한다. 따라서 비전은 오히려 건물의 조감도와 흡사하다.

 

건물의 유려한 자태와 자재의 질감이 느껴져야 한다.

그리고 그 건물 속의 한 부분을 줌업시키면 그 속에 앞으로 자신이 거주하고 생활할 새로운 공간이 보인다.

 

이 건물이 만들어지면 이 아름다운 곳으로 이사올 것이다.

어둡고 추운 지금의 공간을 떠나 밝고 넓고 전망이 좋은 공간에서 생활하게 될 것이다. 



비전에 대해 설명하는 내용이지만, 문득 아키텍처의 출발점이 이와 같지 않을까 하는 생각이 든다.

 

IT 시스템을 위한 아키텍처의 1차적 목표 역시, 대형의 복잡한 시스템에 대한 합리적으로 이해가능한 청사진을 제공하는데 있다.

 

여기서 '이해가능한'의 대상은 시스템 구축에 참여하는 모든 이해관계자로 볼 수 있으며, 이 중 핵심 이해관계자는 바로 고객이 되므로 고객이 이해가능한 시스템의 청사진이어야 한다.

 

고객이 이해한다는 것은, 고객의 요구사항을 합리적으로 해결하는 청사진을 제공하는 것이며, 아키텍처 드라이버라는 용어로 불리우는 아키텍처 결정요인 중 비기능 요구사항에 해당하는 품질속성을 만족시키는 아키텍처가 훌륭한 아키텍처인 것이다.

 

품질속성이라는 것도 가용성/성능/보안/유지보수성과 같은 시스템적인 부분도 있지만, TimetoMarket/시스템수명/가격 등 비지니스적인 부분도 고려되어야 한다.

 

따라서 고객의 관점에서 비기능요구사항에 대한 만족스러운 청사진을 제공하는 것은 IT전문가들만 이해가능한 복잡한 설계도가 아닌 전체 조감도가 더 아키텍처에 근접한 것이 아닐까 한다.

 


다음 그림은 아파트 건축물의 조감도이다.

 

아파트는 주거공간이라는 가장 기본적인 기능적 요구사항 외에도 고객의 선택에 더욱 중요한 변수인 주변생활여건, 녹지공간, 전망, 해가 들어오는 방향, 역세권 등의 품질속성이 매우 중요한 축을 차지한다. 이런 요건은 전문 설계도 보다는 아래 그람과 같은 조감도가 더욱 많은 얘기를 해 준다.

 


물론 이해관계자 모두가 제시된 청사진을 기반으로 작업을 진행해야 하기에 설계자, 개발자, 유지보수자와 같은 IT전문가들이 아키텍처가 설계한 원칙을 준수하는데 동참시키기 위해서는 다양한 설계의 측면을 고려해야 한다. 그래서 아키텍처 뷰의 가이드로써 OMG의 4+1View, CMUSEI의 3View, 지멘스의 4View 같은 참조모델이 존재한다.

 

 


다음 그림은 아파트의 특정 가구에 대한 설계도이다.

이 설계도는 개별 세대의 방구조와 배치, 동선 등을 표현하는 좀더 세부적인 아키텍처에 해당한다. 또한 전문적인 기호와 수치는 또 다른 이해관계자(설계자, 시공업자 등)를 위해 제공되는 정보 상세한 설계 기준으로 사용된다.

 


현대 건축의 아버지라 불리우는, '르 코르뷔지에'는 다음과 같은 말을 했다고 한다.


 

우리는 돌, 나무, 시멘트를 사용하여 집을 짓고 건물을 만든다.

이것은 건축이다.

 

그런데 문득 그것이 내 마음을 사로잡고, 나를 감동시킨다.

그 순간 행복한 나는 이렇게 말한다.

 

"아~ 아름답군!". 아키텍처(Architecture)란 그런 것이다.

 

- 르 코르뷔지에, 19123 "Architecutre: From Prehistory to Post-Modernism"


 

IT 개발의 많은 요소들이 건축의 그것에서 차용되어왔다. IT 아키텍처 역시 건축물의 아키텍처 사상에 근원하고 있으며, 아키텍트라면 르 코르뷔지에와 같은 마인드를 가져야 하지 않을까 한다.

 

마지막으로 앞의 구본형 소장의 글을 SW아키텍처에 비유해 다음과 같이 무단 변경해 본다. 

 



SW아키텍처를 제대로 이해하기 위해서는 건축물을 연상하는 것이 가장 완벽한 동질성을 부여한다.

 

SW아키텍처는 '시스템의 설계도'라고 말하는 사람들이 많다.

그러나 나는 그 생각에 강하게 반대한다.

 

그것을 설계도라고 해석하는 데서부터 많은 오류가 발생한다는 것을 알고 있기 때문이다.

설계도는 전문가들을 위한 것이다.

 

보통 사람은 설계도를 보고 그 건물의 전체적 모습을 떠올릴 수 없다.

그것은 판독하기 어려운 수치와 기호일 뿐이다.

 

SW아키텍처는 이해관계자 모두가 쉽게 그 모습을 머릿속에 떠올릴 수 있어야 하며,

그 모습의 아름다움 때문에 마음이 설레야 한다.

 

따라서 SW아키텍처는 오히려 건물의 조감도와 흡사하다.

소프트웨어의 유려한 자태와 추상화된 고품질의 질감이 느껴져야 한다.

 

그리고 그 시스템 속의 한 부분을 줌업시키면 그 속에 서브 시스템이 생활할 새로운 공간이 보인다.

 

이 시스템이 만들어지면 이 아름다운 것을 사용할 것이다.

어둡고 추운 지금의 시스템을 떠나 밝고 넓고 전망이 좋은 시스템을 활용하게 될 것이다.



 

'프로젝트 관리' 카테고리의 다른 글

아키텍처의 출발점  (0) 2019.04.04
Core/Context 모델  (0) 2019.03.22
Tuckman의 팀 발달 모델  (0) 2019.03.08
Posted by 사용자 박종명

댓글을 달아 주세요

지난 Docker : Dockerfile 편에서는 도커파일의 개념 설명과 도커파일의 생성, 그리고 도커파일을 이용하여 이미지를 만들고 컨테이너를 실행하여 아파치에 접근해보는 간단한 실습을 진행 하였다. 이번 시간에는 도커를 이용하여 Jenkins Slave Node를 생성하여 빌드해보는 실습을 진행 해보고 이 과정을 도커파일로 만들어보도록 하겠다.



Jenkins 분산빌드환경


서버의 자원이 한정된가난한 상태에서 다수의 사람들이 Jenkins(이하 젠킨스)를 통해 빌드를 하다보면 점점 빌드가 잦아지고 결국 빌드를 대기하는 일종의 빌드 병목현상이 발생한다. 게다가 몸집이 큰 프로젝트 파일을 빌드하기 위해서 상당한 시간이 소요되는 경우도 있어서 빌드를 기다리기보다 수동빌드를 하는게 더 나은 상황이 발생 할 수 있다.


이를 분산빌드환경(Slave Node 추가)을 통하여 해결 해보도록 하자.



먼저 젠킨스 메인 화면의 좌측 Jenkins 관리를 누르고 아래로 스크롤하여 노드관리 메뉴로 진입한다. 신규 노드를 눌러 노드명을 입력하고 Permanent Agent 선택 후 OK를 누르면 아래 상세정보 입력 화면으로 이동한다. 필자는 Slave Node Name을 m7Docker라고 입력하였다. Credentials 에는 Docker 컨테이너에 접근할 계정을 Add를 눌러 입력해주면 된다. 필자는 ID는 root에 비밀번호는 xptmxm123으로 입력 후 저장하였다. 이후 이미지에는 나와있지 않지만 필자는 SSH 포트를 8890으로 변경해주었다 (고급버튼 누르면 포트변경 가능)




Jenkins Build를 위한 Slave Node용 도커 컨테이너 생성


다음은 Ubuntu 16.04를 이용하여 젠킨스 서버에서 도커 컨테이너로 SSH로 접근 후 maven 빌드를 수행하는 컨테이너 하나를 만들어보도록 하겠다. 이미지 생성과 컨테이너 생성은 이미 한번 다룬 내용이므로 너무 자세한 설명은 생략 하고 명령어 위주로 작성하겠다.


먼저 docker run명령을 통해 컨테이너를 생성하자 포트포워딩은 젠킨스 slave설정에서 지정해둔 8890 포트와 도커 컨테이너에 접근할 22번 포트를 서로 연결하였다.


[root@localhost testuser]# docker run -i -t -p 8890:22 --name jenkins_slave docker.io/ubuntu:16.04
root@8d8eeb87e586:/#


이제 이 아무것도 없는 도커 컨테이너를 젠킨스 Slave Node로 활용하기 위해 무엇을 해야할까 한번 정리 해보자.


1. 패키지 업데이트

2. 컨테이너 접근을 위한 ssh 설치

3. 빌드를 위한 maven 설치

4. 소스변경사항을 가져오기 위한 git 설치

5. jdk11이 적용된 프로젝트의 빌드를 위해 openjdk11 설치

6. root 계정을 사용하기 위해 root 패스워드 설정

7. ssh로 root접근이 가능하도록 sshd_config파일의 옵션 수정

8. Jenkins 전역설정의 JAVA_HOME과 MAVEN_HOME의 경로 동기화


이정도가 되겠다. 먼저 패키지 업데이트부터 차근차근 진행 해보자.



1. 패키지 업데이트


root@8d8eeb87e586:/# apt-get update Get:1 http://archive.ubuntu.com/ubuntu xenial InRelease [247 kB] Get:2 http://security.ubuntu.com/ubuntu xenial-security InRelease [109 kB] Get:3 http://archive.ubuntu.com/ubuntu xenial-updates InRelease [109 kB] ... ... Fetched 15.7 MB in 1min 3s (248 kB/s) Reading package lists... Done



2. SSH 설치


root@8d8eeb87e586:/# apt-get install -y openssh-server Reading package lists... Done Building dependency tree Reading state information... Done ... ... Setting up ssh-import-id (5.5-0ubuntu1) ... Processing triggers for libc-bin (2.23-0ubuntu11) ... Processing triggers for ca-certificates (20170717~16.04.2) ... Updating certificates in /etc/ssl/certs... 148 added, 0 removed; done. Running hooks in /etc/ca-certificates/update.d... done. Processing triggers for systemd (229-4ubuntu21.16) ...



3. Maven 설치


root@8d8eeb87e586:/# apt-get install -y maven Reading package lists... Done Building dependency tree Reading state information... Done ... ... After this operation, 156 MB of additional disk space will be used. Get:1 http://archive.ubuntu.com/ubuntu xenial-updates/main amd64 libjpeg-turbo8 amd64 1.4.2-0ubuntu3.1 [111 kB] Get:2 http://archive.ubuntu.com/ubuntu xenial-updates/main amd64 x11-common all 1:7.7+13ubuntu3.1 [22.9 kB] Get:3 http://archive.ubuntu.com/ubuntu xenial/main amd64 libxtst6 amd64 2:1.2.2-1 [14.1 kB] ... ... done.



4. Git 설치


root@8d8eeb87e586:/# apt-get install -y git-core Reading package lists... Done Building dependency tree Reading state information... Done Get:1 http://archive.ubuntu.com/ubuntu xenial/main amd64 libatm1 amd64 1:2.5.1-1.5 [24.2 kB] Get:2 http://archive.ubuntu.com/ubuntu xenial/main amd64 libmnl0 amd64 1.0.3-5 [12.0 kB] Get:3 http://archive.ubuntu.com/ubuntu xenial/main amd64 libpopt0 amd64 1.16-10 [26.0 kB] ... ... update-alternatives: using /usr/bin/file-rename to provide /usr/bin/rename (rename) in auto mode Processing triggers for libc-bin (2.23-0ubuntu11) ... Processing triggers for systemd (229-4ubuntu21.16) ...



5. OpenJdk 11 설치 (필자는 11.0.1 버전을 사용하였다.)


root@8d8eeb87e586:/# wget -P /usr/local https://download.java.net/java/GA/jdk11/13/GPL/openjdk-11.0.1_linux-x64_bin.tar.gz --2019-03-22 01:15:09-- https://download.java.net/java/GA/jdk11/13/GPL/openjdk-11.0.1_linux-x64_bin.tar.gz Resolving download.java.net (download.java.net)... 23.212.14.196 Connecting to download.java.net (download.java.net)|23.212.14.196|:443... connected. HTTP request sent, awaiting response... 200 OK Length: 187599951 (179M) [application/x-gzip] Saving to: '/usr/local/openjdk-11.0.1_linux-x64_bin.tar.gz' openjdk-11.0.1_linux-x64_bin.tar.gz 100%[===================================================================================================================>] 178.91M 22.2MB/s in 8.7s 2019-03-22 01:15:23 (20.5 MB/s) - '/usr/local/openjdk-11.0.1_linux-x64_bin.tar.gz' saved [187599951/187599951] root@8d8eeb87e586:/# cd /usr/local/ && tar -xzf openjdk-11.0.1_linux-x64_bin.tar.gz && rm openjdk-11.0.1_linux-x64_bin.tar.gz root@8d8eeb87e586:/usr/local# ls bin etc games include jdk-11.0.1 lib man sbin share src root@8d8eeb87e586:/usr/local#



6. root 패스워드 설정


root@8d8eeb87e586:/usr/local# passwd root Enter new UNIX password: Retype new UNIX password: passwd: password updated successfully root@8d8eeb87e586:/usr/local#



7. sshd_config 설정파일 수정 (ssh로 root계정에 접근하기 위한 설정 변경)


root@8d8eeb87e586:/usr/local# vi /etc/ssh/sshd_config bash: vi: command not found



당황하지 말고 vi에디터를 설치 해주도록 한다.


7-1. vi에디터 설치


root@8d8eeb87e586:/usr/local# apt-get install vim Reading package lists... Done Building dependency tree Reading state information... Done ... ... Processing triggers for libc-bin (2.23-0ubuntu11) ...



7-2. sshd_config 파일 수정 (PermitRootLogin의 prohibit-password설정을 yes로 바꾼 후 저장한다.)


root@8d8eeb87e586:~# vi /etc/ssh/sshd_config

... ...

# Authentication: LoginGraceTime 120 PermitRootLogin prohibit-passwordyes ... ... :wq



8. Jenkins 전역 설정에 맞추어 JAVA_HOME과 MAVEN_HOME 경로 설정


필자는 JDK는 /usr/local/jdk-11.0.1에 저장 하였고(다운로드 및 압축해제는 위의 설정과 같으므로 JAVA_HOME은 별 다른 설정이 필요하지 않다.) maven은 /usr/share/maven 폴더에 저장이 되어있는데 /usr/local/apache-maven-3.5.3의 경로로 심볼릭링크를 걸어두었다.


root@8d8eeb87e586:~# ln -s /usr/share/maven /usr/local/apache-maven-3.5.3



이제 모든 준비가 완료 되었다. Jenkins 서버에서 현재 설정해둔 도커 컨테이너로의 접근이 가능한지 확인 해보자. 먼저 Jenkins 서버에서 필자의 컨테이너에 접근하기 위해서는 외부에서 접근이 가능하도록 포트를 열어 주어야 한다. 필자는 윈도우 10을 기준으로 설명하겠다. 먼저 방화벽의 인바운드 설정에서 아까 도커 컨테이너 생성 시 포트포워딩 했었던 8890을 지정해준다.




인바운드설정이 완료되면 8890으로 들어온 포트를 내부의 어떤 IP로 포워딩 할지 지정 해주어야 하는데 윈도우 커멘드를 관리자 권한으로 접근하여 포트 포워딩을 설정 해주도록 한다.


C:\WINDOWS\system32>netsh interface portproxy add v4tov4 listenport=8890 listenaddress=192.168.70.22 connectport=8890 connectaddress=172.17.100.97 C:\WINDOWS\system32>netsh interface portproxy show v4tov4 ipv4 수신 대기: ipv4에 연결: 주소 포트 주소 포트 --------------- ---------- --------------- ---------- 192.168.70.22 8890 172.17.100.97 8890



192.168.70.22:8890으로 들어온 포트를 필자의 컴퓨터 내부 IP인 172.17.100.97:8890으로 보낸다는 의미이다. Jenkins 서버에서 필자의 도커 컨테이너까지의 접근은 아래 이미지를 참고하기 바란다.




이제 젠킨스 Slave Node를 실행하여 도커 컨테이너로 접근해보자. ssh로 접근하기 위해 ssh service를 활성화 시켜준다.


root@8d8eeb87e586:~# service ssh start * Starting OpenBSD Secure Shell server sshd


ssh service 활성화가 완료되면 젠킨스에서 아까 생성한 m7Docker에 진입 후 Launch agent버튼을 눌러 Slave Node를 실행시킨다.



아래와 같은 로그가 올라온다면 ssh접속에 성공한것이다.


[03/22/19 12:21:07] [SSH] Opening SSH connection to 192.168.70.22:8890.

... ...

[03/22/19 12:21:07] [SSH] Starting sftp client. [03/22/19 12:21:07] [SSH] Remote file system root /jenkins does not exist. Will try to create it... [03/22/19 12:21:07] [SSH] Copying latest slave.jar... [03/22/19 12:21:07] [SSH] Copied 771,004 bytes. Expanded the channel window size to 4MB [03/22/19 12:21:07] [SSH] Starting slave process: cd "/jenkins" && java -jar slave.jar <===[JENKINS REMOTING CAPACITY]===>channel started Remoting version: 3.21 This is a Unix agent Evacuated stdout Agent successfully connected and online



이제 젠킨스 빌드 시 이 Slave Node를 활용하겠다는 설정을 해주어야 하는데 프로젝트 진입 → 구성 → Restrict where this project can be run을 체크하고 위에서 생성했던 m7Docker 를 입력하여 저장해준다.



이제 빌드를 진행 해보자.



m7Docker Slave Node에서 빌드가 정상적으로 진행되었다.



지금까지의 과정들은 도커파일을 사용하면 현재 도커 컨테이너와 동일한 설정이 담긴 이미지를 한번에 생성 할 수 있다. 도커파일의 생성방법은 지난 시간에 설명하였으므로 이번 시간에는 도커파일의 스크립트 설명과 직접 도커파일을 빌드하여 이미지를 생성하고 컨테이너에 SSH접근까지만 확인하도록 하겠다.

# Ubuntu 16.04버전을 기반으로 함
FROM ubuntu:16.04

# 다운로드 링크, 파일명, maven 버전 등 변경이 필요한 경우를 대비해 변수로 선언해준다.
ARG jdkFileName=openjdk-11.0.1_linux-x64_bin.tar.gz
ARG jdkDownloadUrl=https://download.java.net/java/GA/jdk11/13/GPL/${jdkFileName}
ARG mavenHome=/usr/local/apache-maven-3.5.3
ARG userName=root
ARG userPassword=xptmxm123

# 패키지 목록 최신화 후 원격 접속을 위한 ssh와 빌드를 위한 maven 및 변경내역을 가져올 git을 설치한다.
RUN apt-get update
RUN apt-get install -y openssh-server
RUN apt-get install -y maven
RUN apt-get install -y git-core

# 현재 jenkins 전역설정에서 maven의 경로는 /usr/local/apache-maven-3.5.3 으로 지정 해두었다.
# ln -s 명령을 사용하여 심볼릭 링크를 걸어준다.
RUN ln -s /usr/share/maven ${mavenHome}

# service 및 api의 빌드는 jdk11이 필요하므로 다운로드 받고 압축을 풀어준다.
RUN wget -P /usr/local ${jdkDownloadUrl}
RUN cd /usr/local/ && tar -xzf ${jdkFileName} && rm ${jdkFileName}

# root 계정을 사용할 것이므로 root계정의 비밀번호 설정 및 root계정으로 ssh접근이 가능하도록 수정한다.
RUN echo "${userName}:${userPassword}" | chpasswd
RUN sed -i 's/PermitRootLogin prohibit-password/PermitRootLogin yes/' /etc/ssh/sshd_config

# 컨테이너 시작 시 ssh서비스를 Active 시키기 위해 ENTRYPOINT를 지정 해둔다
ENTRYPOINT service ssh restart && /bin/bash

# 외부에서 접근이 가능한 포트를 지정해준다. ssh접속이므로 22번 포트 설정
EXPOSE 22


이제 해당 도커파일을 기반으로 이미지를 생성해보자. 도커파일을 빌드하고 이미지가 잘 생성되었는지 확인해보자.


[root@localhost test2]# docker build -t docker_img ./ ... ... ---> aba77358024b Removing intermediate container 490098d7f585 Step 16/17 : ENTRYPOINT service ssh restart && /bin/bash ---> Running in 22cd10713ee8 ---> 98e07e4fc4b5 Removing intermediate container 22cd10713ee8 Step 17/17 : EXPOSE 22 ---> Running in bcf569c735cc ---> 07f9b213b807 Removing intermediate container bcf569c735cc Successfully built 07f9b213b807 [root@localhost test2]# docker images REPOSITORY TAG IMAGE ID CREATED SIZE docker_img latest 07f9b213b807 3 minutes ago 939 MB docker.io/ubuntu 16.04 9361ce633ff1 10 days ago 118 MB apache_img first d307433464d8 2 weeks ago 390 MB layer_test second 127ab2a39585 4 weeks ago 188 MB layer_test first 48f47ef8257d 4 weeks ago 188 MB docker.io/ubuntu 14.04 5dbc3f318ea5 8 weeks ago 188 MB


새로만든 이미지로 docker run 명령을 실행하기 전에 이전에 켜두었던 jenkins_slave 컨테이너는 종료 하도록 한다. (포트가 겹치므로)


[root@localhost test2]# docker ps -a CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 8d8eeb87e586 docker.io/ubuntu:16.04 "/bin/bash" 19 hours ago Up 4 hours 0.0.0.0:8890->22/tcp jenkins_slave dcc887cf8b0b apache_img:first "apachectl -D FORE..." 2 weeks ago Exited (137) 2 days ago apache_test d33a60d75c45 layer_test:first "/bin/bash" 4 weeks ago Exited (255) 2 weeks ago layer_test2 c73025587f2b ubuntu:14.04 "/bin/bash" 4 weeks ago Exited (0) 4 weeks ago layer_test [root@localhost test2]# docker stop jenkins_slave jenkins_slave [root@localhost test2]#


이제 새로운 이미지로 컨테이너를 생성하도록 한다.
실행이 잘 되었다.


[root@localhost test2]# docker run -i -t -p 8890:22 --name jenkins_slave2 docker_img:latest * Restarting OpenBSD Secure Shell server sshd [ OK ] root@72f83424f1dc:/#


이제 젠킨스에 다시 들어가서 Launch Agent 버튼을 눌러 SSH 접근이 가능한지 확인해보자.

아래 이미지가 출력되면 SSH접속에 성공한것이다.



여기까지 젠킨스 도커 컨테이너를 활용한 Slave Node의 생성과 빌드를 해보고 이 과정을 도커파일로 만들어 이미지를 생성하고 컨테이너 화 하는 실습까지 진행 해보았다. 이미지를 그대로 내려받았을때 세부설정에 대한 변경이 필요한 경우가 있을것이다. 이 때마다 컨테이너를 만들고 설정을 바꿔 다시 commit명령으로 새로운 이미지를 만드는 과정이 생길 수 있는데 도커파일을 활용하면 이러한 낭비를 없앨 수 있다. 또한 도커파일은 설정만 바꾸어 여러대의 서버에 적용하여 사용하는 경우에도 효과적으로 사용할 수 있다.




Docker : Dockerfile 실습 편

끝.



'Docker' 카테고리의 다른 글

Docker : 도커스웜 클러스터 구축 편  (0) 2019.05.17
Docker : 컨테이너 오케스트레이션 개요 편  (0) 2019.04.19
Docker : Dockerfile 실습 편  (0) 2019.03.22
Docker : Dockerfile 편  (0) 2019.03.07
Docker : 이미지 편  (0) 2019.02.22
Docker : 컨테이너 편  (1) 2019.02.15
Posted by DevStream

댓글을 달아 주세요

아마... 아래 그림은 한번쯤은 본 적이 있을 겁니다.
개개인의 서로 다른 재능을 무시한채, 획일적인 기준으로 평가하는 문제를 풍자하는 그림인데요..


"공정한 선발을 위해 같은 시험을 봐야 합니다: 모두 저 나무에 올라 가세요" (말풍선)

"모두가 천재다. 그러나 나무에 오르는 능력으로 물고기를 판단한다면, 그 물고기는 평생 자신을 멍청하다고 생각하며 살아갈 것이다" - 아인슈타인



이 카툰은 획일적인 교육과 평가에만 의존하는 교육분야의 문제 인식으로 자주 인용되지만, 기업의 경영 전략에도 대입해 볼 수 있다는 생각이 듭니다.


기업의 존재 목적은 수익 창출입니다. 모든 기업은 수익을 창출하기 위해 다른 기업과는 차별화된 재화나 서비스를 시장에 공급합니다. 이러한 수익 창출 과정에서 주어진 자원을 최대한 효율적으로 사용해서 수익을 극대화 시키고 리스크(risk)를 경감하는 것이 중요합니다.


따라서 기업은 자신이 제공하는 핵심 서비스 전개를 위한 업무 역량은 자체적으로 내재화 시켜서 경쟁력을 확보하고 다른 기업과의 차별화를 꾀해야 합니다. 


반면, 핵심 서비스에 직접적이지 않은 비 핵심업무는 다른 기업이나 다른 사람에게 위임하여 그들의 전문성을 활용하는 것이 좋습니다. 그렇게 해야 생산성이 향상하고 리스크를 경감할 수 있습니다. 


기업의 외주(아웃소싱) 전략에 좋은 참조 모델이 있어 소개하고자 합니다.


---


'캐즘(Chasm) 이론'으로 유명한 제프리 A.무어의 '코어/컨텍스트(Core/Context) 모델'은 기업이 주어진 자원을 어떻게 운용하는 것이 좋을지에 대한 참조 모델을 제시하며 '클라우드 충격'이라는 책에서 자세히 설명하고 있습니다.


코어(Core)란 의미 그대로 기업의 핵심 업무를 말합니다. 코어 업무는 기업의 경쟁우위를 높여주는 중요한 것이므로 최대한 자원을 집중해야 하고 자체 개발을 해야 한다는 것입니다.


반면 컨텍스트(Context)는 코어 이외의 모든 활동이라고 말합니다. 컨텍스트 업무는 차별성을 추구하는 것이 아니라 가능한 표준적인 방식으로 효율을 최우선으로 수행하는 것'이 좋다고 말합니다.


또한 이러한 컨텍스트 업무는 어느 누군가에게는 코어 업무이기 때문에 그쪽에 아웃소싱을 맡길 수 있다고 시사합니다.

게임을 개발하는 기업에서 인사관리 프로그램이 필요한 사례를 예로 들어 보겠습니다.


게임 개발은 회사의 중요한 코어 업무이기 때문에 자체 개발을 해야 하며, 인사관리 프로그램은 컨텍스트 업무이기에 그 업무를 코어로 하는 외부 업체에게 아웃소싱 하는 식입니다.


그러나 코어/컨텍스트만으로는 기업내 모든 활동을 양분하기에는 한계가 있어 보입니다.


무어는 코어/컨텍스트 구분과 더불어, '미션크리티컬/'비미션크리티' 이라는 또 하나의 축을 또 다른 기준으로 내세웠습니다. 미션 크리티컬은 만일 중지되었을 때 즉시 심각한 리스크로 이어지는 기업 활동을 말하며 그 외의 모든 업무는 비 미션크리티컬이 됩니다. 즉 리스크의 정도를 기준으로 삼고 있습니다

.

이에 대한 도식은 아래와 같습니다.


[출처: 클라우드의 충격]


---


제가 속해 있는 IT 분야에서도 아웃소싱 전략에 큰 영향을 주는 두가조 요소가 있습니다.


바로 클라우드(Cloud)와 오픈소스(Opensource)입니다.


오픈소스의 경우 외주(아웃소싱)라는 카테고리와는 성격이 조금 다를 수 있지만, 특정한 업무를 외부 자원으로 해결한다는 위임이라는 측면에서는 맥을 같이 하기에 연결지어 봤습니다.


클라우드의 경우 종전의 자체 전산실에 직접 렉과 장비를 구비하고 운영했던 온프레미스(On-Premise) 환경과는 달리 클라우드 환경에서는 이러한 물리적인 장비와 운영체제, 소프트웨어까지 빌려 쓸 수 있게 되었습니다. 또한 기업은 자신들이 어디 까지를 직접 운영할지 결정하여 Iaas, Paas, Saas 형태의 클라우드 서비스 모델을 선택할 수 있습니다. 


갈수록 IT 환경의 판이 많이 달라지고 있습니다. 자원을 최적화 시키는 것은 기업의 생산성을 향상시키는 것 뿐만 아니라, 서로 다른 재능을 가진 기업간 위임이 활성화 되어 산업의 발전에도 기여하게 된다고 봅니다. 과거 분업화가 많은 발전을 야기한 것 처럼요.


현재 자신의 회사나 수행하는 프로젝트에서, 코어와 컨텍스트, 미션크리티컬과 비미션크리티컬의 4사분면에 해당하는 업무가 무엇인지 파악하여 전략을 재정비 해 보는 것도 좋을 것입니다.

'프로젝트 관리' 카테고리의 다른 글

아키텍처의 출발점  (0) 2019.04.04
Core/Context 모델  (0) 2019.03.22
Tuckman의 팀 발달 모델  (0) 2019.03.08
Posted by 사용자 박종명

댓글을 달아 주세요