MSFL :: 모리스 소프트웨어 공작소

NodeJS를 활용하는데 필요한 패키지들과 리소스들을 정리해 놓은 사이트가 있어서 링크를 걸어 놓는다. https://github.com/sindresorhus/awesome-nodejs

공개된 개발관련 Ebook과 Tutorial 들을 정리해 놓은 곳이 있어서 링크를 걸어 놓는다. http://stackoverflow.com/revisions/392926/175 참 많기도 많다.. ㅠㅠ

발생 환경 현재 프로젝트에서 Dropwizard를 적용하고 있는데, Mesos와 연계할 부분이 생겨서 Mesos Client를 구성하고 Ning을 사용해서 비동기 Http 클라이언트를 구성하였다. 그런데 디버그 모드일 때는 상관이 없지만 (아마도 처리가 되는 시간적인 부분이 있는 듯 하다) 실행에서 java.io.IOException: Unable to establish loopback connection 오류가 발생하는 것을 확인하였다. 오류 메시지 4047 ERROR 2015-02-26 14:01:13 [main] com.ning.http.client.AsyncHttpClient[loadDefaultProvider:561] -Unable to instantiate provider com.ning.http.client.providers.netty.NettyAsyncHttpProvider. Trying other providers. 4053 ERROR 2015-02-26 14:01:13 [main] com.ning.http.client.AsyncHttpClient[loadDefaultProvider:564] -org.jboss.netty.channel.ChannelException: Failed to create a selector. org.jboss.netty.channel.ChannelException: Failed to create a selector. at org.jboss.netty.channel.socket.nio.AbstractNioSelector.openSelector(AbstractNioSelector.java:343) ~[netty-3.9.2.Final.jar:na] at org.jboss.netty.channel.socket.nio.AbstractNioSelector.(AbstractNioSelector.java:100) ~[netty-3.9.2.Final.jar:na] at org.jboss.netty.ch

요즘 진행하고 있는 Docker 관련한 프로젝트에서 여러 가지 오픈 소스들을 검토하고 적용하면서 새로운 플랫폼으로서의 활용도를 검증하고 있다. 그런데 많은 오픈 소스들이 Go, Ruby, Python, Scala 와 같은 내게는 이질적인 언어들을 사용하고 있는 관계로 이번에 Python에 도전해 보도록 한다. ㅠㅠ 우선 첫 걸음으로 Hello World!를 출력해 보도록 하자. Python 설치 Python (이하 파이썬)의 안정화 버전은 파이썬2 기준으로 2.7.9와 파이썬3 기준으로 3.4.2가 발표된 상태이며, 파이썬3와 파이썬2가 서로 호환성이 높지 않기 때문에 별도로 버전이 진행되고 있으므로 필요한 버전으로 설치를 하면 된다. 파이썬의 설치 파일은 python.org/download 에서 msi를 받아서 설치하면 된다. 설치할 때 기본적으로 환경설정 (PATH 설정)이 꺼져있으므로 이를 활성화해 주거나 아니면 설치 후에 수동으로 설정해야 한다. 설치에서 환경 설정은 기본적인 설치 경로만 처리해 주므로 수동으로 설정이 필요하다. 따라서 여기서는 기본 설치 후에 환경 변수를 설정하는 것으로 한다. 설치 후에 환경 설정 (PATH) 해 주어야 하는 기본 경로는 아래와 같다. C:\Python34 <- 인스톨러 옵션을 활성화하면 설정되는 기본 폴더 C:\Python34\Scripts <- 추가 설정 (향후 사용 편의를 위해) C:\Python34\Tools\Scritps <- 추가 설정 (향후 사용 편의를 위해) 위와 같은 설정이 모두 완료되면 실행 파일에 대한 링크를 설정해 준다. 여러 버전을 관리할 수 있도록 3.x 버전부터는 각 실행파일에는 버전이 붙기 때문에 나중에 사용할 때 번거롭다. 만일 단일 버전만 사용한다면 굳이 아래와 같이 링크를 설정할 필요는 없다. C: \> mklink python34 .exe python .exe C: \> mklink p

