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