태그 보관물: Container

Docker Root Directory 위치 변경

개발 중인 서버에 접근해보니 루트 디렉토리가 91% 사용 중이었습니다.

(*도커의 루트 디렉토리 증설은 불가피했음.)

초기 설치 시 /var/lib/docker/overlay 디렉토리 경로 그대로 사용

01. 루트 디렉토리 설정 확인하기

docker info | grep Root 명령어로 Docker Root Dir이 /var/lib/docker임을 확인했습니다.

[root@totoli]# docker info | grep Root
 Docker Root Dir: /var/lib/docker

02. 루트 디렉토리 설정 변경하기

도커의 설정은 /etc/docker/daemon.json를 변경하면 됩니다.
json 형식으로 작성하면 되며, data-root 요소를 작성합니다.

[root@totoli]# vi /etc/docker/daemon.json

{
  "data-root": "/docker-data/data"		# 변경하고자 할 디렉토리로 작성합니다.
}

*example mount path : "/docker-data" 
mkdir /docker-data/data
cp -rp /var/lib/docker/* /docker-data/data/

03. 설정 변경 후 도커 재기동하기

[root@totoli]# systemctl restart docker

04. 루트 디렉토리 설정 재확인하기

docker info | grep Root 명령어로 다시 한번 확인합니다.
설정했던 바와 같이 /docker-data/data로 변경됨을 확인할 수 있습니다.

[root@totoli]# docker info | grep Root
 Docker Root Dir: /docker-data/data

/var/lib/docker/~~~에서 /docker-data/data/~~~ 로 변경됨을 확인.

05. 기존 루트 디렉토리 삭제

docker info | grep Root 명령어로 다시 한번 확인합니다.
설정했던 바와 같이 /docker-data/data로 변경됨을 확인할 수 있습니다.

ls /docker-data/data
* 잘 복사된것 확인 후 .

[root@totoli]# rm /var/lib/docker -Rf

3-Tier container environment configuration using Docker(NginX/Tomcat/MySQL)

이번 글에서는 Docker를 사용하여 간단한 3-Tier 컨테이너 환경을 구성해보고자 한다.

– WEB = NginX

– WAS = Tomcat

– DB = MySQL

구성은 WAS -> WEB -> DB 순으로 하도록 한다.

우선, WAS 부터 구성해보도록 하자.

1. WAS 구성

1-1. Github에 올라가 있는 어플리케이션 소스 다운로드

> 소스를 다운받을 디렉토리 생성 후 Git 저장소에서 소스를 Pull 한다.

root@master:~# mkdir -p /home/src
root@master:~# cd /home/src
root@master:/home/src#

root@master:/home/src# git clone https://github.com/Hwang-sangyeon/spring-framework-for-petclinic.git
Cloning into ‘spring-framework-for-petclinic’…
remote: Enumerating objects: 4, done.
remote: Counting objects: 100% (4/4), done.
remote: Compressing objects: 100% (4/4), done.
remote: Total 4 (delta 0), reused 4 (delta 0), pack-reused 0
Unpacking objects: 100% (4/4), 1.89 MiB | 4.96 MiB/s, done.

1-2. JDK와 Maven 설치

> 소스를 컴파일 하기 위해 OpenJDK와 Maven을 설치한다.

root@master:~# sudo apt-get install openjdk-8-jdk maven

(중략)
…
update-alternatives: using /usr/lib/jvm/java-11-openjdk-amd64/bin/unpack200 to provide /usr/bin/unpack200 (unpack200) in auto mode
update-alternatives: using /usr/lib/jvm/java-11-openjdk-amd64/lib/jexec to provide /usr/bin/jexec (jexec) in auto mode
Setting up libxdmcp-dev:amd64 (1:1.1.3-0ubuntu1) …
Setting up x11proto-core-dev (2019.2-1ubuntu1) …
Setting up libxcb1-dev:amd64 (1.14-2) …
Setting up libx11-dev:amd64 (2:1.6.9-2ubuntu1.2) …
Setting up libxt-dev:amd64 (1:1.1.5-1) …

1-3. JAVA_HOME 설정

> 현재 java -version으로 버전 확인 시 설치한 자바로 설정되어 있지 않기 때문에 아래와 같이 변경이 필요하다.

root@master:/home/src# sudo update-java-alternatives –list
java-1.11.0-openjdk-amd64 1111 /usr/lib/jvm/java-1.11.0-openjdk-amd64
java-1.8.0-openjdk-amd64 1081 /usr/lib/jvm/java-1.8.0-openjdk-amd64
root@master:/home/src#
root@master:/home/src#
root@master:~# sudo update-java-alternatives –jre-headless –jre –set java-1.8.0-openjdk-amd64

root@master:/home/src# java -version
openjdk version “1.8.0_292”
OpenJDK Runtime Environment (build 1.8.0_292-8u292-b10-0ubuntu1~20.04-b10)
OpenJDK 64-Bit Server VM (build 25.292-b10, mixed mode)

1-4. 소스 Build

> 이제 소스와 컴파일 할 JDK와 maven도 준비되었기 때문에 Compile을 해보도록 하자

소스 경로에 들어가 압축을 풀고 아래와 같이 빌드를 진행해준다.

빌드 전에 잠시 소스 수정이 필요하다.
pom.xml에 mysql 연동 부분에 localhost:3306을 mysql-petclinic:3306으로 수정하자.
was와 db가 다른 컨테이너로 기동되기 때문에 localhost를 인식할 수 없다.
그러나 mysql-petclinic은 컨테이너 명으로 link가 걸려 통신이 가능하다..

root@master:/home/src/spring-framework-for-petclinic/spring-framework-for-petclinic# mvn clean package -Dmaven.test.skip=true -P MySQL

…(중략)

[INFO] ————————————————————————
[INFO] BUILD SUCCESS
[INFO] ————————————————————————
[INFO] Total time: 16.802 s
[INFO] Finished at: 2021-11-07T13:54:37+09:00
[INFO] ————————————————————————

=========================================================================
빌드를 하고 나면, 소스 경로 하위의 target 디렉토리에 petclinic.war 소스 파일이 생성된다.

root@master:/home/src/spring-framework-for-petclinic/spring-framework-for-petclinic/target# ls -arlt|grep petclinic.war
-rw-r–r– 1 root root 41605349 11월 7 13:54 petclinic.war

1-5. WAS 이미지 생성

> 이제 만든 소스를 활용하여 tomcat 이미지를 만들어보도록 하자.

우선 이미지 생성을 위해 Dockerfile을 생성하고 이전에 만들었던 petclinic.war 파일을 같은 디렉토리에 위치시킨다.

root@master:/home/dockerfile/petclinic# pwd
/home/dockerfile/petclinic
root@master:/home/dockerfile/petclinic# ls -arlt
total 40644
drwxr-xr-x 5 root root     4096 11월  7 14:06 ..
-rw-r–r– 1 root root 41605349 11월  7 14:06 petclinic.war
-rw-r–r– 1 root root       64 11월  7 14:06 Dockerfile
drwxr-xr-x 2 root root     4096 11월  7 14:06 .

하기는 Dockerfile 내용이다.
root@master:/home/dockerfile/petclinic# cat Dockerfile
From tomcat:8-jre8
ADD petclinic.war /usr/local/tomcat/webapps/

위와 같이 준비가 되었다면 이제 해당 위치에서 이미지 빌드를 하면 된다.

커맨드는 아래와 같다.

root@master:~/docker/tomcat-test# docker build -t tomcat-petclinic .
Sending build context to Docker daemon 41.61MB
Step 1/2 : From tomcat:8-jre8
8-jre8: Pulling from library/tomcat
bb7d5a84853b: Pull complete
f02b617c6a8c: Pull complete
d32e17419b7e: Pull complete
ab18cfab55f9: Pull complete
793716e93ecb: Pull complete
3b9b14f7678b: Pull complete
4dc2d594b57d: Pull complete
3f275ee15a3d: Pull complete
15b0db619216: Pull complete
c0aa838e7a3a: Pull complete
Digest: sha256:47165dabe7c092c61ef2726a7fdc70dda0ce9dea07ca68bda0aea6ecfaba2873
Status: Downloaded newer image for tomcat:8-jre8
—> cff25871f024
Step 2/2 : ADD petclinic.war /usr/local/tomcat/webapps/
—> f27039d77fc4
Successfully built f27039d77fc4
Successfully tagged tomcat-petclinic:latest

2. WEB 구성

2-1. NginX 리소스 다운로드

> Git에 올라가 있는 NginX 리소스를 다운받는다.

root@master:/home/src# git clone https://github.com/Hwang-sangyeon/nginx-for-petclinic.git
Cloning into ‘nginx-for-petclinic’…

리소스 다운로드 후,

nginx.conf 파일에서 was 연동 포트 확인 및 nginx listen-port를 확인한다.

2-2. 이미지 생성

> Dockerfile이 있는 디렉토리에서 이미지를 빌드한다.

root@master:/home/src/nginx-for-petclinic/nginx-for-petclinic# docker build -t nginx-petclinic .
Sending build context to Docker daemon 6.656kB

2-3. WEB/WAS 이미지 확인

root@master:/home/src/nginx-for-petclinic/nginx-for-petclinic# docker images|grep petclinic
nginx-petclinic latest 952aff9083ee 19 seconds ago 133MB
tomcat-petclinic latest 39e56a91e5e7 9 minutes ago 334MB

3. 컨테이너 기동

이제부터는 필요한 이미지가 준비되었기 때문에 WEB/WAS/DB 컨테이너를 기동하여 3-Tier를 구성을 해보려고 한다.

여기서 중요한 점은 WAS가 기동되기 전에 (소스 빌드) DB가 먼저 떠있어야 하기 때문에 DB 컨테이너를 반드시 먼저 기동시켜야 한다는 것이다.

3-1. DB 컨테이너 기동

> mysql-petclinic 컨테이너 명으로 mysql 이미지를 바로 받아 컨테이너를 실행한다.

docker run --name mysql-petclinic -e MYSQL_ROOT_PASSWORD=petclinic -e MYSQL_DATABASE=petclinic -p 3306:3306 mysql:5.7.8

Initializing database 이후 docker container ps로 확인

root@master:~# docker container ps | grep mysql
d286f5c59a6c mysql:5.7.8 “/entrypoint.sh mysq…” 57 seconds ago Up 56 seconds 0.0.0.0:3306->3306/tcp, :::3306->3306/tcp mysql-petclinic

3-2. WAS 컨테이너 기동

docker run -it --rm -p 8080:8080 --name tomcat-petclinic --link mysql-petclinic:mysql-petclinic tomcat-petclinic

> tomcat 컨테이너에서 mysql 컨테이너의 ip로 접속할 수 있겠지만, static ip가 아니기 때문에 mysql 컨테이너의 이름으로 접속을 해야 할 필요가 있다. 이럴 경우 link 옵션을 통해 컨테이너를 구동하면 tomcat 컨테이너에서 mysql 컨테이너로 이름으로 접속할 수 있다. link 옵션으로 구동하면 톰캣 컨테이너 안의 /etc/hosts에 링크된 mysql 컨테이너 hostname과 ip가 들어간다.

3-3. WEB 컨테이너 기동

docker run -it --rm -p 80:80 --name nginx-petclinic --link tomcat-petclinic:tomcat-petclinic nginx-petclinic

4. 서비스 호출

192.168.56.200은 VM의 IP

이상 도커를 활용하여 3-Tier 컨테이너 환경을 구성해보았다..

Kubernetes Monitoring : HPA (Horizontal Pod Autoscaler)

Overview

쿠버네티스 클러스터에서 hpa를 적용해 시스템 부하상태에 따라 pod을 autoScaling시키는 실습을 진행하겠습니다.

참고 링크 : Kubernetes.io/Horizontal Pod Autoscaler

Prerequisites

먼저 쿠버네티스 클러스터를 생성해주세요.

참고링크 : 호롤리한하루/Install Kubernetes on CentOS/RHEL

본 실습에서 사용한 spec :
OS : CentOS v7.6
Arch : x86

Kubernetes : v1.16.2
Master : 4cpu, ram16G (1개)
Node : 4cpu, ram16G (2개)

Step

그림1

1. Metrics-Server 배포

먼저 top명령어를 입력해봅시다.

$ kubectl top node

Error from server (NotFound): the server could not find the requested resource (get services http:heapster:)

현재는 에러메세지가 뜹니다.
이유는 노드의 system metric들을 수집하는 서비스가 없기 때문입니다.

system metric을 수집하는 Metrics-Server를 배포해주도록 합시다.

$ git clone https://github.com/kubernetes-sigs/metrics-server.git
$ cd metrics-server

쿠버네티스에서 공식으로 서포트하고있는 add-on 컴포넌트인 metrics-server를 클론받고, 배포하기 이전에 yaml파일을 수정해주어야합니다.
클러스터 내에서 사용하는 인증서가 신뢰되지 않은 경우와 호스트 이름을 찾지 못하는 경우를 방지하기 위함입니다

$ vim deploy/kubernetes/metrics-server-deployment.yaml

위 그림과 같이 argument들을 수정해줍니다.

args:
  - --kubelet-insecure-tls
  - --kubelet-preferred-address-types=InternalIP
  - --cert-dir=/tmp
  - --secure-port=4443

그리고 나서 metrics-server를 배포하면 :

$ kubectl apply -f deploy/kubernetes/

clusterrole.rbac.authorization.k8s.io/system:aggregated-metrics-reader created
clusterrolebinding.rbac.authorization.k8s.io/metrics-server:system:auth-delegator created
rolebinding.rbac.authorization.k8s.io/metrics-server-auth-reader created
apiservice.apiregistration.k8s.io/v1beta1.metrics.k8s.io created
serviceaccount/metrics-server created
deployment.apps/metrics-server created
service/metrics-server created
clusterrole.rbac.authorization.k8s.io/system:metrics-server created
clusterrolebinding.rbac.authorization.k8s.io/system:metrics-server created

중간에 metrics.k8s.io라는 API가 생성되어 Api server에 등록된 것을 확인할 수 있습니다.

이제 top명령어를 사용할 수 있게 됩니다.

$ kubectl top nodes

NAME       CPU(cores)   CPU%   MEMORY(bytes)   MEMORY%
kube-m     248m         6%     1656Mi          10%
kube-n01   112m         2%     760Mi           4%
kube-n02   112m         2%     724Mi           4%

각 노드의 cpu와 memory사용량을 확인할 수 있습니다.

2. 부하테스트를 위한 이미지 작성

이제 시스템의 부하테스트를 위한 이미지를 작성해보겠습니다.

$ mkdir php
cd php

스크립트 작성 :

$ vim index.php

<?php
  $x = 0.0001;
  for ($i = 0; $i <= 1000000; $i++) {
    $x += sqrt($x);
  }
  echo "OK!";
?>

스크립트를 포함하는 도커 이미지 작성 :

$ vim Dockerfile

FROM php:5-apache
ADD index.php /var/www/html/index.php
RUN chmod a+rx index.php

도커 이미지 빌드 :

$ docker build --tag {docker id : totoli78}/php-apache .

$ docker images |grep php

totoli78/php-apache                    latest              39e1797ad29c        23 seconds ago      355MB

생성한 이미지를 본인의 docker hub에 push해줍니다.

$ docker login
...
Login Succeeded

$ docker push totoli78/php-apache

부하테스트를 위해 쿠버네티스 클러스터에 pod으로 배포해줍니다.

$ vim hpa-test.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: php-apache
spec:
  selector:
    matchLabels:
      run: php-apache
  replicas: 1
  template:
    metadata:
      labels:
        run: php-apache
    spec:
      containers:
      - name: php-apache
        image: totoli78/php-apache
        ports:
        - containerPort: 80
        resources:
          limits:
            cpu: 500m
          requests:
            cpu: 200m
---
apiVersion: v1
kind: Service
metadata:
  name: php-apache
  labels:
    run: php-apache
spec:
  ports:
  - port: 80
  selector:
    run: php-apache

yaml을 작성한 뒤에는 배포!

$ kubectl apply -f hpa-test.yaml

deployment.apps/php-apache created
service/php-apache created

3. HPA 배포

이제 오토스케일러를 생성해주면 됩니다.

$ vim autoscaler.yaml

위에서 만든 부하테스트용 pod인 php-apache의 평균 cpu사용량을 50%로 맞추기 위해 레플리카의 개수를 늘리고 줄입니다. (1개~10개)

apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
  name: php-apache
  namespace: default
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: php-apache
  minReplicas: 1
  maxReplicas: 10
  targetCPUUtilizationPercentage: 50

$ kubectl apply -f autoscaler.yaml
horizontalpodautoscaler.autoscaling/php-apache created

hpa커맨드를 통해 현재 hpa에 감지되는 시스템 부하정도와 관리하는 pod의 개수를 확인할 수 있습니다.

$ kubectl get hpa
NAME         REFERENCE               TARGETS   MINPODS   MAXPODS   REPLICAS   AGE
php-apache   Deployment/php-apache   0%/50%    1         10        1          18s

아직은 서버로 어떠한 요청도 하지 않았기 때문에, 현재 cpu소비량은 0%임을 알 수 있습니다. (TARGET은 deployment에 의해 제어되는 pod들의 평균을 뜻합니다.)

부하테스트

부하가 증가함에 따라 오토스케일러가 어떻게 반응하는지 살펴보겠습니다.

창을 하나 더 띄워서 php-apache 서비스에 무한루프 쿼리를 전송합니다.

$ kubectl run -it --rm load-generator --image=busybox /bin/sh

If you don't see a command prompt, try pressing enter.
/ #
/ # while true; do wget -q -O- http://php-apache.default.svc.cluster.local; done
OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!...

1~2분 지난 뒤에 hpa커맨드로 부하상태를 살펴보면 TARGET의 수치가 높아진 것을 확인할 수 있습니다.

$ kubectl get hpa

NAME         REFERENCE               TARGETS    MINPODS   MAXPODS   REPLICAS   AGE
php-apache   Deployment/php-apache   248%/50%   1         10        1          9m7s

그리고 deployment 컨트롤러를 확인해보면 pod의 replica수가 5개까지 늘어난 것을 확인할 수 있습니다.

$ kubectl get deploy php-apache

NAME         READY   UP-TO-DATE   AVAILABLE   AGE
php-apache   5/5     5            5           12m

busybox컨테이너를 띄운 터미널에서 Ctrl+C로 부하 발생을 중단시키고, 몇 분 후에 결과를 확인합니다.

$ kubectl get hpa

NAME         REFERENCE               TARGETS   MINPODS   MAXPODS   REPLICAS   AGE
php-apache   Deployment/php-apache   0%/50%    1         10        5          11m

cpu의 사용량이 0%까지 떨어졌고, deployment의 pod replica수도 1개로 줄어든 것을 확인할 수 있습니다.

$ kubectl get deploy php-apache

NAME         READY   UP-TO-DATE   AVAILABLE   AGE
php-apache   1/1     1            1           19m

replica autoscaling은 몇 분 정도 소요됩니다. (체감상 3~5분)