글쓴이 보관물: litcoder

AWS Lightsail에 둥지 틀기

여러 국내 호스팅 업체들을 거쳐서 여러 곳에서 WordPress 호스팅 서비스로 추천되는 Siteground에 한동안 정착하는 듯 했다. 준수한 속도에 비해 합리적인 가격($3.95/월) 때문에 당분간 정착할 거라고 생각하고 있었는데 일년이 지나서 서비스 갱신기간이 되자 가격이 세배 넘게 올라서 1년에 $143을 달라고 한다.($11.95/월).
“이건 너무 한 거 아니냐고!”

WordPress hosting은 더 비싸다

대안으로 생각한 것은 1) wordpress.com hosting과 2) AWS Lightsail이었는데, 발견한 한 가지 놀.라.운. 사실은 WordPress hosting에서 플러그인을 설차하려면 한달에 $25 짜리 business plan 이상을 계약해야 한다는 것이다. 한달에 $25라니!!! 멋 모르고 카드 결재를 하고 이리저리 플러그인 설치를 시도하다가 아래의 표를 발견하고는 미련 없이 ‘refund’ 버튼을 눌렀다.

AWS Lightsail은 한 달간 무료 시험기간을 주기 때문에 Siteground 계정이 종료하기 전에 미리 설치를 마쳤다. 인스턴스 리전을 한국으로 할까 하다가 이전 Siteground와 같은 위치인 싱가포르로 선택했고 WordPress의 export/import 기능 덕에 마이그레이션은 수월하게 진행되었다. Domain name은 호스팅 업체와 같은 곳으로 이전하는게 좋다고 해서 AWS Route 53으로 이전 및 1년 연기 등록을 했는데 상위 도메인에 따라 다르지만 .com의 경우 $13.2(세금포함)가 소요된다. 어라? 그러고 보니 Siteground에서 도메인을 연장하는 서비스는 $15.95였는데? 이눔 시키들…

도메인 이전과 새로운 IP 연결

도메인 이전을 요청하니 이전 관리자였던 Siteground에서 확인 메일이 왔고, 수락한 이후에는 하루 후에 AWS로 도메인이 이전되었다. 그 후에는 Lightsail의 네트워킹 탭에서 고정 IP와 DNS 영역을 생성해서 A 레코드를 추가하고 IP와 도메인 이름을 연결 시켜 주었다.

그리고 나서 한참을 DNS가 업데이트 되기를 기다렸다. nslookup은 여전히 예전 IP를 보여줬지만 48시간 까지 걸릴 수 있다는 말에 이틀정도를 기다렸는데도 IP가 업데이트 되지 않았다. AWS Route 53에 가보니 ‘registered domains > [domain name]’ 아래에 Name Servers 항목이 있는데 혹시 이것 때문인가 싶어서 고정 IP를 만들때 나왔던 네임서버 목록으로 업데이트를 해주었다. 그리고 나서 잠시 후 드디어 새로운 IP로 접속되었다!

계속 예전 IP로 돌아가는 도메인 문제와 해결

기쁜 마음으로 꿀잠에 들었는데 다음날 아침에 보니 Jetpack에서 서버연결 붙었다가 끊어졌다가 했다는 연락이 와 있었다. 혹시나 싶어서 서버를 재부팅 해봤더니 재부팅하는 순간 잠깐 IP가 새 것으로 붙었다가 다시 예전 IP로 돌아가는게 보였다. 그니까 누가 AWS 알고 있는 것과 다른 예전 정보를 자꾸 준다는 거지…” 혹시나 하는 마음에 Siteground의 cPannel > Advanced DNS zone editor에 들어가 봤더니 역시나 얘가 예전 주소를 꼭 쥐고 있었다. 예전 사업자의 도메인 서버를 AWS 고정 IP로 수정해 주고 났더니 Jetpack이 사이트 살아났다고 축하한댄다. 다행히 그 후로는 다시 끊어지는 일은 없었다.

도메인 관리자를 변경하고 새로운 IP를 연결 했으니 이전 네임 서버에서는 자동으로 놔 주겠거니 하고 잘 못 생각하고 있었던게 문제 였던듯 싶다.

Anycast M2 Plus는 Airplay용으로 적당할까?

