무제

Life & Culture/생각지도 2015/02/26 11:09 posted by k16wire

자기 생각에 확신을 가지고 이야기하는 사람이 많아질수록

세상은 바뀐다고 믿는다.


저작자 표시 비영리 변경 금지

'Life & Culture > 생각지도' 카테고리의 다른 글

무제  (0) 2015/02/26
가장 어려운 문제와 가장 쉬운문제  (0) 2015/02/03
DevOps 엔지니어의 행복한 하루  (0) 2015/01/21
유리감옥  (0) 2014/12/31
읽는 힘과 듣는 힘  (0) 2014/12/24
아이작 아시모프의 1959년 창조적 사고에 대한 에세이  (0) 2014/11/04

도커가 가벼운 가상화 기술이라고 흔히 말합니다만 도커 이미지 크기도 관리하지 않으면 야금야금 늘어나는걸 흔히 볼수 있습니다. 관련 내용이 몇가지 있어서 같이 정리해봤습니다.


가벼운 베이스 이미지를 사용한다.

이미지를 만들때 가능한 크기가 작은 베이스 이미지를 사용합니다.

$ docker images
REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZE
scratch latest 511136ea3c5a 13 months ago 0 B
busybox latest a9eb17255234 7 weeks ago 2.433 MB
debian latest e8d37d9e3476 4 days ago 85.18 MB
ubuntu latest ba5877dc9bec 4 days ago 192.7 MB
centos latest 1a7dc42f78ba 2 weeks ago 236.4 MB
fedora latest 88b42ffd1f7c 10 days ago 373.7 MB


이 외에도 tinycore 리눅스는 19M 정도 작은 용량이어서 가능하다면 좋은 대안이 될수 있을거 같습니다.


Dockerfile 명령을 체인으로 사용한다.

Dockerfile에서 RUN 명령을 개별로 실행하게 되면 실행이 끝날때 마다 중간 이미지가 만들어집니다. 하지만 체인으로 명령을 실행하면 한개만 만들어지기 때문에 크기가 줄어듭니다.


개별적으로 실행하는 경우

RUN wget -nv
RUN tar -xvf someutility-v1.0.0.tar.gz
RUN mv /tmp/someutility-v1.0.0/someutil /usr/bin/someutil


체인으로 실행하는 경우

RUN wget -nv &&
tar -xvf someutility-v1.0.0.tar.gz &&
mv /tmp/someutility-v1.0.0/someutil /usr/bin/someutil


중간 이미지를 하나로 합친다.

도커 이미지는 여러개의 중간 이미지의 합으로 최종 이미지가 만들어집니다. 이 중간 이미지들은 Dockerfile로 이미지를 만들때는 유용하지만 이미 만들어진 이미지를 사용할때는 별로 필요없습니다. 그럼 이런 이미지를 하나로 합치면 이미지 크기가 줄어듭니다. 이미지를 sample 이라는 이름의 컨테이너로 실행했다면

docker export sample | docker import - sample:flat


빌드 도구를 설치하지 않는다.

꼭 필요한 경우가 아니라면 소스를 빌드해서 이미지에 넣으면 불필요한 빌드 도구가 차지하는 공간을 줄일수 있습니다.


패키지 관리자를 정리한다.

apt-get 을 실행했다면 마지막에 apt-get clean을 적어줍니다. /var/cache/apt/archives 디렉토리에 있는 다운로드 파일을 지워줍니다. 패키지 리스트 파일도 지우는것도 권장합니다.[2] apt-get은 /var/lib/apt/lists 디렉토리를 지우면 됩니다.



참고자료

[1] http://www.centurylinklabs.com/optimizing-docker-images/

[2] https://dayone.me/1740z5r



저작자 표시 비영리 변경 금지

Docker로 만드는 냐옹냐옹

Work & Study/TechTalk 2015/02/06 12:37 posted by k16wire

아래 컨테이너를 실행하면 뭐가 나올까요.

docker run -it supertest2014/nyan


아래와 같은 달리는 고양이 애니메이션을 볼수 있습니다. ㅎ





저작자 표시 비영리 변경 금지

세상일에서 사람으로 해결해야 하는 것이 가장 어려운 문제다. 이는 제 아무리 돈이 많아도 해결할 수 없으며, 진정한 사람은 돈으로 얻을 수도 없다. 

