도커는 주로 우분투(리눅스)에서 사용하고 있다. 그래야 제대로된 성능이 나오기 때문이다.

그런데, 개발/테스트 등을 위해 맥os 에서 사용하고자 한다.

설치는 쉽다. https://www.docker.com/products/docker-desktop 에서 다운로드 후 설치하면 된다.

도커를 실행하면, 로그인은 꼭 필수는 아니다.(본인의 도커 이미지등을 docker hub에 등록하고자 하면 필요)
그냥 로컬에서 실행/테스트 할때는 굳이 필요없다.

끝.

도커를 연습해 보고자 한다면, https://docs.docker.com/get-started/ 를 참조한다.

도커 데스크탑 이 쿠버네티스도 지원하는 듯 하다. 설정을 해봤다. 쓸만한 지는 체크해봐야겠다.

간단한 golang 어플을 도커 이미지를 사용해서 배포하려 한다.(배포는 kubernetes 를 사용한다)

docker hub 등 온라인 방식으로 해도 되지만, microk8s 의 registry 서비스를 이용한다.
방법은 그리 어렵지 않다.  https://microk8s.io/docs/registry-built-in 를 참조 한다.

일종의 registry 서비스를 로컬에 가동하여 도커 이미지를 등록 하는 것이다.

1. 이미지 빌드

$ sudo docker build . -t localhost:32000/prod-api:registry

Sending build context to Docker daemon  4.608kB
Step 1/6 : FROM golang:latest
latest: Pulling from library/golang
dc65f448a2e2: Pull complete 
346ffb2b67d7: Pull complete 
dea4ecac934f: Pull complete 
8ac92ddf84b3: Pull complete 
7ca605383307: Pull complete 
f47e6cebc512: Pull complete 
530350156010: Pull complete 
Digest: sha256:fe6b1742d48c4d6d360c6fac1e289e8529aaab924fa0e49a330868be50c0f2f4
Status: Downloaded newer image for golang:latest
 ---> 297e5bf50f50
Step 2/6 : RUN mkdir /app
 ---> Running in 2a6795d86353
Removing intermediate container 2a6795d86353
 ---> 541dbb10344e
Step 3/6 : ADD . /app/
 ---> c60e6e741cb4
Step 4/6 : WORKDIR /app
 ---> Running in 5de0b590c65d
Removing intermediate container 5de0b590c65d
 ---> 24c7788d1b8e
Step 5/6 : RUN go build -o main .
 ---> Running in 5e44a7f53909
Removing intermediate container 5e44a7f53909
 ---> 56462a496eac
Step 6/6 : CMD ["/app/main"]
 ---> Running in bdde4584ff89
Removing intermediate container bdde4584ff89
 ---> dbba71be4f83
Successfully built dbba71be4f83
Successfully tagged localhost:32000/prod-api:registry

등록체크 

$ sudo docker images

REPOSITORY                 TAG                 IMAGE ID            CREATED             SIZE
localhost:32000/prod-api   registry            dbba71be4f83        5 minutes ago       810MB

2. 이미지 registry 등록

$ sudo docker push localhost:32000/prod-api

The push refers to repository [localhost:32000/prod-api]
44006ff06569: Pushed 
203febf79d4f: Pushed 
2ec821486852: Pushed 
cae11887bc90: Pushed 
729c3ac48990: Pushed 
8378cd889737: Pushed 
5c813a85f7f0: Pushed 
bdca38f94ff0: Pushed 
faac394a1ad3: Pushed 
ce8168f12337: Pushed 
registry: digest: sha256:7c8fe99287f680f23e611c4113834c5c8343aa102a49a3584a65888205604609 size: 2420

3. kubernetes 로 배포

배포코드는 https://github.com/yusufkaratoprak/kubernetes-gosample 를 참조

$ vi config/deploy.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: prod-api-dep
spec:
  replicas: 1
  selector:
    matchLabels:
      app: prod-api
  template:
    metadata:
      name: prod-api
      labels:
        app: prod-api
    spec:
      containers:
      - name: prod-api-dep
        image: localhost:32000/prod-api:registry
        ports:
        - containerPort: 8090

$ vi config/service.yaml

apiVersion: v1
kind: Service
metadata:
  name: prod-api-service
spec:
  selector:
    app: prod-api
  ports:
    - name: http
      protocol: TCP
      port: 8070
      targetPort: 8090
  externalIPs:
    - 192.168.0.111

배포/가동 : kubectl apply -f config/

$ curl 192.168.0.111:8070  으로 체크

추후 LoadBalance 로 설정 - golang 파드는  replicas 로 여러대로 동작

btrfs 를 쓰고 있는데, 뭔가 이상하다.

내가 잘못 쓰고 있는 것인지?

오늘 생긴일은 다음과 같다.

40G 정도 되는 파일을 원격지에서 전송받는 것이었다.

btrfs 를 쓰고있는 파티션이 80G 정도 남아있어서 괜찮겠다 싶어 전송하였다.