비싼 AppleTV가 내 눈에 들어왔던 이유 중 하나는 편리 해보이는 Airplay 연결이었다. 최소 20만원 정도나 하는 비싼 가격때문에 망설이던 차에 Anycast M2 plus가 눈에 들어왔다 Airplay 뿐만 아니라 DLNA, Mirracast 등의 다양한 무선 display연결들을 지원한다고 하니 고려해볼만 하다고 생각했다. 가격은 대략 4만원 정도 된다.

img_5701.jpg

DLNA나 Mirracast는 사용해보지 않았고 iPad mini와 Macbook pro에서 Airplay만 사용해본 결과는 실망스러웠다.

가장 큰 문제점은 연결이 계속 끊어진다는 것인데, 끊어진 후에 연결 상태가 갱신되지 않기 때문에 디바이스를 다시 껐다가 켜야하는 경우가 많았다. 두번째로 Netflix를 재생할 수 없다는 점인데 이 문제는 Anycast M2 plus 뿐만 아니라 AppleTV에서도 있는 문제로 “기술적 한계” 때문에 지원되지 않는다고 한다. 아마도 Netflix에서 Airplay로 HDCP contents가 forwarding되는 것을 막은게 아닐까 추측해 본다. 혹시나 추후에 펌웨어 업데이트 등으로 문제가 해결 될 수도 있겠지만 그게 바로 세번째 문제점이다. 현재도 업그레이드 가능한 펌웨어가 있다고 표시되기는 하지만 업데이트 기능이 제대로 동작하지 않는다.

하지만, iPad mini와 달리 Macbook pro로는 Airplay 연결이 유지되도록 할 수 있는 방법이 있긴한데, lid를 열어 두거나 유선 display를 활성화 시켜 두는 것이다. 유선 display를 끄거나 lid를 닫으면 얼마 후에 연결이 끊어지게 되서 전원 옵션과 관련이 있지 않을까 여기저기 뒤져봤는데 찾지는 못했다.

결론은 제한적인 Macbook pro display 환경에서는 쓸만할 수도 있으나 iPad에서 연결하는 용도는 돈 값 못한다.

ClearLinux에 Tomcat 설치하기

2019년 3월 현재, Clear Linux에서는 Tomcat이 bundle로 제공되지 않기  때문에 수동으로 설치해야 한다. 이 포스트는 Clear Linux에 수동으로 Tomcat을 설치하기 위한 과정에 관한 것이다.

 

Java Runtime 설치

Tomcat을 실행하기 위해서는 Java runtime이 시스템에 설치 되어 있어야 한다. 만약 없다면 다음 명령어로 설치해 준다.

Java runtime을 설치한 후에는 버전명에 관계없이 접근할 수 있도록 보다 잘 알려진 경로인 /usr/lib/jvm/java로 링크를 생성해 주고 JAVA_HOME 환경 변수를 설정해 준다.

 

Tomcat 다운로드 및 설치

설치된 Java runtime에 맞게 Tomcat download page에서 적절한 binary distribution을 download받고 설치해준다. Tomcat website에 있는 Which version? 항목을 보면 아래와 같이 표가 나오는데,  “Supported Java Version”을 참고해서 적합한 “Apache Tomcat Version”을 선택하면 된다. 예를 들어, OpenGrok의 경우 Java 1.8이 requirement이므로, Tomcat version 9.0.x이상을 선택하면 된다.

sc_tomcat_versions

다음과 같이 Tomcat을 download 받고 /opt/tomcat에 풀어 준다.

 

사용자 설정

/opt/tomcat/conf/tomcat-users.xml 파일을 편집해서 다음과 같이 Tomcat user를 추가해 준다. 아래의 설정은 가장 단순하게 access control하기 위한 설정으로 ‘tomcat’이라는 id를 추가하기 위한 것이다.

 

결과확인

모든 설정이 끝났다면 Tomcat을 설치한 머신에서  http://localhost:8080/manager/html 주소에 접근해서 Tomcat 서버 설정을 관리 할 수 있다. ID와 password를 묻는 prompt가 뜨면 위의 tomcat-users.xml에서 설정한것 처럼 ID/비밀번호(tomcat/비밀번호(password)를 입력한다.

