2017년 8월 11일 금요일

Grafana docker upgrading.

기억력이 감퇴해서 매번 검색해야 하는 머리를 위해.


거대 프로젝트가 아니라 우리는 Database로 sqlite를 사용합니다.


1. 최선의 방법.


   Installing using Docker 문서를 천천히 읽고 container를 생성할 때 database와 환경
   설정 변수 경로를 host에 맵핑 시키기만 하면 backup / restore 과정이 없어도 됩니다.

  
1
2
3
4
$ docker run -d -p 3000:3000 \
    -v /var/lib/grafana:/var/lib/grafana \
    -e "GF_SECURITY_ADMIN_PASSWORD=secret" \
    grafana/grafana
cs


2. 업그레이드


  
1
2
3
4
docker pull grafana
docker stop my-grafana-container
docker rm my-grafana-container
docker run --name=my-grafana-container --restart=always -/var/lib/grafana:/var/lib/grafana
cs


3. 1번 방법으로 설치하지 않았을 경우.


   sqlite의 경우 grafana.db를 백업해야 합니다. 보통 /var/lib/grafana/grafana.db 경로에
   위치해 있고 설정 파일의 경우 /etc/grafana/grafana.ini 경로에 있습니다.
   설정 파일의 경우엔 버전에 따라 다를 수 있으므로 백업 후 그대로 복구하지 않고
   비교해보고 진행합니다.

   그 외 다른 Database를 사용하는 경우 백업은 Upgrading Grafana 문서를 참조합니다.

  

2017년 8월 7일 월요일

Docker container 그리고 VI.

Debian 계열로 만들어진 이미지를 사용하는 경우 편집기 때문에 애를 먹어서 간단하게 정리해본다.

1. Update.

   2번 명령으로 설치가 안되는 경우 진행.

  
1
sudo apt-get update
cs


2. Install.

  
1
sudo apt-get install vim-full
cs

2017년 8월 4일 금요일

Docker 옵션.

사용중인 옵션을 정리해 본다.


1. --insecure-registry


   private registry 서버를 사용할 때.


2. -g


   Docker image 저장 경로를 변경하고 싶을 때.


3. 예제


  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
# /etc/sysconfig/docker
#
# Other arguments to pass to the docker daemon process
# These will be parsed by the sysv initscript and appended
# to the arguments list passed to docker -d
 
other_args="-g /home/ships/docker/ --insecure-registry 192.168.1.100:5000"
DOCKER_CERT_PATH=/etc/docker
 
# Resolves: rhbz#1176302 (docker issue #407)
DOCKER_NOWARN_KERNEL_VERSION=1
 
# Location used for temporary files, such as those created by
# # docker load and build operations. Default is /var/lib/docker/tmp
# # Can be overriden by setting the following environment variable.
# # DOCKER_TMPDIR=/var/tmp
cs

2017년 8월 3일 목요일

How Should I Get Application Configuration into my Docker Containers?

어떻게 다양한 환경에 배포할 수 있을까?


서버를 다 만들고 배포할 때 지금까지는 동일한 환경에서 배포가 가능했다.
그런데 다른 환경에 배포를 하게 되면서 일부 설정이 틀려져야만 하는 상황이 발생한 것이다.
이 글은 인터넷에서 찾은 블로그 게시물을 간단하게 요약한 것임을 밝힙니다.

원문은 How Should I Get Application Configuration into my Docker Containers? 링크를 통해 확인 가능합니다.


1. 지금까지 해왔던 방법.


   이미지를 만들 때 설정 파일을 같이 포함한다.
   그럼 설정이 달라야 하는 서버에 배포하는 경우엔 어떻게 할까?
   우선 컨테이너를 실행한 뒤, 설정 파일을 변경한 후 컨테이너를 재시작.

   장점:
      ■ 설정 파일을 임의로 변경하지 않는 한 모든 컨테이너는 동일하다.

   단점:
      ■ 설정 변경을 위해 docker image를 새로 빌드하거나 우리의 경우처럼 컨테이너를
         직접 수정해야 한다.


2 - 1. 환경 변수로 전달.


   일반적으로 많이 사용되는 방법.

  
1
docker run -e SETTING1=foo -e SETTING2=bar ... <image name>
cs


   장점:
      ■ 1번 방법에 비해 좀 더 동적인 설정이 가능해진다.

   단점:
      ■ 개발 / 서비스 버전의 컨테이너가 변수에 의해 다른 행동을 할 수 있다.
      ■ nginx/apache의 virtual host configuration과 같이 key/value로 정의하기 어려운
         설정이 존재한다.


2 - 2. 환경 변수로 전달.


   2 - 1 방법과 비슷하지만 컨테이너가 시작될 때 직접 전달하는 방법이 아니라
   Consul 또는 etcd처럼 네트웍을 통해서 KV store설정을 사용하는 방법.
   KV store의 경우 계층적 구조를 가질 수도 있기 때문에 key/value 형태의 단순 환경 변수
   전달에 비해 훨씬 더 많은 것들이 가능해진다.
   심지어 confd 같은 경우 KV store가 변경되면 응용 프로그램을 자동으로 재시작 해준다.

   장점:
      ■ 지금까지 이야기했던 방법 중 제일 동적이고 많은 것들을 할 수 있다.

   단점:
      ■ KV store같은 외부 의존성이 생긴다.


3. Docker Volume을 통해 host 파일을 사용.


   이 방법도 기존에 사용하고 있던 방법.

  
1
docker run -/home/ships/my_statsd_config.conf:/etc/statsd.conf hopsoft/graphite-statsd
cs


   장점:
      ■ 임의의 설정 문제로 컨테이너를 변경할 필요가 없습니다.

   단점:
      ■ 배포시 Docker와 별개로 Host OS에 설정 파일을 배포해야 하고 그런 경우
         Ansible, Chef, 또는 Puppet 같은 관리 도구가 별도로 필요할 수 있습니다.

4. 결론.



   경우에 맞게 설정이 얼마나 복잡하고 동적이어야 하는지에 따라 결정.
   배포는 언제나 문제고 어렵다