그런데, 30기가 정도 받고 나니 시스템이 다운된다.

이유가 뭘까?

혹시나 네트웍디바이스가 무리가 간것인가 다시 해봐도 동일현상.

그냥 ext4 의 다른 파티션으로 해보니 정상적이다.

btrfs 의 뭔가 특성이 있는 것인가?

커널로그를 살펴봤다.

다음과 같은 메시지가 눈에 띈다.

df 로 확인한 용량과 BTRFS 의 용량계산은 차이가 있는 것인가?

아직 잘 모르겠다.

docker 쪽이 btrfs 를 쓰는듯 한데, 특성을 찾아봐야 겠다.

요즘 서버 자동화에 대한 구상을 하고 있다.

여러가지 방법이 있어 상황에 맞는 좋은 방법을 찾고 있다.

docker / vagrant / chef / puppet 등을 체크하고 있다.

관리해야 하는 서버가 수십대 규모에서 수백대 규모로 넘어가는 상황에서는 수작업/스크립트 만으로는 처리가 어렵다. 미리 미리 체크해서 상황이 발생했을 때 빠른 대처를 할 생각이다.

# digital ocean 의 서비스를 활용.

서비스쪽에서는 amazon 이 최고이긴 하지만, 비용문제가 있다. 계산법 복잡한 부분도 있다.
설정 부분도 그렇고, 초보가 접근하기에는 좀 부담스럽다.

디지털오션은 그 부분에서 간략화되어 있다는 느낌이다.