SC_tomcat_manage_html

 

Remote Access 허가

Tomcat 관리자 page를 접근할 때 localhost가 아닌 remote에서 접속을 시도하면 403 access denied 오류가 뜰 수 있다. Localhost외에서도 tomcat 관리자 page 접근을 허용하려면 아래 경로에 있는 context.xml file의 allow= 부분을 수정해서 모든 IP를 받아들이도록 변경해 주면된다. context.xml은 여러개 있으니 경로에 주의.

/opt/tomcat/webapps/manager/META-INF/context.xml

 

Firewall 바깥의 git을 clone하기

Firewall등이 막고 있어서 외부의 git repository를 HTTPS로는 clone할 수 있지만 SSH로는 막히는 경우가 있다. 특히나 GitHub의 two-factor authentication을 설정한 경우라면 매번 token값을 입력하는 것 때문에 commit을 push하는게 매우 귀찮아진다.

이 문제는 ssh config file에 Proxy command를 설정해서 해결할 수 있는데
${HOME}/.ssh/config에 다음과 같이 추가해 주고, (-S option에는 SOCKS port를 설정해야 한다)

credential caching을 설정해 준다.

Travis CI 설정과 docker image 사용

GitHub project에 CI를 붙이고 싶은데 Jenkins server가 회사 firewall 안에 들어 있어서 GitHub에서 직접 webhook을 붙일 수 없는 문제가 있다. Jenkins의 GitHub plugin으로 tunneling을 설정하는 방법 등 있기는 하지만 다른 CI 옵션들을 살펴 보던중 Open source project에 대해서는 무료라는 Travis CI가 있다는 것을 알게 되었다. Travis CI는 기본으로 Ubuntu를 지원하고 그 외의 경우는 docker를 사용해서 환경을 설정할 수도 있다. 이 포스팅은 Travis CI에서 ClearLinux docker를 사용한 설정에 대한 기록이다.

 

삽질1: Travis CI의 Ubuntu이용

빌드와 Google test를 이용한 unittest만 할 것이니까 OS를 크게 타지 않을테니 기본으로 제공되는 Ubuntu 환경에 필요한 도구들만 설치 하면 가장 빠르지 않을까?

일견 타당해 보이기는 하지만 문제는 의존성이다. Pre-compile된 Google test를 download 받는다 해도, 2019년 1월 현재 아직 Travis CI에서 제공하는 Ubuntu의 가장 최신 버전은 Xenial이다. CMake version이 안맞아서 최신버전으로 설치하고 Intel LibVA, Intel MediaSDK등의 의존 package들을 컴파일한 후 빌드를 하고 unittest를 하도록 하는데 14분이 넘게 걸렸다. 다음은 사용한 .travis.yml file이다.

 

삽질2: Clear Linux docker image 사용

시간만 오래 안 걸렸어도 기본 Ubuntu OS로 어떻게든 해보는 건데, 14분이면 시간이 너무 오래 걸린다. 이왕 시간이 오래 걸리는 거라면 Clear Linux docker docker image를 사용해보자.

Clear Linux docker image를 생성하기 위한 dockerfile을 다음과 같이 작성해준 다음

.travis.yml file을 다음과 같이 선언해 준다.

총 소요된 시간은 17분 41초 그 중에 docker 설정하는데 걸린 시간만 16분이 넘는다. 나머지 시간은 unittest… 즉 대부분의 시간이 docker를 빌드 하고 설정하는데 사용 되고 있었다.

 

삽질3: Docker image download

빌드하는데 시간이 오래 걸린다면 이미 만들어 둔 docker image를 저장소에 넣어두고 pull해서 사용하면 좀 빠르지 않을까? Docker 빌드 vs Docker 다운로드.

이미 빌드 한 docker image를 공개 저장소인 docker hub에 넣어두고 Travis CI에서 pull하도록 변경하면 시간은 8분정도로 줄어든다.

흠.. 8분이면 그나마 그럭저럭 쓸만 하군.

 

결론

Travis CI는 머리는 나쁘고 손발은 빠르다. Docker를 이용해서 테스트 하려면 매번 새롭게 빌드하기 보다 Docker Hub에 올려두고 pull 하는 방법을 고려해 볼만 하다.