처음에는 Graphite, DBInfluxDB, OpenTSDB 등을 지원하는 오픈소스 대시보드 도구로 개발
메트릭 정보를 시각화하고 대시보드를 구성한다는 큰 틀은 여전히 변함이 없습니다만, AWS CloudWatch, Azure Monitor와 같은 클라우드 데이터 소스를 비롯해 Loki나 ElasticSearch 등을 기반으로 로그 데이터를 지원하는 등 더 많은 데이터 소스를 지원
엔터프라이즈 플랜에서는 Splunk, New Relic, AppDynamics, Oracle, Dynatrace, ServiceNow, DataDog 등의 외부 서비스들과 통합도 지원
Grafana는 현재 Grafana Labs에서 개발
Grafana LAB은 Grafana와 Loki, Tanka 등의 애플리케이션을 오픈소스를 개발하고 있는 회사
Grafana는 Paypal, ebay, Intel, rackspace, Video, TED, Digital Ocean, Bloomberg 등 다양한 기업에서 활용
$ influx
# 초기 데이터베이스 확인
> show databases
name: databases
name
----
_internal
# fluentdb 이름을 가지는 데이터베이스 생성
> create database fluentdb
# 생성 확인
> show databases
name: databases
name
----
_internal
fluentdb
# 생성한 fluentdb 데이터베이스 접근
> use fluentdb
Using database fluentdb
$ docker images hippo_flask
REPOSITORY TAG IMAGE ID CREATED SIZE
hippo_flask v1 64d54ca5156c About a minute ago 51.7MB
3. hippo_flask:v1 docker 이미지를 통해 컨테이너 생성과 확인
컨테이너 생성
$ docker run --name version1 -d -p 9000:9000 hippo_flask:v1
3d75997676b1f71d80eb72070ac3dbba9695ead6810b8d2a6cefcc1bad83b939
생성된 컨테이너 확인
$ docker ps | grep version1
3d75997676b1 hippo_flask:v1 "python3 server.py" 14 seconds ago Up 13 seconds 0.0.0.0:9000->9000/tcp, :::9000->9000/tcp version1
생성된 컨테이너 통신 테스트
1. 생성된 컨테이너에 트래픽 전송하여 정상적으로 통신 되는지 curl 트래픽 전송 테스트
curl 명령어를 통해 통신 확인
$ curl localhost:9000/version
version 1
2. 생성된 컨테이너에 for문을 활용하여 연속적으로 트래픽 전송
배포하는 과정에서 변화를 알기 위해 curl를 for 통해 무한 사용
$ for (( ; ; )) do curl localhost:9000/version; sleep 1; done
version 1
version 1
version 1
version 1
version 1
version 1
version 1
^C
3. 생성한 컨테이너 종료
# 종료할 hippo_flask:v1 컨테이너 확인
$ docker ps | grep hippo_flask
3d75997676b1 hippo_flask:v1 "python3 server.py" 2 minutes ago Up 2 minutes 0.0.0.0:9000->9000/tcp, :::9000->9000/tcp version1
# 해당 컨테이너 종료
$ docker rm -f 3d75997676b1
# 컨테이너가 출력되지 않았으므로 정상적으로 삭제된 것 확인
$ docker ps | grep hippo_flask
gitlab private container registry에 이미지 올리기
1. gitlab private container registry 로그인
gitlab에 container registry에 로그인 작업 필요 → [서버 IP]:8001로 로그인 시도
docker login 명령어 입력 후 Username과 Password를 입력하면 로그인됨
$ docker login [서버 IP]:8001
Username: root
Password:
WARNING! Your password will be stored unencrypted in /root/.docker/config.json.
Configure a credential helper to remove this warning. See
https://docs.docker.com/engine/reference/commandline/login/#credentials-store
Login Succeeded
※ 참고 → docker repository에 http로 접근하면 오류 발생
$ docker login [서버 IP]:8001
Username: root
Password:
Error response from daemon: Get "https://서버 IP:8001/v2/": http: server gave HTTP response to HTTPS client
해결 방법 → 접근 시도하는 서버의 docker 설정 변경(insecure-registries 내용 부분 추가)
기본은 지정된 레파지토리 저장위치가 있으나 드라이브를 별도로 추가하여 운영하는 경우는 다른 드라이브로 저장 위치를 변경해야함
git_data_dirs 함수 아래에 원하는 저장 디렉토리를 지정
/dev/sdb1와 mount된 /data 디렉토리 아래에 gitlab_data에 저장(/data/gitlab_data)
/data/gitlab_data/ 디렉토리가 없다면 해당 디렉토리 생성 필요
$ mkdir /data/gitlab_data
# 레파지토리 저장 디렉토리 위치 변경
$ vi /etc/gitlab/gitlab.rb
## ...중략...
git_data_dirs({
"default" => {
"path" => "/data/gitlab_data"
}
})
3. 도메인 생성 및 SSL 적용
IP를 사용할 경우 SSL 사용 X
SSL을 사용하는 경우 도메인 필요
/etc/gitlab/ssl 디렉토리로 crt, key 파일 복사 필요
$ vi /etc/gitlab/gitlab.rb
external_url 'https:/도메인'
nginx['redirect_http_to_https'] = true
nginx['redirect_http_to_https_port'] = 80
nginx['ssl_certificate'] = "/etc/gitlab/ssl/도메인.crt"
nginx['ssl_certificate_key'] = "/etc/gitlab/ssl/도메인.key"
# 도메인 생성 및 SSL 설정 적용
$ gitlab-ctl reconfigure
multi masters의 단일 진입점인 LoadBalancer(LB) 구성 → 사실상 HA 클러스터 구성
192.168.0.100 IP를 사용하는 서버에 Nginx를 이용하여 LB 구성
Nginx docker 이미지를 이용하여 LB 사용 → docker 컨테이너 운영 관리에 쉬움
1. nginx 구성 파일을 만들어서 master들의 단일 진입점을 구성
# nginx로 Load Balancer할 수 있게 nginx.conf 파일 생성
$ mkdir /etc/nginx
$ cat << END > /etc/nginx/nginx.conf
events {}
stream {
upstream stream_backend {
least_conn;
server 192.168.0.200:6443;
server 192.168.0.201:6443;
server 192.168.0.202:6443;
}
server {
listen 6443;
proxy_pass stream_backend;
proxy_timeout 300s;
proxy_connect_timeout 1s;
}
}
END
2. 도커 컨테이너로 NGINX를 실행하면서 LB를 운영
# nginx 컨테이너 실행
$ docker run --name proxy -v /etc/nginx/nginx.conf:/etc/nginx/nginx.cof:ro --restart=always -p 6443:6443 -d nginx
Unable to find image 'nginx:latest' locally
latest: Pulling from library/nginx
b380bbd43752: Pull complete
fca7e12d1754: Pull complete
745ab57616cb: Pull complete
a4723e260b6f: Pull complete
1c84ebdff681: Pull complete
858292fd2e56: Pull complete
Digest: sha256:644a70516a26004c97d0d85c7fe1d0c3a67ea8ab7ddf4aff193d9f301670cf36
Status: Downloaded newer image for nginx:latest
4324e6beaef0bd05d76af525fa415c4bcdf34fb807e4280e952108bf0a957630
# nginx 컨테이너가 실행 중 확인
$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
4324e6beaef0 nginx "/docker-entrypoint.…" 54 seconds ago Up 53 seconds 80/tcp, 0.0.0.0:6443->6443/tcp, :::6443->6443/tcp proxy
# 통신이 되는지 확인
$ curl 192.168.0.100:6443
전역 옵션(global) 섹션과 기본 옵션(defaults) 섹션, 프록시 옵션 섹션(listen)의 주요 옵션에 관한 설명
global # 전역 옵션 섹션
daemon → 백그라운드 모드(background mode)로 실행
log → syslog 설정
log-send-hostname → hostname 설정
uid → 프로세스의 userid를 number로 변경
user → 프로세스의 userid를 name으로 변경
node → 두 개 이상의 프로세스나 서버가 같은 IP 주소를 공유할 때 name 설정(HA 설정)
maxconn → 프로세스당 최대 연결 개수
Defaults # 기본 옵션 섹션
log → syslog 설정
maxconn → 프로세스당 최대 연결 개수
listen
listen webfarm 10.101.22.76:80→ listen haproxy name ip:port
mode http → 연결 프로토콜
option httpchk → health check
option log-health-checks → health 로그 남김 여부
option forwardfor → 클라이언트 정보 전달
option httpclose → keep-alive 문제 발생 시 off 옵션
cookie SERVERID rewrite → 쿠키로 서버 구별 시 사용 여부
cookie JSESSIONID prefix → HA 구성 시 prefix 이후에 서버 정보 주입 여부
balance roundrobin → 순환 분배 방식
stats enable → 서버 상태 보기 가능 여부
stats uri /admin → 서버 상태 보기 uri
server xvadm01.ncli 10.101.22.18:80 cookie admin_portal_1 check inter 1000 rise 2 fall 5 → real server 정보(server [host명] [ip]:[port] cookie [서버쿠키명] check inter [주기(m/s)] rise [서버구동여부점검횟수], fall [서비스중단여부점검횟수])
3. balance 옵션
로드 밸런싱의 경우 round robin 방식을 일반적으로 사용하지만 다른 여러 방식이 있음 → 옵션에 적용할 수 있는 로드 밸런싱 알고리즘
roundrobin → 순차적으로 분배(최대 연결 가능 서버 4128개)
static-rr → 서버에 부여된 가중치에 따라서 분배
leastconn → 접속 수가 가장 적은 서버로 분배
source → 운영 중인 서버의 가중치를 나눠서 접속자 IP를 해싱(hashing)해서 분배
uri → 접속하는 URI를 해싱해서 운영 중인 서버의 가중치를 나눠서 분배(URI의 길이 또는 depth로 해싱)
url_param → HTTP GET 요청에 대해서 특정 패턴이 있는지 여부 확인 후 조건에 맞는 서버로 분배(조건 없는 경우 round robin으로 처리)
hdr → HTTP 헤더 에서 hdr()으로 지정된 조건이 있는 경우에 대해서만 분배(조건 없는 경우 round robin으로 처리)