디지털오션 서비스를 체험하려면 관련글을 참조(2개월무료사용글 => http://blog.1day1.org/498 )

droplet 까지 생성을 해봤다면 다음으로 넘어가보자.

미리 세팅한(OS + your service app) droplet 를 스냅샷(snapshot)으로 만들 수 있다.

기본으로는 해당 지역(San Francisco) 에 생성이 되는데, 다른 지역에도 같은 이미지를 배포하고 싶으면 다른 지역으로 전송할 수 있다. 전송하는 시간이 좀 길다. 20G 정도 밖에 안되는데, 꽤 오랜 시간이 걸린다.
미리 미리 타지역으로 배포를 해놓는 것이 좋다.( 이 시간 때문에 다른 서비스도 고려중이다)

일단 스냅샷을 만든후

# droplet 을 저장이미지를 사용해본다.

  지역을 선택하고 My Images 에 저장된 이미지가 보인다. 그것을 선택한다.
  SSH Key 도 미리 등록해 놓으면 로그인도 바로 할 수 있으니 편하다.

기존에 droplet 생성 -> 서비스 app 세팅 하는데, 스크립트를 이용해서 보통 20~30 / 테스트까지 하면 1시간정도 필요했었다. 그런데, 이미지를 이용하면 거의 5분이내로 서비스 가동이 완료된다. 무지 편해졌다.
서비스 배포 시간을 줄이며 그 만큼 빠른 대응을 할 수 있다.

디지털오션쪽에서는 API 도 제공하기 때문에 위 시간에서 더 줄일 수 있을 듯 하다.
(https://developers.digitalocean.com)

내가 한 방법이 최상이라고는 할 수 없다. 서비스 앱의 종류 / 복잡도에 따라 또 달라질 수 있다.

설정등이 서버마다 바뀌거나, 복잡한 부분은 chef 나 puppet 등을 사용해야 할 것이다.

처음에는 간단한 것부터 조금씩 복잡한 부분에 대한 자동화시스템을 구축해볼 예정이다.

우분투 14.04 시스템에 btrfs 를 사용하고 있다.

SSD raid 에 LVM 으로 나눠서 쓰고 있다. 일반적인 사용형태보다는 좀 복잡할 것이다.
(물론 아주 특이한 케이스는 아니다)

docker 를 테스트 하던 중.

docker pull 로  이미지 몇개 설치하지 않았는데, 디스크가 꽉차는 현상이 발생했다.
크롬이 비정상 종료되길래 왜 그러지 싶었다. 그냥 아무 생각없이 재부팅하니. 정상부팅되지 않았다.

순간 멘붕.

허걱! 다시 OS를 깔아야 하나. 데이터 만이라도 살려야 하는데.
중요데이터는 Dropbox 로 동기화 하고 있으니 별 상관은 없지만, 또 세팅을 다시하려니 힘이 쭉.

single 모드로 다시 부팅을 해보고 점검을 해봤다.

주요 메시지는

이런식의 메시지가 계속 무한루프 된다. 위 메시지를 검색 해봤는데, 별다른 원인을 못찾겠다.

docker 를 테스트 하던중 용량 관련 메시지 No space left on device  => 디스크 full 일때 나오는 익숙한(?) 메시지
를 봤었다. 그것과 관련이 있을 것 같다.

그러나 시스템 용량은 충분했다. 어떤 다른 이유인것 같다.

docker pull dockerfile/mongodb

등의 명령을 내리면, 이미지를 다운로드하고 컨테이너를 생성한다.

이때 docker 는 btrfs 인 경우 subvolume (스냅샷?) 기능 을 이용하는 것 같다.

/var/lib/docker/btrfs/subvolumes 에 생성이 된다.

을 해보면 아무것도 없어야 한다. 그런데, docker pull 후에 다시 명령을 해보면.

위 처럼 많은 subvolume 이 생성된 것을 볼 수 있다.
ID 값이 동일한 것(진한부분)을 보니 ID 당 서브볼륨을 생성해서 관리하나 보다.

파일용량을 체크해보면 다음과 같다.

서브볼륨은 어느 부분에 영향을 주는지 확인해봐야 겠다.

아무튼.

명령으로 docker 이미지를 삭제하면 해당 subvolume 도 삭제된다.

개별적으로 subvolume 을 삭제하려면

으로 삭제해준다.( 부팅이 안되서 usb 우분투 로 부팅하고, 해당 서브볼륨을 위 처럼 하나씩 삭제해줬다)

btrfs 에 좀더 알기전까지는 조심해야 겠다.

다음부터 docker 는 vagrant 기반의 vm 내에서 테스트 해봐야 겠다.

docker 를 어떻게 하면 잘 활용할 수 있을까?

여러가지 방향을 생각해본다.

vagrant 와는 다르게 linux 전용이라 구성에 제약이 따른다.

1. 최대의 성능.

  [필요사항] 배포용 머신이 팀 또는 개인이 보유하고 있어야 한다.

  [장점] linux 머신에 docker 를 바로 세팅해서 최대 성능을 낸다.
  [단점] 리눅스 환경의 개발PC 가 아니면 원격으로 접속해서 개발해야 한다.

2. 관리의 편의.

  [장점] 개발PC 의 OS 에 상관없이 개발환경을 세팅가능하다.(win / mac)
  [단점] vagrant(vm) 을 활용하기 때문에 성능저하가 있다.

# 개발이 완료된 후 서비스용 설정

기본 구성은 다음과 같이 하려 한다.

서비스서버 를 AWS / DigitalOcean / GoogleCloud 등의 가상서버로 세팅해도 되고, 서버호스팅의 리얼서버를 이용해도 된다.

클라우드는 성능저하가 있겠지만, 빠른배포 와 편의성을 잘 따져보고 결정하면 되겠다.

충분한 테스트를 해보고 결정하는 것이 좋겠다.

디지털오션쪽에 2개월정도 무료사용가능하니 먼저 테스트해봐야 겠다.
(512M 짜리 * 2개 => 1개월 , 4개 => 2주? , 8개 => 1주일정도? )

(무료 사용은 => 링크 참조)

테스트 해보고 사용해도 되겠다 판단이 되면, Core 를 늘려서 서비스용으로 활용해도 되겠다.

# 서비스 시나리오.

서비스용으로 10대의 클라우드 서버에 배포하는 시나리오를 만들고 테스트 해봐야 겠다.

그러고 보니 docker 모니터링툴도 필요하겠다. (관련 자료도 찾아봐야 겠네)

자동화에 필요한 사항은 다양한 시나리오 사례가 만들어지면, 재미있을 것 같다.

docker 를 우분투에 설치해봤다. 이제 기본 컨테이너 환경을 구성해보자.

- Centos 를 테스트로 구성해본다.

를 해보면, centos 관련 저장소에 있는 이미지들의 리스트를 보여준다.(무지 많다.)

- 아래 처럼 리스트가 많이 나온다. (docker hub 에 등록된 이미지 인듯함)

- 맨 위의 공식 이미지로 해보자.

- 다음처럼 이미지를 다운받는 화면을 볼 수 있다.

- 완료가 되면 docker 컨테이너 환경으로 들어가 본다.

기본 호스트로 사용하고 있는 구조와 다르다. ubuntu 안에 centos 의 가상환경을 만들어 준것이다.

- 설치된 이미지를 확인해본다.

다음 처럼 로컬에 설치한 이미지들을 볼 수 있다.

참조 : http://blog.nacyot.com/articles/2014-01-27-easy-deploy-with-docker/

docker 를 설치해본다.

우분투 14.04 에서는 간편하다. 이미 우분투 공식패키지로 등록이 되어 있다.

그러나 공식패키지는 버전업이 느리다.

# docker.io --version

빠르게 버전업하는 패키지는 공식사이트의 배포버전을 사용하면 좋다.

한번에 끝내기

위 스크립트를 받아서 실행하는 방법이다.

최신버전으로 설치된다.

간단한 테스트.

다음과 같은 명령을 내리면.. 로컬이미지를 찾고,
없으면 저장소에서 찾아서 설치한 후 echo 'Hello World' 를 실행하게 된다.

하위 버전은 다음을 참조.

http://docs.docker.io.s3-website-us-west-2.amazonaws.com/installation/ubuntulinux/