반면 세상일에서 돈으로 해결할 수 있는 것이 가장 쉬운 문제다. 이는 별다른 노력을 하지 않아도 되고, 고민과 갈등도 필요없다.


- 장하성 한국 자본주의 중에서 - 


저작자 표시 비영리 변경 금지

'Life & Culture > 생각지도' 카테고리의 다른 글

무제  (0) 2015/02/26
가장 어려운 문제와 가장 쉬운문제  (0) 2015/02/03
DevOps 엔지니어의 행복한 하루  (0) 2015/01/21
유리감옥  (0) 2014/12/31
읽는 힘과 듣는 힘  (0) 2014/12/24
아이작 아시모프의 1959년 창조적 사고에 대한 에세이  (0) 2014/11/04

Beyond the Universe

Life & Culture/일상다반사 2015/01/31 22:42 posted by k16wire

작년 한해동안 진행했던 일 하나가 끝났습니다. 

이제 숨을 고르고 2단계를 향해 달려가야 합니다. 험난한 일들이 많을거라 예상되지만 즐겁네요.

신난다. ㅎ 



저작자 표시 비영리 변경 금지

Docker에서 중요한 개념이 이미지와 컨테이너입니다. 컨테이너는 이미지를 실행한 상태라고 많이 설명합니다. 이 컨테이너중에 데이터 볼륨 컨테이너라는 유형이 있는데 이에 대한 이야기를 해보겠습니다.


Docker 호스트에 있는 특정 디렉토리를 Docker 컨테이너에 공유하고 싶다면 VOLUME을 사용합니다. Dockerfile에 VOLUME을 설정해보겠습니다.


FROM ubuntu:14.04

MAINTAINER scott hwang("k16wire@gmail.com")

VOLUME ["/opt/project/webapp", "/data"]


이 Dockerfile 이미지로(k16wire/ubuntu) 컨테이너를 만들면 '/opt/project', '/data' 디렉토리가 컨테이너에 만들어집니다. 컨테이너에 만들어진 디렉토리와 호스트에 있는 디렉토리를 바인딩 시키는건 컨테이너를 실행할때 합니다. 

docker run -d -P --name datacontainer -v src/webapp:/opt/project/webapp k16wire/ubuntu


 VOLUME을 명시하지 않고 -v 로 바인딩하면 어떻게 될까요? 바인딩 됩니다. 단 바인딩하려는 디렉토리가 반드시 존재해야 에러없이 컨테이너가 실행됩니다.


컨테이너가 하나 더 있다고 해보겠습니다. 이 컨테이너 역시 호스트에 있는 src/webapp 디렉토리를 공유하고 싶습니다. 그럼 앞에서 사용한 -v 옵션을 이용하면 됩니다. 

docker run -d -P --name web -v src/webapp:/opt/webapp nginx

하지만 이렇게 하지않고 앞에서 만든 컨테이너를 활용할수도 있습니다.

docker run -d -P --name web --volumes-from datacontainer nginx

후자처럼 컨테이너를 실행한다고 했을때 VOLUME을 공유하는 컨테이너를 데이터 볼륨 컨테이너라고 부릅니다. 그럼 데이터 볼륨 컨테이너를 쓰는것과 -v로 직접 디렉토리를 공유하는게 어떤 차이가 있을까요. 결과만 놓고 본다면 다르지 않습니다만 컨테이너 구성면에서 변화가 생깁니다.


-v 옵션으로 공유를 추가하는것은 컨테이너와 호스트간에 연결을 맺는것이지만 데이터 볼륨 컨테이너를 사용하면 컨테이너와 컨테이너간의 연결로 바뀝니다.(궁극적으로는 데이터볼륨컨테이너를 거쳐 호스트와 연결이 되는것이죠.) 호스트가 공유하고 싶은 데이터(여기서는 디렉토리)를 논리적인 단위로 추상화 시켰다고 볼수도 있습니다. 꼭 Symbolic Link를 만들어서 사용하고 물리적인 실제 경로는 숨기는것과 유사해보입니다.

Microservice 아키텍처로 본다면 컨테이너는 서비스에 해당하며 서비스는 특정 행위를 책임집니다. 데이터 볼륨 컨테이너는 데이터 공유라는 행위를 책임지는 서비스인 셈입니다. 이렇게 행위에 대한 역할이 명확해 지기 때문에 데이터 볼륨 컨테이너가 필요합니다. 