apt-get update 명령을 사용해서 처리를 수행할 때 중간에 파일 Not found (404, …) 등으로 오류가 발생할 수 있다. 대 부분의 경우는 실제 구성 패키지의 일부 파일들이 다운로드되지 않아서 패키지의 Hash sum 값이 틀리다는 오류다. 원인은 Archive 파일이 잘 못된 경우도 존재하지만 거의 대부분은 네트워크가 느려서 발생하는 경우로 이 때는 좀 더 빠른 사이트로 변경을 해 주면 문제없이 해결할 수 있다. 패키지 소스에 대한 정보는 /etc/apt/sources.list 파일에 존재한다. 해당 파일을 확인해 보면 사이트가 archive.ubuntu.com 으로 지정되어 있는데 무선 접속이나 통신망이 원할하지 않는 경우는 큰 패키지 처리 시에 위와 같은 오류가 지속적으로 발생한다. 따라서 사이트를 국내에서 제공하는 사이트로 변경해서 처리하면 된다. $ sudo sed -i 's/archive.ubuntu.com/ftp.daum.net/g' /etc/apt/sources.list 위의 명령은 ‘sed’ 툴을 이용해서 /etc/apt/sources.list 파일의 내용 중에서 archive.ubuntu.com 으로 지정된 모든 문자열을 ftp.daum.net 으로 변경해서 원본을 갱신하는 것이다. 이렇게 국내 미러 사이트로 변경을 하면 네트워크 문제로 인한 오류는 대 부분 해결이 된다. 그러나 OS 상에 설치되어 있는 정보에 문제가 있어서 발생하는 경우도 존재할 수 있기 때문에 아래와 같이 추가적인 설정을 처리해 주면 된다. $ sudo rm -rfv /var/lib/apt/lists/* && sed -i 's/# \(.*multiverse$\)/\1/g' /etc/apt/sources.list && apt-get update && apt-get -y upgrade 위의 명령은 /var/lib/apt/lists 폴더의 내용

아파치 웹 서버 (Apache Web Server)에는 mod_proxy 모듈이 내장되어 있다. 이 모듈은 Forward Proxy (이하 전달 프록시) 와 Reverse Proxy (이하 배후 프록시) 기능을 제공한다. Forward Proxy 사용자 (이하 클라이언트)가 특정 서버에 연결하려고 할 때 클라이언트 PC가 직접 연결하는 것이 아니라 클라이언트가 내부의 전달 프록시를 통해서 요청을 하면 전달 프록시가 클라이언트가 요청한 정보를 기준으로 요청을 전달하고, 연결된 서버의 결과를 전달 프록시가 클라이언트로 반환해 주는 것이다. 일반적으로 사내망 (Private Network) 에서 외부로 나갈 때 사용하는 프록시를 의미한다. 아래의 그림을 보면 쉽게 이해할 수 있다. 또한 캐시 기능을 통해서 자주 사용되는 컨텐츠라면 성능향상을 제공하고, 정해진 규칙에 따라 사용자들의 접속을 조정할 수 있기 때문에 기업 환경에서 많이 사용된다. Reverse Proxy 위에서 설명한 전달 프록시와는 반대로 생각하면 된다. 즉, 외부의 요청을 배후 프록시가 받아서 내부 망에 존재하는 서버에 연결하고 결과를 클라이언트에 반환한다. 그냥 내부에 존재하는 서버를 외부의 연결에 노출해도 되지만 보안 상의 이유로 이렇게 구성하지 않는다. 기업망에서는 일반적으로 DMZ 이라고 표현하는 내부 망과 외부 망을 구분하는 영역을 지정하고 이 영역에 메일 서버, 웹 서버, FTP 서버등을 배치해서 서비스를 한다. 그러나 보통 WAS (웹 어플리케이션 서버)를 DMZ에 배치하게 되는 경우에 일반적으로 WAS를 통해서 데이터베이스에 접근하는 경우가 많기 때문에 WAS를 내부 망에 배치하고 DMZ 영역에는 배후 프록시를 배치해서 외부에서는 배후 프록시만 노출이 되고 실제 서비스가 진행되는 서버들은 모두 내부 망에 배치되도록 하는 것이 보통이다. 따라서 DMZ에는 요청에 대한 주소 매핑 처리를 위한 아파치 웹 서버만 배치해서 배후 프록시 매핑을 통해 내부 망의 WAS

References 원문 : https://github.com/patrickhoefler/coreos-vagrant-kubernetes/blob/master/Vagrantfile 이 글은 원문의 내용을 기준으로 여러 가지를 테스트하면서 나름대로 정리한 내용으로 Vagrant를 사용해서 CoreOS, CoreOS Cluster, Kubernetes 까지 설정하는 방법을 로컬 머신에서 설정해 보는 것을 정리하도록 한다. 기본 설치 작업에 필요한 바이너리와 프로젝트등은 모두 GitHub를 통해서 얻게 되므로 로컬 머신에 Git 가 설치되어 있어야 하며 아래의 모든 명령들은 Git Bash 를 기준으로 한 것이다. 필요 도구 설치 로컬 머신에 단일 CoreOS 를 구성하는 작업을 먼저 진행하기 위해서는 다음과 같은 도구의 설치가 필요하다. VirutalBox 4.3.10+ or VMWare Vagrant 1.6+ Vagrant를 사용해서 CoreOS 설치를 하기 위한 프로젝트를 복제한다. $ git clone https://github.com/patrickhoefler/coreos-vagrant-kubernetes $ cd coreos-vagrant-kubernetes VM에 CoreOS 구성 VM을 구성하는데는 아래와 같이 2 가지 프로바이더가 존재한다. Vagrant의 내부 처리 명령도 프로바이더에 따라 다르기 때문에 사용할 툴에 따라서 프로바이더 정보를 설정해야 한다. 기본으로 VirtualBox 프로바이더를 사용한다. 아래와 같이 vagrant up 명령이 실행되면 CoreOS 이미지를 다운로드하고 VM에 Guest OS로 설치를 진행한다. 이미 구성된 경우라면 VM을 실행시키는 명령을 처리한다. Notes 더 다양하게 CoreOS 이미지에 대한 채널 (Alpha, Beta, Stable) 을 설정하거나, SSH 구성 정보나, VM의 갯수 및 메모리 크기를 변경하려면 Vagrant에서 제공하는 config.r

Notes DataImport 처리에 대해서 처음 접하는 경우는 아래와 같은 정보를 사전에 검토해야 한다. DataImport 처리를 처음 구성하는 경우는 이미 많은 정보들이 존재하므로 찾아서 검토를 하고, DataImport 와 관련된 다음의 정보를 검토해야 한다. DataImport 처리할 때 주의할 점 DataImport 에서 last_index_time 의 의미와 사용법 Quartz Schedule 을 이용한 DataImport 작업 수행 그리고 실제 작업을 진행하면서 만났던 오류를 기준으로 정리한 것으로 다른 원인과 다른 오류가 더 많을 수 있으므로 Solr관련 정보를 확인해야 한다. DataImport on SolrCloud 단일 서버에 구성했던 Solr 로 DataImport 를 처리하는 것과 동일하게 처리하면 된다. 아래는 기존 샘플 에서 사용했던 Collection 을 대상으로 DataImport (Full-Import) 를 처리하는 명령이다. http: / /localhost:7070/solr /test-collection/dataimport ?command=full-import&clean= true &commit= true 단, 차이점이라면 Solr Admin UI 에서 처리하는 “DataImport” 는 Collection name 을 이용하는 것이 아니라 실제 Core 를 사용한다는 점이다. 예를 들면 다음과 같은 명령이 호출된 것과 같다. http: / /localhost:7070/solr /test-collection_shard1_replica1/dataimport ?command=full-import&clean= true &commit= true 명령을 처리하는 방식 (Request or Admin UI) 의 차이를 제외하면 기존 방식과 동일하게 처리하면 된다. Problems dataimport.p

[ 참고 및 주의 사항 ] 여기에 정리된 내용은 원문 을 기준으로 여러 가지 테스트와 문제점의 검토 및 해결책을 찾으면서 나름대로 정리한 내용으로 오역과 잘 못 이해하고 정리한 부분이 있을 수 있습니다. 또한 원문의 Solr 버전이 지금 테스트를 진행하고 있는 4.10.2 버전과 다르기 때문에 내용을 잘 확인하면서 진행 해야 합니다. SolrCloud Collection 디자인 SolrCloud 를 운영하기 위해서는 Cluster를 디자인을 하는 것이 가장 중요한 부분이다. 개념적으로는 SolrCloud Cluster 내에서 Collection 과 Shard 는 논리적인 요소로 여러 개의 물리적인 Core 들의 집합을 형성하기 위한 것 이다. 샘플 테스트를 위해서 다음과 같이 Cluster를 디자인 한 것으로 가정한다. Cluster에는 단일 Collection을 관리하고 이름을 test_collection 이라고 한다. ZooKeeper Ensemble 은 3개의 복제된 서버들을 사용하는 것으로 한다. Replication Factor를 3으로 지정하여 SolrCloud 에 3개의 Node를 구성한다. SolrCloud 에 3개의 Shard 를 구성한다. 3개 노드의 3개 Shard에 복제 본들을 수동으로 배포한다. 필요 항목들 이 작업을 테스트하기 위해서는 다음과 같은 구성이 필요하다. Apache Tomcat 7.x Apache ZooKeeper 3.4.6 Apache Solr 4.10.2 Notes 위의 디자인된 SolrCloud 는 단일 장비에서 테스트를 진행한다. 실제로는 여러 장비에 분산하여 운영되는 것이 정상이다. 샘플 디렉터리 구성 단일 장비에서 테스트를 진행할 것이기 때문에 “D:\SolrCloud” 를 기본 경로로 사용한다. Node 구성을 위한 각 Solr Home 폴더 D: \SolrCloud \solr \home 1 D: \SolrCloud \solr \home 2

[ 참고 및 주의 사항 ] 여기에 정리된 내용은 원문 을 기준으로 여러 가지 테스트와 문제점의 검토 및 해결책을 찾으면서 나름대로 정리한 내용으로 오역과 잘 못 이해하고 정리한 부분이 있을 수 있습니다. ZooKeeper 란? ZooKeeper는 분산 어플리케이션들에 대한 분산 조정 서비스를 제공하는 프로그램으로 표준 파일 시스템과 유사하게 구성되어 공유된 계층적 공간을 통해서 분산된 프로세스들이 서로 조정할 수 있는 기능을 관리한다. 공유되는 공간은 ZooKeepr의 용어로 zNodes라고 불리는 데이터 등록의 집합으로 구성 되어 있으며 이 구조는 폴더들과 파일들의 구성과 유사하다. 파일 시스템과는 달리 ZooKeeper는 자바로 실행되며 자바와 C에 대한 바인딩을 가지고 있다. ZooKeeper Cluster 기본 구성 ZooKeeper Service 는 “Ensemble” 이라고 불리는 Host 들의 집합들을 통해서 복제되며, 동일한 어플리케이션을 구성하는 서버들의 복제된 그룹을 “Quorum” 이라고 부른다. Quorum 내의 모든 서버는 동일한 설정 파일들의 복제본을 가지고 있다. ZooKepper의 서버 구성의 수는 절반이 실패해도 기능을 수행할 수 있도록 항상 홀수로 구성하는 것을 권장 한다. 예를 들어 2대의 서버가 장애 상태가 되어도 나머지 서버들이 동작할 수 있도록 5대의 서버로 구성하는 것이다. 이 중에 한 대는 Leader가 된다. 최소한의 구성은 3 대가 된다. ZooKeeper 구성할 때 검토할 부분 ZooKeeper를 구성하기 위해서는 최소한 아래에 언급한 내용들에 대한 검토가 선행이 되어야 한다. 그리고 ZooKeeper Cluster의 구성은 아래의 그림과 같이 기본적으로 Leader를 포함하는 홀 수의 서버 구성이 되어야 한다. 여기서는 샘플을 테스트하는 것을 기준으로 검토를 진행하도록 한다. ZooKeeper 서버 구성의 수는 어떻게 할 것인가? - 위에서 언급한 것과 같이 홀수를 기준으로 구성