간단한 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 로 여러대로 동작

 


WRITTEN BY
1day1
하루하루 즐거운일 하나씩, 행복한일 하나씩 만들어 가요.

트랙백  0 , 댓글  0개가 달렸습니다.
secret

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

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

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

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

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

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

이유가 뭘까?

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

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

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

커널로그를 살펴봤다.

 BTRFS error (device dm-6): block group 117604089856 has wrong amount of free space
 BTRFS error (device dm-6): failed to load free space cache for block group 117604089856

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

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



아직 잘 모르겠다.

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



WRITTEN BY
1day1
하루하루 즐거운일 하나씩, 행복한일 하나씩 만들어 가요.

트랙백  0 , 댓글  1개가 달렸습니다.
  1. 안녕하세요! 해당 증상은 블록 그룹에 대한 여유 공간 캐시가 재할당 등으로 인해 적재되지 못한 경우로 보여지며, 마운트 옵션으로 clear_cache를 주고 재부팅 혹은 재부착하시면 될 것으로 보입니다~!
secret

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

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

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 등을 사용해야 할 것이다.

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





WRITTEN BY
1day1
하루하루 즐거운일 하나씩, 행복한일 하나씩 만들어 가요.

트랙백  0 , 댓글  0개가 달렸습니다.
secret

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

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

docker 를 테스트 하던 중.

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

순간 멘붕.

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

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

주요 메시지는

Incrementally starting RAID arrays...
mdadm: CREATE user root not found
mdadm: CREATE group root not found
Incrementally started RAID arrays.

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


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

# df -h
Filesystem                   Size  Used Avail Use% Mounted on
/dev/mapper/vg_root-lv_root  131G   46G   84G  36% /
none                         4.0K     0  4.0K   0% /sys/fs/cgroup
udev                         3.9G  4.0K  3.9G   1% /dev
tmpfs                        791M  1.3M  789M   1% /run
none                         5.0M     0  5.0M   0% /run/lock
none                         3.9G  156K  3.9G   1% /run/shm
none                         100M   44K  100M   1% /run/user

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


docker pull dockerfile/mongodb

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

# docker pull dockerfile/mongodb
Pulling repository dockerfile/mongodb
6c03df111896: Download complete
511136ea3c5a: Download complete
5e66087f3ffe: Download complete
4d26dd3ebc1c: Download complete
d4010efcfd86: Download complete
99ec81b80c55: Download complete
b261bc65cd23: Download complete
42404685406e: Download complete
6cc69450fe19: Download complete
efc4fbcd007f: Download complete
2baeb2edbf92: Download complete
ecd5c1cc18ac: Download complete
1f089cc15e82: Download complete
9c1219bb985c: Download complete
d5885db18d17: Download complete
f1b2b4374c6b: Download complete
c0cda6b780cd: Download complete
42f2a60d100f: Download complete

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

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

btrfs subvolume list /

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

# btrfs sub list /
ID 386 gen 94278 top level 5 path var/lib/docker/btrfs/subvolumes/511136ea3c5a64f264b78b5433614aec563103b4d4702f3ba7d4d2698e22c158
ID 387 gen 94278 top level 5 path var/lib/docker/btrfs/subvolumes/5e66087f3ffe002664507d225d07b6929843c3f0299f5335a70c1727c8833737
ID 388 gen 94279 top level 5 path var/lib/docker/btrfs/subvolumes/4d26dd3ebc1c823cfa652280eca0230ec411fb6a742983803e49e051fe367efe
ID 389 gen 94280 top level 5 path var/lib/docker/btrfs/subvolumes/d4010efcfd86c7f59f6b83b90e9c66d4cc4d78cd2266e853b95d464ea0eb73e6
ID 390 gen 94281 top level 5 path var/lib/docker/btrfs/subvolumes/99ec81b80c55d906afd8179560fdab0ee93e32c52053816ca1d531597c1ff48f
ID 391 gen 94282 top level 5 path var/lib/docker/btrfs/subvolumes/b261bc65cd23e8399c39ef0b77d732ddf6ca9679d4cea0ad1cdaca715c4a0d81
ID 392 gen 94283 top level 5 path var/lib/docker/btrfs/subvolumes/42404685406e72d29e3b349605d34cb88590cfcfabb06b9925628f2949c2eb89
ID 393 gen 94284 top level 5 path var/lib/docker/btrfs/subvolumes/6cc69450fe1990579c13d444495dcfec342955712481647fcb73d5a8e6184f33
ID 394 gen 94285 top level 5 path var/lib/docker/btrfs/subvolumes/efc4fbcd007ff7a202ead05932a48f62301464b8f1bc1449f3a8f9b5c26d9515
ID 395 gen 94286 top level 5 path var/lib/docker/btrfs/subvolumes/2baeb2edbf92488d7bbd4723368aeb2e86045f7ed6310b5924cec2d3c3ff8710
ID 396 gen 94287 top level 5 path var/lib/docker/btrfs/subvolumes/ecd5c1cc18ac86e88dd6420161d5812ef6cd31c1a0ce252d071d4481996502fc
ID 397 gen 94288 top level 5 path var/lib/docker/btrfs/subvolumes/1f089cc15e82571690524c3633dc361ba526d25fed072e09607fac7ee1178098
ID 398 gen 94289 top level 5 path var/lib/docker/btrfs/subvolumes/9c1219bb985cb5ceb0a602ad943c9dd5b83cf0f16d3cd05730113fe0af37d0be
ID 399 gen 94290 top level 5 path var/lib/docker/btrfs/subvolumes/d5885db18d17c3e473f310ab7723a1c6b4c29a14b9a8db54bfd795466bee1da3
ID 400 gen 94291 top level 5 path var/lib/docker/btrfs/subvolumes/f1b2b4374c6b1813549a4436c190f4e0ab04168eee3244e08931b63c96b943c1
ID 401 gen 94292 top level 5 path var/lib/docker/btrfs/subvolumes/c0cda6b780cdb2c400b470371baea2149ac4caef980d4685465f0ef13eb2af6c
ID 402 gen 94293 top level 5 path var/lib/docker/btrfs/subvolumes/42f2a60d100fcbda388b76bb69270fc057565ab4bdf5d68072b30b225669e5f4
ID 403 gen 94293 top level 5 path var/lib/docker/btrfs/subvolumes/6c03df11189668e549ac34464dbdbef563144f92eeb89246afaa1029b92cfd7d

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


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