참고자료

[1] https://docs.docker.com/userguide/dockervolumes/#creating-and-mounting-a-data-volume-container

[2] https://medium.com/@ramangupta/why-docker-data-containers-are-good-589b3c6c749e

[3] http://stackoverflow.com/questions/18496940/how-to-deal-with-persistent-storage-e-g-databases-in-docker/20652410#20652410

[4] http://www.offermann.us/2013/12/tiny-docker-pieces-loosely-joined.html

[5] http://crosbymichael.com/advanced-docker-volumes.html


저작자 표시 비영리 변경 금지

닷 클라우드 솔로몬 하이크(Solomon Hykes)가 내부적으로 개발하던 Docker를 Pycon2013에서 처음 공개했던 영상입니다.


The Future of Docker Container

http://www.youtube.com/watch?v=wW9CAH9nSLs

5분밖에 안되는 발표지만 지금 보면 정말 충격적인 내용을 선보인겁니다. 저기 앉아 있는 사람들은 복받았네요. Hello World를 찍는 새로운 방법으로 추가할만 합니다.


위 데모중 Hello World 찍는 부분을 다시 재 구성한 영상도 있습니다.

http://www.youtube.com/watch?v=w4jfLy633xM





저작자 표시 비영리 변경 금지



개발자 꾸뻬씨는 이번주까지 마무리 해야 하는 일이 몇가지 있는데 한가지도 쉬운일이 아니어서 아침부터 한숨만 나옵니다. 가장 급한건 신규 프로젝트를 위한 개발서버와 스테이징 서버 준비입니다. 이게 빨리 준비 안되면 어렵게 모인 개발팀과 파트너사 직원들이 개발을 시작할수 없기 때문이죠.

그 다음은 지난주 발생한 장애건에 대해 팀장님이 지시한 재발방지 대책 마련입니다. 1급장애 상황이라 일단 서버 재시작으로 정상화는 시켰지만 정확한 원인을 찾으려면 동일한 상황을 재현해야 합니다. 그런데 운영서버도 빠듯한 상황에 서버를 내려서 테스트하겠다면 사업부서가 가만있지 않을거 같아 걱정입니다.

마지막은 신규로 도입하려는 게이트웨이 서버에 대한 검증작업입니다. 제대로 테스트하려면 적어도 서버를 종류별로 따로 받아서 설치해서 실행해 놓고 다양한 시나리오로 테스트해야 하는데 설치는 고사하고 아직 서버도 받지 못한 상황입니다.


Docker기반의 DevOps 인프라가 있다면 위에서 언급한 업무는 어려운 일이 아닙니다. 미리 준비된 이미지를 이용하면 개발과 스테이징 환경을 위한 컨테이너를 만드는 작업은 몇번의 클릭으로 끝납니다. 컨테이너는 바로 만들어져 제공되기 때문에 기다릴 필요가 없습니다. 

운영중인 컨테이너가 문제를 일으키면 미리 커밋해둔 컨테이너 이미지를 이용해 바로 동일한 컨테이너를 몇분만에 만들어 대체할수 있습니다. 문제를 일으킨 컨테이너는 멈춘채 그대로 아카이브했다가 나중에 다시 실행해서 왜 장애가 발생했는지 확인하는데 사용합니다.

원하는 이미지가 없다면 필요한 SW가 설치된 이미지를 요청해서 받을수 있습니다. 검증후에는 따로 반납할 필요없고 데이터만 백업받고 바로 지워버릴수 있어 편리합니다.


DevOps 인프라는 개발자 꾸뻬씨가 행복한 하루를 보낼수 있게 해줄겁니다.

저작자 표시 비영리 변경 금지

'Life & Culture > 생각지도' 카테고리의 다른 글

무제  (0) 2015/02/26
가장 어려운 문제와 가장 쉬운문제  (0) 2015/02/03
DevOps 엔지니어의 행복한 하루  (0) 2015/01/21
유리감옥  (0) 2014/12/31
읽는 힘과 듣는 힘  (0) 2014/12/24
아이작 아시모프의 1959년 창조적 사고에 대한 에세이  (0) 2014/11/04