# btrfs file df /
Data, single: total=127.21GiB, used=44.64GiB
System, DUP: total=8.00MiB, used=20.00KiB
System, single: total=4.00MiB, used=0.00
Metadata, DUP: total=1.50GiB, used=1.02GiB
Metadata, single: total=8.00MiB, used=0.00

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

아무튼.

docker rmi dockerfile/mongodb

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


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

btrfs sub del var/lib/docker/btrfs/subvolumes/6c03df11189668e549ac34464dbdbef563144f92eeb89246afaa1029b92cfd7d

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


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

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




WRITTEN BY
1day1
하루하루 즐거운일 하나씩, 행복한일 하나씩 만들어 가요.

트랙백  0 , 댓글  0개가 달렸습니다.
secret

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

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

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


1. 최대의 성능.

배포용 : 개발머신(linux / docker 호스트)  => docker 이미지

개발용 : 개발PC(win/mac/linux) => 개발환경(linux / docker) + docker pull  <= 배포 이미지

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

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


2. 관리의 편의.

배포용 : 개발머신(docker 호스트)  => docker 이미지

개발용 : 개발PC+개발환경[ vagrant (docker) ] + docker pull  <= 배포 이미지

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



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

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

서비스서버(docker) + docker pull  <= 배포이미지

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

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

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


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


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

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


# 서비스 시나리오.

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

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


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



WRITTEN BY
1day1
하루하루 즐거운일 하나씩, 행복한일 하나씩 만들어 가요.

트랙백  0 , 댓글  0개가 달렸습니다.
secret

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

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

docker search centos

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

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

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

docker pull centos

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


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

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


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

# docker images

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

REPOSITORY          TAG                 IMAGE ID            CREATED             VIRTUAL SIZE
ubuntu              14.04               e54ca5efa2e9        2 days ago          276.1 MB
centos              centos6             0c752394b855        11 days ago         124.1 MB
centos              latest              0c752394b855        11 days ago         124.1 MB
centos              6.4                 539c0211cd76        14 months ago       300.6 MB



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



WRITTEN BY
1day1
하루하루 즐거운일 하나씩, 행복한일 하나씩 만들어 가요.

트랙백  0 , 댓글  0개가 달렸습니다.
secret

docker 를 설치해본다.

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

apt-get install docker.io


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

# docker.io --version

Docker version 0.9.1, build 3600720


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

echo deb https://get.docker.io/ubuntu docker main > /etc/apt/sources.list.d/docker.list

apt-get update

apt-get install lxc-docker

한번에 끝내기

curl -s https://get.docker.io/ubuntu/ | sudo sh

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

Docker version 1.0.1, build 990021a

최신버전으로 설치된다.


간단한 테스트.

# docker run ubuntu:14.04 /bin/echo 'Hello World'

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

Unable to find image 'ubuntu:14.04' locally
Pulling repository ubuntu
e54ca5efa2e9: Download complete
511136ea3c5a: Download complete
d7ac5e4f1812: Download complete
2f4b4d6a4a06: Download complete
83ff768040a0: Download complete
6c37f792ddac: Download complete
Hello World


하위 버전은 다음을 참조.

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




WRITTEN BY
1day1
하루하루 즐거운일 하나씩, 행복한일 하나씩 만들어 가요.

트랙백  0 , 댓글  0개가 달렸습니다.
secret