[최종정리] 쿠버네티스란? 쿠버네티스 실습

이호용·2021년 6월 10일

42_ft_services

목록 보기

8/8

쿠버네티스 정리부터 실습까지 정리된글입니다. 너무 양이 많아서, 1~7번 까지 글과 0번 글이 같습니다. 편한거 보시면 됩니다. 내용은 같습니다.

내용들은 추가적으로 제가 쿠버네티스를 공부하며, 중요하다고 생각된 내용들을 정리해서 작성해두었습니다..

쿠버네티스에 대해 알아보자.

기본적으로 쿠버네티스를 이해하려면 컨테이너와 오케스트레이션 개념에 대해 함께 알아야한다. 같이 한번 알아보자.

컨테이너 오케스트레이션란? (여러 컨테이너들을 효과적으로 관리하기위한 도구)

컨테이너 오케스트레이션이란? : 컨테이너의 배포, 관리, 확장, 네트워킹을 자동화 하는 기술을 말한다.

하나의 서비스를 구현하다보면, 여러개의 서버, 여러개의 클라이언트들을 사용하게 된다. 이러한 다양한 종류의 서버와 클라이언트를 하나의 컴퓨터에서 돌릴때 라이브러리 버전이 다르거나, 충돌이 발생할수 있는데, 이러한 오류들을 방지하기위해, 각각의 서버나 클라이언트를 컨테이너화 하게 된다. 문제는 이러한 컨테이너의 수가 많아지면 배포, 관리 ,확장, 네트워킹 자동화가 힘들어지는데 이러한 작업들을 컨테이너 오케스트레이션에서 자동화 시켜줄수 있다.

한번 보고 넘어가기 : 컨테이너 오케스트레이션은 YAML 또는 JSON 파일을 사용해 애플리케이션 설정에 대해 설명하게 됩니다.

1. 컨테이너란?

컨테이너는 리눅스 기술을 사용하여 선박의 컨테이너 처럼 프로세스가 사용하는 애플리케이션을 관련 라이브러리 및 종속 항목을 격리 하는 것입니다

vm 과 도커 차이 : vm의 경우, 호스트 os위에 각각의 vm즉 guestOS를 하나씩 설치한다. (호스트 os와 게스트 os사이에 커널을 하나씩 생성해야하고, 이러한 커널작업과, guest마다 os를 생성하다 보니, 무겁고 느려진다.) 컨테이너의 경우, 하나의 호스트에 도커 엔진을 올리고 도커 엔진 위에 Application 실행에 필요한 바이너리만 올라가게 됩니다.
사진!

(사진참고)[https://medium.com/@darkrasid/docker%EC%99%80-vm-d95d60e56fdd][vm과 도커 차이 잘 정리 되어있음.](https://khj93.tistory.com/entry/Docker-Docker-%EA%B0%9C%EB%85%90)

2. 컨테이너 특징

가상머신에 비해 쉽게 컨테이너 생성이 쉽고 효율적이다.
컨테이너 이미지를 이용한 배포와 롤백이 간단.
언어나 프레임워크에 상관없이 애플리케이션을 동일한 방식으로관리.
개발, 테스팅, 운영 환경은 물론 로컬 피시와 클라우드 까지 동일한 환경을 구축(보통 개발에서 어려웟던 부분이 로컬 컴퓨터에서 잘 작동했는데, 실제로 운영해보면 정상적이지 않앗던 부분이 있다. 그러나 컨테이너 화하는건 이런 에러 사항을 해결해주었다.)
특정 클라우드 벤더에 종속적이지 않음. (aws에서 쓰던걸 다른 환경으로 옮겨서도 쉽게 적용이 가능하다. 그냥 이미지파일만 옮겨서 사용하면 됨.)

컨테이너 원리 : 컨테이너는 계층형태로 구성되어있다. 도커에서 컨테이너를 만들 떄 이미지 계층 방식을 이용한다. 예를들면 하나의 컨테이너 위에 os와 nginx를 올리고 싶다면, os레이어를 컨테이너에 쌓고, 추가적으로 nginx레이어를 추가해서 os와 nginx가 설치된 컨테이너를 만들수 있다. 이렇듯 컨테이너를 만들떄는 한층한층씩 쌓는데, 쌓을때 필요한 데이터인 이미지는 도커에서 올릴때 읽기 전용으로 만 사용되며, 여러개의 컨테이너를 만들떄 하나의 이미지로 여러개의 똑같은 컨테이너를 쉽게 만들수 있다.
컨테이너의 원리

3. 컨테이너를 여러개 생성했을떄 단점

프로그램 마다 containerization화 시키다 보니, 컨테이너의 개수가 많아졌고, 컨테이너 하나하나 관리하기가 힘들어졋다.
컨테이너가 많아지다보니, 어느날 갑자기 컨테이너가 멈춰버리거나 또는 서버가 갑자기 부하를 많이 받을떄 여러개의 컨테이너들을 모두 재부팅하거나, 로드벨런스를 시켜주어야하는데 이를 하나하나 수작업으로 하기엔 일이 많다.
프로그램들을 버전업 할떄, 다른 프로그램들도 같이 버전업을 해야하는데 컨테이너 하나하나 들어가며 업데이트를 할려니 일이 많다.
로드벨런서를 할때, 또한 여러 컨테이너가 있는데 그것들을 모두 로드벨런스 할려면 일이 많다.

로드벨런서란? : 하나의 인터넷 서비스가 발생하는 트래픽이 많을 때 여러 대의 서버가 분산처리하여 서버의 로드율 증가, 부하량, 속도저하 등을 고려하여 적절히 분산처리하여 해결해주는 서비스입니다.

Container Orchestration Tool 종류(Top 8)

Amazon ECS
Azure Container Service(ACS)
Cloud Foundry's Diego
CoreOS Fleet
Docker Swarm
Google Container Engine
Kubernetes
Mesosphere Marathon(메소스사의 마라톤)

2. 쿠버네티스란?

쿠버네티스는 컨테이너화된 워크로드와 서비스를 관리하기 위한 이식성이 있고, 확장가능한 구글에서 만든 오픈소스 플랫폼이다.
컨테이너 오케스트레이션 중 하나

3. 쿠버네티스의 구성

kubernetes 는 마스터(master), 노드(node), 애드온(addon)으로 구성됩니다. 추가적으로 마스터와 노드로 구성된 클러스터도 살펴보도록 하겠습니다.

1. 마스터

마스터에는 etcd, kube-apiserver, kube-scheduler, kube-controller-manager, kubelet, kube-proxy, docker등이 실행됩니다

쿠버네티스의 주요 컨트롤 유닛으로서 Worker Nodes를 관리하는 주체입니다.

사진, 마스터와 노드 정리

2. 노드

노드는 쿠버네티스에서 워커 머신을 말하며 클러스터에 따라 가상 또는 물리 머신일 수 있다. 각 노드는 마스터에 의해 관리된다. 하나의 노드는 여러 개의 파드를 가질 수 있고, 쿠버네티스 마스터는 클러스터 내 노드를 통해서 파드에 대한 스케쥴링을 자동으로 처리한다.

3. 애드온

클러스터 내부에서 실행중인 컨테이너의 상태를 모니터링하기 위해서는 cpu, 메모리 같은 필요한 메트릭 데이터들을 시계열형식으로 저장하고 볼수 있는 방법을 제공하는데 필요한 애드온입니다. (에드온은 쿠버네티스에서 데쉬보드같이 여러 형태로 사용자가 볼수 있게 제공해준다.)

(조대협님 블로그 사진참조)[https://bcho.tistory.com/1256][쿠버네티스 아키텍처](https://arisu1000.tistory.com/27827)

4. 클러스터

앞서 살펴본 마스터와 마스터와 노드로 구성된게 클러스터입니다.
쿠버네티스 클러스터는 크게 2가지 종류로 구성됩니다. 클러스터를 관리하는 역할을 하는 마스터(master)와 실제 컨테이너를 실행시키는 작업을 하는 노드(node)입니다.

클러스터는 쿠버네티스에서 컨테이너화된 애플리케이션을 실행하기 위한 일련의 노드 머신입니다. 쿠버네티스를 실행 중이라면 클러스터를 실행하고 있는 것입니다.

쿠버네티스 클러스터에는 원하는 상태가 있으며, 이 상태는 실행해야 할 애플리케이션이나 워크로드, 사용하는 이미지, 사용할 수 있는 리소스 등과 같은 기타 구성 세부 사항을 정의합니다.

클러스터란? 한번 읽어보기
쿠버네티스 클러스터가 갖춰야 할 특성은 다음과 같습니다.

보안성: 최신 보안 모범 사례를 따라야 합니다.
사용 편이성: 몇 가지 간단한 명령으로 작동할 수 있어야 합니다.
확장 가능성: 하나의 제공업체만을 선호해서는 안 되고 구성 파일을 통해 사용자 정의할 수 있어야 합니다.

4. 쿠버네티스 용어

1. master : 마서트 노드에서 실행되는 세개의 프로젝트 집합(kube-apiserver, kube-controller-manager, kube-scheduler)
1. Node : kubelet, kube-proxy, 동작중인 pod를 유지시키고 런타임 환경제공 노드는 클러스터에 따라 가상 또는 물리적 시스템 일 수 있습니다
1. Control Plane : master + kubelet
1. object : Pod, Service, Volume, Namespace 등으로 시스템의 상태를 나타내는 추상 개념 (써보면 감이 올거다. 간단한 예로, 파드에 연결하는 외부포트설정도 objecte 중 하나이다.)
1. Controller : ReplicaSet, Deployment, StatefulSet, DaemonSet, Job 등으로 기초 오브젝트를 기반으로 부가 기능 및 편의 기능을 제공하는 개념. (deployment 나 replicaset의 경우 pod에 해당하는 부가적인 기능을 추가할수 있다.)
1. Pod : 컨테이너의 집합으로 가장 작은 배포 단위. Pod 내부의 컨테이너 들은 네트워크와 볼륨을 공유, 클러스터내의 Running 프로세스
  
  pod 특징 : Pod 내의 컨테이너는 IP와 Port를 공유한다. 서로다른 컨테이너가 하나의 pod를 통해서 배포 되었을경우, localhost 를 통해서 통신이 가능하다. 예를들면 하나의 컨테이너 A가 포트가 8080이고 다른 하나는B가 7002라면 배포가 되었을 때, B에서 A를 호출할떄, localhost:7001로 호출하면 된다., Pod 내에 배포된 컨테이너간에는 디스크 볼륨을 공유할 수 있다.

조대협님 블로그 사진 및 내용 참고..

1. volume : 쿠버네티스에서 볼륨이란 Pod에 종속되는 디스크이다. (컨테이너 단위가 아님). Pod 단위이기 때문에, 그 Pod에 속해 있는 여러개의 컨테이너가 공유해서 사용될 수 있다.
볼륨에는 종류에는 여러가지가 있는데, 나는 pod를 껏다켜도 안전하게 데이터를 복원할수 있고, 컴퓨터 저장공간도 여유가 있기에, 실습에선 persistentvolume을 사용하고자한다.

persistentvolume 이란? 시스템 관리자가 생성한 물리 디스크를 쿠버네티스 클러스터에 표현한것이 PV 입니다. 시스템 관리자가 실제 물리 디스크를 생성한 후에, 이 디스크를 PersistentVolume이라는 이름으로 쿠버네티스에 등록합니다
persistentvolumeclame 이란? : pv를 사용할떄는 pvc도 함께 사용하는데, pvc는 PVC는 사용자가 PV에 하는 요청이다. 사용하고 싶은 용량은 얼마인지, 읽기/쓰기는 어떤 모드를 사용하고 싶은지 등을 정하여 요청한다. 즉 사용자가 직접 볼륨을 할당 하는게, 아니라, pvc를 두어 좀더 쉽게 volume을 생성할수 있게 도와주는게 pvc이다.

사진참조

1. Service : pod의 집합들을 외부와 연결해주는 정책에 대한 추상화.
1. Cluster IP : 클러스터 내에서 사용되는 내부 IP
1. External IP : 외부 ip

이외에도 다른 용어들이 있다. 더 궁금한게 있다면, 쿠버네티스 공홈 여기 들어가서 살펴보길 바란다.

5. 쿠버네티스 역활(가볍게 읽어보기)

1. 클러스터 역활(가볍게만 읽어보기)

1. 중앙제어

컨테이너가 무수히 많아진다고 가졌했을떄,
cpu1000, ram8gb, cpu8000,ram32gb, cpu100,ram256mb 처럼 서버가 나뉘어 져있들떄 기존에는 서버관리자가 다 알고 관리를 햇지만, 이런 서버가 무수히 많아졌을때 관리를 편하게 하기위해, 여러 서버를 하나의 클러스터로 합치고 관리를 한다.
이런 클러스터들들은 여러 서버들을 집합체인데, 이 서버들에 하나하나 접속해서 관리하기는 어렵기 떄문에, 하나의 마스터 서버를 두고 마스터서버에 명령 을 내리면 어떤서버든 접속가능하게 만들어주엇다.

2. 네트워킹

클러스터의 노드들끼리는 네트워크가 잘 되어있어, 서버들끼리 통신하는데 문제가 없어야한다.

3. 노드 스케일

노드의 개수가 1000가 넘어갈수도 있다. 잘 관리되게 설계해야한다.
노드의 개수가 수천개 수만개 가 되더라도 클러스터역활이 잘 되어야한다.

2. state (상태관리)

컨테이너가 3개를 사용한다고 설정을 해두 었는데, 사용중 한개가 갑자기 꺼지면 알아서 새로운 컨테이너 하나를 열어 3개를 유지하게 만들어 주는기능

3. scheduling (배포관리)

여러 프로그램이 있는데, 어떤 서버는 여유가 있고 어떤 서버는 여유가 없다. 이럴떄 여유있는 서버에 넣고 여유없는곳은 그대로 두는 배포관리역활도 함.

4. 배포 버전관리

컨테이너 마다 버전이 다른데, 이버전들을 하나하나 업데이트시키는게 아니라 한번에 해줌. 롤백도 가능함.

5. 서비스 등록 및 조회

사용자나 쿠버네틱이(오케이스트레이션) 서버를 사용하겠다고 등록하면, 새로운 서버를 사용하는 프록시 서버에 자동으로 설정해주는 기능''

6. 볼륨 스토리지

각 노드마다, NFS나 AWS EBS, GCEPD 같은 volume들을 마운트해줘야하는데, 이를 손으로 할수 있지만, 설정으로도 할 수 있게 해줌.

이외에도 오케이스트레이션에는 컨테이너를 관리하는 다양한 기능들이 있다.

그중 하나가 쿠버네티스임!

한번 읽어 보기

1. 왜 쿠버네티스를 많이 사용할까?

구글은 1주일에 20억개의 컨테이너를 만들고 있엇다. 이런 구글이 만든 오케이스트레이션이 쿠버네티스이다.
(아무래도 많은 컨테이너를 다룬 구글이니까 더 용의하게 만들었겠지?)

2. 어떤걸 배울까?

쿠버네티스 == 어렵다.

구성요소를 이해하고, 동작원리를 파악하고 기본적인 사용법을 익혀보자.
롤도 잘할려면 어렵다... 하지만 즐겜으로 마우스 움직이고 캐릭터 움직이는건 할만하다 그정도만 일단 배워보자.

3. 도커를 사용하며 바뀐점

과거에는 웹서버 pc가 따로 있었고, db서버 pc가 따로있었다면, 요즘에는 컴퓨터하나의 컴퓨터라도 컨테이너로 묶어서 뛰워두기만 하면 문제없이 잘 동작하기 떄문에 하드웨어 자원에 상관없이 서버나 db, 프로그램등을 나누어 사용할수 있게 되었다.

위 사진은 44BITS강의를 캡쳐한 사진입니다.

다음 할일

오늘은 쿠버네티스의 개념과 용어 및 특징들에 대해 살펴보았다. 다음시간에는 쿠버네티스 설치와, 사용법 및 예제를 보도록하자.

최종목표.

Kubernetes를 사용해 서비스를 배포 해봅시다.
지난시간까지 쿠버네티스의 개념에 대해 알아보았습니다. 이번시간에는 특정 조건들이 주어지는 서비스를 구현해보도록 하겠습니다.

1. 필수파트

1. 다중 서비스 클러스터를 설정해야합니다.
1. 각 서비스는 전용 컨테이너에서 실행되어야합니다.
1. Alpine Linux를 사용하여 컨테이너를 빌드해야하기 때문입니다.
1. 또한 setup.sh에서 호출되는 Dockerfile이 작성되어 있어야합니다.
1. 사용할 이미지를 직접 빌드해야합니다.
1. 이미 빌드된 이미지를 사용하거나 DockerHub와 같은 서비스를 사용하는 것은 금지되어 있습니다.
1. 하나의 스크립트 파일을 이용해 모든 응용프로그램을 셋업 합니다.
1. 쿠버네틱 웹 데시보가, 너의 클러스터 관리를 도와준다.
모든 컨테이너는 구성 요소중 하나가 충돌하거나, 중지되는 경우 다시 시작해야합니다.
1. 서비스에 대한 각 요청이 로드 밸런서를 사용하여 수행되는지 확인하십시오.
1. FTPS, Grafana, Wordpress, PhpMyAdmin, nginx의 kind는 “LoadBalancer”여야합니다.
1. Inﬂuxdb MySQL의 kind는 “ClusterIP”여야합니다.
1. 다른 엔트리들이 있을 수 있지만 kind가 “NodePort”가 될 수는 없습니다.

2. 로드 밸런서

서비스의 외부 액세스를 관리하는 로드 밸런서가 클러스터의 유일한 엔트리포인트가 될 것입니다.
반드시 서비스에 맞는 포트를 유지해야합니다(Grafana는 IP:3000처럼).
로드 밸런서는 단일 IP를 갖습니다.
클라우드 제공 업체에서 제공하는 로드밸런서를 사용하려고 시도하는 건 쓸모 없어요.
당신은 MetalLB를 봐야합니다.

3. 워드프레스

워드프레스 포트 5050에서 mysql 데이터베이스를 수신하는 웹사이트.
워드프레스와 mysql은 별도의 컨테이너에서 실행되어야 합니다.
워드프레스 웹사이트는 여러사용자 및 관리자를 가질 수 잇습니다.
wordpress는 자체의 nginx서버를 필요로 합니다.
Load Balancer는이 서비스로 직접 리디렉션 할 수 있어야합니다.

4. phpmyadmin

phpmyadmin은 5000포트에서 동작하고, mysql와 연결되어 있어야합니다.
phpmyadmin은 자체 niginx서버가 있어야합니다.
Load Balancer는이 서비스로 직접 리디렉션 할 수 있어야합니다.

5. nginx

콘테이너와 함께 nginx서버는 80, 443에서 수신 대기중입니다.
80포트은 http유형이며, https인 443으로 시스템적인 리다렉션(301)이 있어야 합니다.
표시되는 페이지는 http오류가 아닌 이상 중요하지 않습니다.
이 컨테이너는 리다렉션을 만드는데 대한 /wordpress경로에대한 액세스를 허용합니다. IP:WPPORT로 리디렉션(307)하는 접근을
또한 /phpmyadmin로의 접근을 허용해야합니다. 리버스 프록시로 IP:PMAPORT로.

6. ftps

포트 21을 수신하는 서버.

7. mysql

InﬂuxDB가 터지거나 중지되는 경우에, 데이터가 지속되는지 확인해야합니다.

8. influxDB

InfluxDB 데이터베이스와 grafana플랫폼은 연결되어 있고, grafana는 포트 3000에서 수신 가능합니다
InﬂuxDB와 Grafana는 두 개의 별개 컨테이너에 있어야합니다.
InﬂuxDB가 터지거나 중지되는 경우에, 데이터가 지속되는지 확인해야합니다.

9. Grafana

Grafana는 모든 컨테이너를 모니터링합니다, 서비스 하나당 대시보드 하나를 만들어야합니다.
InﬂuxDB와 Grafana는 두 개의 별개 컨테이너에 있어야합니다.

과제 용어 정리

1. nginx란?

웹 서버에 10,000개의 클라이언트의 접속을 동시에 다룰수 있는 기술적인 문제(apachedml c10k problem)를 해결하기 위해 만든 Event-driven구조의 http, Reverser Proxy, IMAP/POP PROXY server를 제공하는 오픈 소스 프로그램.
대표적인 웹서버로 대두되는 두개의 서버 apache와 nginx가 있습니다.
웹서버는 해당 서비스의 트래픽을 감당해야하는 역활이기에, 선택할때 신중히 결정해야한다.

apache 특징

apache의 경우 거의 모든 os와 지원이되고, 문서화 및 통합 지원 이점이 있습니다.
웹서버 자체내에서 동적으로 컨텐츠를 처리합니다.
클라이언트 요청을 처리하기 위해 멀티 스레드 방식을 따릅니다.

nginx 특징

제한된 하드웨어 리소스로도 여러 클라이언트 요청을 동시에 효율적 처리
경량 아키텍처와 높은 동시성이 있습니다.
클라이언트 요청을 이벤트 중심의 접근 방식 사용, 단일 쓰레드를 통해 여러 연결을 처리할수 있습니다.

세부 정리는 오른쪽 글을 참고해주세요. nginx개념과 nginx와 아파치 차이점에 대해 정리한 글이 있습니다.

2. 로드벨런서란?

로드밸런서는 이름에서도 알수 있듯 서버에 가해지는 부하를 분산해주는 장치 또는 기술을 통칭합니다
실습에서는 쿠버네티스로 들어오는 사용자 요청을 좀더 효율적으로 분산하기위해 사용할 겁니다.

사용에 필요한 경우 : 로드밸런싱은 여러 대의 서버를 두고 서비스를 제공하는 분산 처리 시스템에서 필요한 기술입니다. 서비스 규모가 작다면 하나의 서버로 모두 해결하겠지만, 규모가 커지게 되고, 클라이언트수가 늘어나면 기존 서버로는 문제가 생깁니다. 이러한 문제를 해결하기 위해 로드벨런서를 사용합니다. 하지만 부하가 많이 생긴다고 꼭 로드벨런서를 사용하셔야 하는건 아닙니다. 부하의 대처방법은 두가지가 있는데, scale-out의 경우 앞서 설명했던 서버의 개수를 늘려 부하를 분산하는 방법이고, 하나의 서버의 성능을 향상 시켜 해결하는 방법도 있습니다. 이 방법은 scale-up이라고 합니다. 이 글에서는 scale-out으로 부하를 분산할것입니다.

3. wordpress란?

워드프레스란 PHP로 작성된 온라인 오픈 소스 웹사이트 저작 도구입니다.

4. phpmyadmin란?

phpMyAdmin은 MySQL을 월드 와이드 웹 상에서 관리할 목적으로 PHP로 작성한 오픈 소스 도구이다.

mysql을 실행창에서 관리하는거 생각보다 힘든데, phpmyadmin을 사용하면 좀더 쉽게 관리할 수 있다.

5. ftps란?

file transfer protocol security
http와 FTP는 모두 tcp통신을 합니다.
http의 경우 요청이 들어오면, 서버에서 사용자에게 파일을 전송하는 단방향 작업이 이루어지지만,
ftp의 경우 ftp서버와 클라이언트 사이에 서로 파일이 전송이 가능한 양방ㅎㅇ 작업을 합니다.
또한 ftp는 두개의 포트를 이용해 대이터를 주고 받아 대용량 데이터 전송에 용의합니다.(하나는 명령을 내리기 위한 포트, 다른하나는 데이터를 전송하기 위한 포트)
ftps : ssl을 ftp통신에 추가한것, 자세한 설명은 뒤에 ftps를 만들때 첨부.

6. mysql란?

오픈 소스 데이터베이스이며, MySQL AB사가 개발하여 배포/판매하고 있는 데이터베이스(DataBase)이다.
좀더 쉽게 설명하자면 웹 서비스를 구현하는데 필요한 데이터들을 엑셀형태로 보기좋게 정리해주는 역활을 한다.
사실 mysql이라 썼지만, 실습에서는 mariaDB를 사용하려고 한다.
물론 다른 점이 있겟지만, mariaDB의 기반이 mysql인점.
대부분 동작들이 mysql로 진행하는 사람들과 비슷하게 실행 되기 떄문에 별차이 없이 진행할수 있을거다.
mysql은 사용자의 동적 요청이 들어았을때 처리를 해주기 위해 사용했다.
자세한 설명은 아래 실습을 하면서 추가하겠다.

7. influxDB란?

이름에서 볼수 있듯 이또한 db의 한 종류이다.
생각보다 db의 종류는 많다. 자연어 처리(문장을 끊어서 mysql에 저장하면 힘드니까 문장 자체를 db에 저장할떄는 를 하기위해 c++의 map자료형 같은 구조로 되어있는 MongoDB도 있고, key-value 방식으로 저장하는 Redis db도 있다.
influxDB의 경우 시계열 형태, 실시간으로 클라이언트의 정보를 가지고 와서 저장하는 역활을 수행하게 하기 위해 여기서는 influxDB를 사용하였다.

8. Grafana란?

Grafana를 사용하면 저장된 위치에 상관없이 메트릭 을 쿼리, 시각화, 경고 및 이해할 수 있습니다
또한 자체 알럿(Alert)기능을 사용하여 슬랙(Slack), 이메일, 디스코드 등 다양한 채널에 알림을 보낼 수 있다.
솔직히 시각화는 쿠버네티스 dashboard를 통해 어느정도 볼수 있지만, 짱짱 좋았던건, slack이나 디스코드 이메일로 데이터의 상태를 받아볼수 있다는 점이 좋았다.
influxdb로 가지고 온 데이터들을 시각화 시켜 보여준다.

다음시간에 할것.

sh파일을 통해 쿠버네티스 사용해보기, 도커 이미지 파일과 쿠버네티스 yaml파일을 통해 설정하기.

풀이 정리

우선 미니쿠베가 설치 안되어있다면, 설치하기.

~/.zshrc에 아래 코드 추가(미니쿠베파일을 goinfre파일에 설치한다.)
(이건 개인 맥이나 개인 컴퓨터면 안해도 되어요. 42seoul 클러스터 mac인 경우 설정해주세요, 설치 경로 변경)

export MINIKUBE_HOME=~/goinfre

아래 미니쿠베 설치.(만약 brew없으면 brew도 설치하세요.)

brew install minikube

main()
{
	introduce
	minikube_setup
	make_images
	yaml_services
}

메인문은 4가지로 구성되어있다.
1. introduce : sh 파일의 만든이 정보를 넣어줍니다.
2. minikube_setup : 미니쿠베를 시작하고 설정을 해줍니다.
3. make_images : 이미지파일을 만들어 줍니다.
4. yaml_services : yaml파일로 생성한 이미지파일로 pod를 생성해주고, 파드의 오브젝트를 설정합니다.

1. introduce

introduce()
{
	echo -e $GREEN
	echo "by. hoylee, 21-04-21"
	echo "FT_services,start!"

	echo -e $WHITE
	echo -e $CYAN
	echo "=============================================================================================="
	echo -e $WHITE
	echo " 8888888888 88888888888          88        d88888b  8b   d8  88        88888888  8888888"
	echo " 888            888              88        88   88  88   88  88        88        88"
	echo " 888            888              88        88   88  88   88  88        88        88"
	echo " 8888888        888              8888888h  88   88  88   88  88        88888888  8888888"
	echo " 888            888              88888888  88   88  \"888888  88        88        88"
	echo " 888            888              88    88  88   88       8b  88        88        88"
	echo " 888            888              88    88  88   88      8b   8888888b  88        88"
	echo " 888            888   88888888   88    88  d88888b  8888b    88888888  88888888  8888888"
	echo -e $CYAN
	echo "=============================================================================================="
	echo -e $BLUE

	echo -e $CYAN
	echo -e $WHITE
}

2. minikube_setup

minikube_setup()
{

	minikube delete
	minikube start --driver=virtualbox --cpus=2
	minikube addons enable dashboard
	minikube addons list
	more_addons
	echo 😻- complete addons..!
	kubectl apply -f https://raw.githubusercontent.com/metallb/metallb/v0.9.3/manifests/namespace.yaml
	kubectl apply -f https://raw.githubusercontent.com/metallb/metallb/v0.9.3/manifests/metallb.yaml
	kubectl create secret generic -n metallb-system memberlist --from-literal=secretkey="$(openssl rand -base64 128)"
	kubectl apply -f srcs/yaml_metallb/metallb_complete.yaml
	eval $(minikube docker-env)
	echo $DOCKER_HOST
	echo -en $GREEN
	echo "Minikube is ready !"
	echo
}

쿠버네티스를 시작할 가상머신을 virtualbox를 사용합니다. virtualbox를 사용하는 이유는 docker 의 사용환경이 linux환경일 때 더 높은 효율로 자원들을 컨테이너를 만들수 있습니다. 쿠버네티스의 linux가상 머신의 기본툴이 virtualbox입니다. 드라이브 종류
쿠버네티스에서 제공하는 로드벨런스 metallb를 활성화 합니다. addons 추가 설명
추가적으로 metlalb설정 했습니다.
minikube docker-env 을 하는 이유는 내 컴퓨터에 있는 도커 CLI와 쿠버네티스의 docker server 를 연결해줄려고 사용했습니다.
쿠버네티스에는 도커는 있지만, docker server가 내장되어있지만, 이를 컨트롤 하기 위해서 내 로컬호스트의 컴퓨터와 연결해서 미니쿠베 도커에게 요청을 할수 있습니다.

more_addons

more_addons()
{
	echo -e "addons 더 필요한게 있으면 입력하세요, 그냥 진행하려면 enter"
	echo -e "ex) ambassador or auto-pause "
	read word
	while [[ $word != '' ]];
	do
		flag1=1
		for value in "${addons_list[@]}"; do
		    if [ $word == $value ] ; then
				minikube addons enable $word
				minikube addons list
				flag1=2
				echo "add complete $word"
			fi
		done
		if [ $flag1 -eq 1 ] ; then
			echo "==================================================================="
			echo -e $RED"$word is not inside addons. addons list,"
			echo -e $WHITE
			echo "Please input addons name or if you dont need addons just put enter"
			echo "==================================================================="
		fi
		if [ $flag1 -eq 2 ] ; then
			echo -e "addons 더 필요한게 있으면 입력하세요, 그냥 진행하려면 enter"
			echo -e "ex) ambassador or auto-pause "
		fi
		read word
	done
}

여기서는 addons list를 추가적으로 입력 받고 싶으면 입력 받게끔 만들었는데, 과제만 목적이라면 굳이 안해도 괜찮다.
'' 빈 공간을 입력을 받으면 그냥 넘어간다.
addlist에 없는 값을 입력 받으면 잘못된 입력이라고 띄운다.
addon list중에 하나를 입력받으면 활성화된다.

코드 실행 후 사진!

metalLB 설정도 잘 진행 되고 addons에 관련해서 더 활성화 시킬 에드온이 있는지 물어본다.

metallb.yaml

apiVersion: v1
kind: ConfigMap
metadata:
    namespace: metallb-system
    name: config
data:
    config: |
        address-pools:
        - name: default
            protocol: layer2
            addresses:
            - 192.98.100.92-192.98.100.92

컨피그맵은 키-값 쌍으로 기밀이 아닌 데이터를 저장하는 데 사용하는 API 오브젝트이다. 파드는 볼륨에서 환경 변수, 커맨드-라인 인수 또는 구성 파일로 컨피그맵을 사용할 수 있다.
metadta 에서 네임스패이스와 이름을 설정한다.
metalLB란?
layer2 : 이 중 Layer 2 설정은 가장 심플하지만, 노드 하나가 트래픽을 일단 다 받으며 로드밸런싱을 한다음 서비스에 연결된 모든 포드로 트래픽을 분산시키는 방식이라는 특징을 가지고 있습니다

3. make_images

make_images()
{
	images_kind=("nginx"  "wordpress" "mysql" "phpmyadmin" "ftps" "grafana" "influxdb")

	for kind in "${images_kind[@]}"
	do
		echo -en $WHITE
		echo "📲 Building $kind image..."
		echo -en $YELLOW
		docker build -t $kind srcs/$kind/
		echo "$kind === "
		echo -en $GREEN
		echo "📱 success built $kind image !"
		echo
	done
	echo -en $WHITE
}

도커를 이미지를 빌드합니다. 도커 설명은 ft_server때 정리해둔 글이있어요! 많이 봐주세요 ㅠ.ㅠ.도커란?
docker build -t nginx srcs/nginx/ 를 통해 srcs폴더에있는 각각의 dockerfile로 빌드합니다.

색 넣는거 해두면 좋아요. 나중에 sh파일 돌릴 때 빌드마다 노란색으로 구분되서 보여서 실행 상황 보기 편했어요.

yaml_services

yaml_services()
{
	kubectl apply -f srcs/yaml_services/nginx.yaml
	kubectl apply -f srcs/yaml_services/wordpress.yaml
	kubectl apply -f srcs/yaml_services/mysql.yaml
	kubectl apply -f srcs/yaml_services/phpmyadmin.yaml
	kubectl apply -f srcs/yaml_services/ftps.yaml
	kubectl apply -f srcs/yaml_services/grafana.yaml
	kubectl apply -f srcs/yaml_services/influxdb.yaml
}

생성한 이미지파일을 컨테이너로 생성하고, 컨테이너를 묶어 pod를 생성합니다.
여기서는 이번 실습에서 주로 사용되는 kind는 디플로이먼트와 서비스를 사용합니다.
deployment : 이미지파일을 통해 컨테이너를 생성하고 리플리카셋을 통해 하나의 파드에 무슨종류의 컨테이너가 몇개씩 사용할지 정해줍니다. 파드의 설정도 진행해줍니다.
services : 파드를 외부와 연결해주는 오브젝트를 생성합니다.

addons 추가 설명

minikube addons list

dashboard : 클러스터의 웹 UI 툴
efk : 로그분석 툴(Elasticsearch, Fluentd 및 Kibana)
freshpod : 이미지 리빌드시 pod 재시작
gvisor : 컨테이너 런타임을 대체하여 안전하게 pod 실행
heapster : 컴퓨터 리소스 분석 및 클러스터 모니터링
ingress : 쿠버네티스 Ingress 리소스를 기반으로 구축된 NGINX 컨트롤러
logviewer : 경량 로그 툴
metrics-server : 클러스터 자원 사용률 및 활용도를 수집
** addons의 툴은 각자 기능이 있는데, 구글에 검색하면 설명이나옴. 궁금하면 검색 해볼것 **
참고 : https://www.oops4u.com/2372
> addons : 부가 기능은 Kubernetes의 기능을 확장합니다

지난시간에 sh를 틀을 만들며 쿠버네티스를 설정 및 실행해보았다.
metalLB를 yaml파일을 이용해, 쿠버네티스에 적용해두었다.

해야할 일

이제 nginx도커파일 만드는 방법과 생성한 이미지를 쿠버네티스에 pod형태로 생성하는 방법을 알아보자.

docker build -t nginx-alpine srcs/nginx/

-t옵션은 tag임, 이름을 정해줄수 있음.

1. nginx - Dockerfile

빌드명령에 있는 srcs/nginx안에 있는 Dockerfile이다.
alpine linux 공식위키 - nginx 설치방법

FROM	alpine:3.12

LABEL	maintainer="hoylee@student.42seoul.kr"
RUN		echo "http://dl-2.alpinelinux.org/alpine/edge/community" >> /etc/apk/repositories
RUN     apk update && apk add --no-cache nginx openssl telegraf

COPY ft_server.sh default.conf telegraf.conf ./
COPY telegraf.conf /etc/telegraf/
COPY ./healthy.sh /tmp/healthy.sh
EXPOSE 80 443

ENTRYPOINT sh ft_server.sh

과제에서 alpine os를 사용하라고 해서 알파인 os를 사용햇다.

알파인 리눅스의 가장 큰 특징은 바로 이 '가볍다'이다. 커널을 제외한 용량이 8MB 라고 하는데, 확실히 우분투 등의 다른 리눅스 배포판과 비교했을 때 상대적으로 가벼운 것을 알 수 있다. 알파인 리눅스는 가볍게 만들기 위해서 다른 배포판들 대비 아래와 같은 차이점이 있다.
세번 째 줄에, alpinelunux의 패키지를 설치하는게 있는데, 이건, 3.12버전으로 telegraf를 설치하려니까, 3.12에서는 텔레그래프를 지원해주지 않았다.
그래서 알파인 커뮤니티에서 확장을 지원해주는 패키지를 설치해줬다.
apk nginx : nginx파드 부분이니까 당연히 nginx가 필요해서 설치해주었다.
apk openssl : http를 https형태로 바꾸어 줄려고 추가해 주었다. 모른다면 꼭 한번 보고 넘어가자 ssl 이란?
도커 파일을 만들다 보면 주로 etc폴더에 conf파일을 넣는다.
443포트와 80포트를 쓰겠다고 선언하고,
ft_server에서 사용했던 설정들을 그대로 설정해주었다.
healthy.sh 파일은 livenessprobe를 사용하려고 추가해주었다.
telegraf 란? : 원하는 지표들을 수직하여 지정한 곳으로 보내주는 에이전트를 말합니다. 실습에서는 influxDB로 데이터를 송신할려고 사용했습니다.

etc특징 : /etc와 /usr/etc 디렉토리는 시스템의 부팅, 셧다운 시에 필요한 파일들과 시스템의 전반에 걸친 설정 파일들 및 초기 스크립트 파일들이 있다. 시스템에 어떠한 문제가 발생한다거나, 시스템 전체 환경에 관한 설정을 바꾸기 위해서는 이들 디렉토리내에 포함되어 있는 파일들에 대하여 잘 알아야 한다. etc 폴더란?

livenessProbe: 컨테이너 프로브중 하나이다. 실습에선, 해당 컨테이너의 prosses가 정상적으로 작동중인지 확인한다. 만약 활성 프로세스가 정상 작동하지 않는다면, kubelet은 컨테이너를 죽이고, 해당 컨테이너는 재시작 정책의 대상이 된다. 만약 컨테이너가 활성 프로브를 제공하지 않는 경우, 기본 상태는 Success이다.
Success: 컨테이너가 진단을 통과함.
Failure: 컨테이너가 진단에 실패함.
Unknown: 진단 자체가 실패하였으므로 아무런 액션도 수행되면 안됨.

컨테이너 프로브 : 프로브는 컨테이너에서 kubelet에 의해 주기적으로 수행되는 진단(diagnostic)이다. livenessProbe, readinessProbe, startupProbe 3가지 종류가 있다.

livenessProbe: 컨테이너가 동작 중인지 여부를 나타낸다. 만약 활성 프로브(liveness probe)에 실패한다면, kubelet은 컨테이너를 죽이고, 해당 컨테이너는 재시작 정책의 대상이 된다.
startupProbe: 컨테이너 내의 애플리케이션이 시작되었는지를 나타낸다. 스타트업 프로브(startup probe)가 주어진 경우, 성공할 때까지 다른 나머지 프로브는 활성화되지 않는다.
readinessProbe: 컨테이너가 요청을 처리할 준비가 되었는지 여부를 나타낸다. 만약 준비성 프로브(readiness probe)가 실패한다면, 엔드포인트 컨트롤러는 파드에 연관된 모든 서비스들의 엔드포인트에서 파드의 IP주소를 제거한다.
livenessProbe를 사용한 이유 : 실습인 서비스를 운영하면서 프로세스 작동이 정상적으로 동작하고 있지않으면, 서비스중 하나에 문제가 생긴경우다. 일정 간격마다 프로세스 동작여부를 확인하고 문제가 생겼을때 해당 파드를 끈다면 livenessprobe에서도 재시작을 시켜주고 만약 잘못 켜진다고 해도, yaml파일로 설정을 해두었기떄문에 마스터 노드에서 안전하게 재시작을 해줄거라 livenessprobe를 사용햇따.

2. ft_server.sh

#!/bin/bash

mkdir -p /run/nginx

openssl req -newkey rsa:4096 -days 365 -nodes -x509 -subj "/C=KR/ST=Seoul/L=Seoul/O=42Seoul/OU=AITEAM/CN=localhost" -keyout localhost.dev.key -out localhost.dev.crt
mv localhost.dev.crt etc/ssl/certs/
mv localhost.dev.key etc/ssl/private/
chmod 600 etc/ssl/certs/localhost.dev.crt etc/ssl/private/localhost.dev.key

echo "hellow word" >> index.html
mv index.html /var/www/localhost/htdocs
cp -rp ./default.conf /etc/nginx/conf.d
telegraf & nginx -g 'daemon off;'

#!/bin/bash는 bash를 사용한다고 선언을 하는것.
그리고 ssh를 위해 crt와 key를 만들어 넣어주고, 기본설정을 위해 conf.d파일에 defalut를 넣어주엇다.
마지막으로 nginx -g "daemon off;"를 해주었든데, 이 명령어는 damon을 꺼주는 명령어다.
default.cofd 파일과 index.html파일은 아래에 함수로 빼두었다.
동기적 비동기적 설명!!!! 아래 사진도 여기서 가지고 왔어요.

damon off를 해주는 이유는, 쿠버네티스에서 컨테이너를 실행할 때, sudo docker run -d -p 외부포트:내부포트 이미지파일명 처럼 -d 옵션을 줘서 해당 컨테이너가 백그라운드로 돌아가게 만든다. -d옵션으로 백그라운드 하게 되면, 해당 클러스터를 데몬으로 프로세스를 관리하게 되는데, 이떄 데몬의 자식프로세스로 nginx가 생성이 된다. 문제는 이 nginx가 백그라운드로 돌아가게되는 특성이 잇는데, 이렇게 되면 데몬이 자식 프로세스인 nginx를 탐색할수 없게 되고, 추적을 못하게 되므로 해당 nginx가 exit되게 된다. 그렇기에 nginx를 nginx -g "daemon off; 명령어로 forground시켜준다.

데몬이란? : 멀티태스킹 운영 체제에서 데몬은 사용자가 직접적으로 제어하지 않고, 백그라운드에서 돌면서 여러 작업을 하는 프로그램을 말한다.

3. default.conf

server {
		listen 80;
		listen [::]:80;

		return 301 https://$host$request_uri;
}

server {
		listen 443 ssl ;
		listen [::]:443 ssl ;

		ssl on;
		ssl_certificate /etc/ssl/certs/localhost.dev.crt;
		ssl_certificate_key /etc/ssl/private/localhost.dev.key;

		root /var/www/localhost/htdocs;

		index index.html;

	    location /wordpress {
	            return 307 http://192.168.99.10:5050;
	    }

	    location /phpmyadmin/ {
		    	proxy_pass https://192.168.99.10:5000/;
	    }


		location / {
			try_files $uri $uri/ =400;
		}

}

보안을 위해 80포트로 입력되는 요청을 https로 리다이렉션 시켜주엇습니다 .
실습에서 wordpress 리다이렉션을, phpmyadmin의 경우 리버시 프록시를 요청했습니다.
다른 서버의 정보를 프록시를 통해 받아오는 부류의 프록시를 뜻한다.
리버스 프록시란? : 요청하는 Endpoint는 접근하고자 하는 최종 목적지 서버가 아닌, 리버스 프록시가 된다.
아래 그림에서 볼수 있듯이, 리버시 프록시는 사용자가, 클라이언트에 바로 접속하는게 아니라, 리버스 프록시에 접속을하고 리버스 프록시가 사용자를 대신해서 클라이언트에 접속한다. 사용자는 리버스 프록시에 접속 된 상태이기 떄문에, end point는 리버스 프록시의 도메인을 사용자에게 반환한다.

포워드 프록시와 리버스 프록시 차이 : Forward Proxy 는 클라이언트가 요청하는 End Point 가 실제 서버 도메인이고 프록시는 둘 사이의 통신을 담당해준다.

4. index.html

HELLOW WORD

그냥 이것 만 넣어주었다. html에는 자신이 원하는 html파일을 만들어 넣어주면된다.

5. telegraf.conf

[global_tags]
[agent]
  interval = "10s"
  round_interval = true
  metric_batch_size = 1000
  metric_buffer_limit = 10000
  collection_jitter = "0s"
  flush_interval = "10s"
  flush_jitter = "0s"
  precision = ""
  hostname = ""
  omit_hostname = false
[[outputs.influxdb]]
  urls = ["http://influxdb-service:8086"]
  database = "nginx"
[[inputs.cpu]]
  percpu = true
  totalcpu = true
  collect_cpu_time = false
  report_active = false
[[inputs.disk]]
  ignore_fs = ["tmpfs", "devtmpfs", "devfs", "iso9660", "overlay", "aufs", "squashfs"]
[[inputs.diskio]]
[[inputs.kernel]]
[[inputs.mem]]
[[inputs.processes]]
[[inputs.swap]]
[[inputs.system]]

telegraf기본 형식 [] 이런형식으로 상황마다 나눈다.
몇초마다 influxDB로 송신할것인지. 한번에 송신할수 있는 데이터 크기 등을 설정 할수 있다.
다른건 default값으로 설정을했다.
다른 부분은 [outpush.influxdb]에서, influxdb의 주소값을 넣고, 데이터 베이스 이름을 nginx라고 지어주었다. 다른 pod (wordpress, myphpadmin 등등) influxDB와 연결된 파드들에도 telegraf.conf파일로 설정해주었다.

6. nginx.yaml

자 이제, nginx의 images파일을 만들었다.
이제 만든 이미지파일을 이용해, 쿠버네트스에서 컨테이너를 만들고, 파드 형태로 묶어 외부 통신이 되도록 설정하자.

kubectl apply -f srcs/yaml_services/nginx.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 80
          name: http
        - containerPort: 443
          name: https
        livenessProbe:
          exec:
              command:
              - sh
              - /tmp/healthy.sh
          initialDelaySeconds: 14
          periodSeconds: 5
---
apiVersion: v1
kind: Service
metadata:
  annotations:
    metallb.universe.tf/allow-shared-ip: wp
  name: service-nginx
spec:
  selector:
    app: nginx
  ports:
    - name: http
      protocol: TCP
      port: 80
      targetPort: 80
    - name: https
      protocol: TCP
      port: 443
      targetPort: 443
  type: LoadBalancer
  loadBalancerIP: 192.168.99.10

앞선 설명에도 있었지만, deploymen를 통해, 이미지 파일을 컨테이너로 만들고, 파드형태로 묶어준다.
services를 통해 생성한 pod를 로드벨런스와 연결할수 있도록 오브젝트를 생성한다.
디플로이먼트에서 리플리카셋을 설정할수 있지만, 실습에선 하나의 파드만 생성할거라, 따로 입력 안해주어도 1개로 설정된다.
대충 설명하면, deployment를 생성할건데 이름은 nginx-deployment, selector에서 실행중인 파드중 데이터가 일치하는 파드를 찾고 파드가 일치하면 개수를 세서 리플리카셋보다, 실행중인파드가 적으면 추가적으로 파드를 생성해줍니다.
이떄 생성해주는 파드의 정보는 spec에서 정해줍니다.
서비스에서 설정한 파드의 외부 연결 오브젝트를 생성해줍니다.
여기서 사용자와 파드사이에 통신은 tcp/ip를 사용해서 통신합니다.

사진 참조
tcp통신은 뒤에서 좀더 상세하게 다루도록 하겠습니다
마지막으로 로드벨런스와 연결해주고 끝을 내주었습니다.

다음해야 할 일

워드프레스, myphpadmin dockerfile 생성
이미지 빌드와 쿠버네티스 적용

해야할일

워드프레스에 컨테이너에 nginx서버를 사용, wordpress를 돌려야한다.
wordpress를 동적요청도 처리하기 위해 mariaDB와 연동을 시켜주자.
phpmyadmin도 비슷하다.
mariaDB의 데이터들을 좀더 쉽게관리하는 phpmyadmin을 설치하고 mariaDB에 연결해주자.

wordpress 설정 조건

워드프레스 웹 사이트는 5050 포트를 수신
워드프레스는 MySQL 데이터베이스랑 같이 작동
두 서비스 모두 별도의 컨테이너에서 실행되어야합니다.
워드프레스 웹 사이트에는 여러 사용자와 관리자를 갖습니다.
워드프레스 자체 nginx 서버가 필요합니다.
로드 밸런서는 이 서비스로 직접 리디렉션 할 수 있어야 합니다.
과제해석 참고

srcs/wordpress/dockerfile

alpine linux 공홈위키 - wordpress 설치방법

FROM alpine:3.12
RUN apk update && apk upgrade && \
	apk add --no-cache nginx php7 php7-fpm php7-opcache php7-gd php7-mysqli \
	php7-zlib php7-curl php7-mbstring php7-json php7-session
COPY ft_wordpress.sh default.conf wp-config.php ./

RUN adduser -D -g 'www' www && mkdir -p /www \
	&& chown -R www:www /var/lib/nginx && chown -R www:www /www

RUN	mkdir -p /run/nginx

ADD https://wordpress.org/latest.tar.gz .
RUN tar -xvf latest.tar.gz && \
	mv wordpress /www && \
	mv wp-config.php /www/ && \
	rm -f latest.tar.gz

ADD https://dl.influxdata.com/telegraf/releases/telegraf-1.6.3-static_linux_amd64.tar.gz ./
RUN tar -C . -xzf telegraf-1.6.3-static_linux_amd64.tar.gz && \
        chmod +x telegraf/* && \
        cp telegraf/telegraf /usr/bin/ && \
        rm -rf *.tar.gz* telegraf/

COPY telegraf.conf /etc/telegraf/
COPY ./healthy.sh /tmp/healthy.sh
RUN mv ./default.conf /etc/nginx/conf.d/default.conf

EXPOSE 5050

ENTRYPOINT sh ft_wordpress.sh

wordpress의 독자적인 nginx를 설치하라고 해서 nginx를 설치하였고, 포트번호는 5050으로 지정해서 설정해 주었다. dockerfile에서의 설정은 저번에 nginx에서 설정과 동일하다.
add를 통해, 워드프레스 홈페이지에서 파일을 다운받아주고, 아래 코드를 통해,압출을 풀고 www폴더에 넣어주었다. (왜 www 폴더에 넣는지, 이유는 모르겠다. 워드프레스에서 그렇게 설정한건데, www폴더가 뭐하는 폴더인지 찾아보면 알수 있지 않을까? 아 웹이 이래서 싫다. 논리 없이 그냥 다 약속이다. 약속약속) 도커파일 만들떄 참고 한 사이트
healthy.sh 는 livenessprobe를 위해 설치해주었고, telegraf는 influxDB를 위해 설치했다.
wp-config.php : 여기서 mariaDB와 연결을 해준다.
필요한 툴 설치

apk add --no-cache php7 php7-fpm php7-opcache php7-gd php7-mysqli \
	php7-zlib php7-curl php7-mbstring php7-json php7-session

php7-fpm : PHP FastCGI Process Manger의 약자로, CGI보다 빠른 버전이라고 말할 수 있습니다.
php7-opcache : php를 bytecode로 컴파일하고, 해당 데이터를 공유메모리에 저장 시켜 성능을향상시키는 모듈
php7-gd : gd는 png, jpg, gif 등 을 다루는 library
php7-mysqli : mysqli는 뭔가 했더니 mysql보다 더 빠르고, 더 안전한 쿼리문이라는거
대충 이런식이다. 나도 알고 설치를한게 아니라, alpine 공식 홈페이지에서 wordpress를 설치할떄 필요한 설치 자료들을 보고 따라했다. (alpine 공식 wiki)[https://wiki.alpinelinux.org/wiki/WordPress]

cgi란? : CGI란 공통 게이트웨이 인터페이스(Common Gateway Interface)의 약어로, 웹서버와 외부 프로그램 사이에서 정보를 주고받는 방법이나 규약들을 말한다.
우리가 사용하는 nginx, apach 등 서버들은 클라이언트에서 요청이 들어오면 해당 요청에 맞는 정보를 제공하는게 일반적인 서버(정적인 작업만 가능)의 기능이다.
문제는 이러한 정적인 작업만 가능하면, 회원가입을 할 떄 사용자가 입력한 데이터들이나 인터넷 주문을 할떄 필요한 사용자 정보들을 db에 저장할수 없다. 이러한 문제점을 해결하기 위해서는, 외부 프로그램과 정보를 주고받을 규약이 필요했고, 이것을 cgi라고 한다.
참고자료 - cgi란 무엇인가?, 웹서버와 웹 어플리케이션 서버 차이, 위키 cgi란?

srcs/wordpress/default.conf

server {
	listen   5050;
	listen   [::]:5050;
   root 		/www/wordpress;
   index		index.html index.htm index.php;
   location ~ \.php$ {
      fastcgi_pass      127.0.0.1:9000;
      fastcgi_index     index.php;
      include           fastcgi.conf;
   }
   location / {
      try_files         $uri $uri/ =404;
   }
}

nginx랑 다른 점은 fastcgi를 추가했는데, 이를통해 php-fpm과 nginx가 소켓통신으로 연결되게 된다. nginx로 전해지는 php파일을 좀더 빨리 html형식으로 변환시켜준다.

php란? : 원래는 동적 웹 페이지를 만들기 위해 설계되었으며 이를 구현하기 위해 PHP로 작성된 코드를 HTML 소스 문서 안에 넣으면 PHP 처리 기능이 있는 웹 서버에서 해당 코드를 인식하여 작성자가 원하는 웹 페이지를 생성한다.

fastcgi란? : CGI는 데이터 처리요청이 있을 때마다 매번 프로세서를 실행해야만 했다. FastCGI는 매번 프로세스를 만들지 않고, 미리 만들어 놓은 프로세스와 데이터를 주고 받음으로서 CGI 보다 더 효츌적으로 작동한다. 이러한 해결책으로 CGI를 진화시킨 기술로 FastCGI 입니다 20년 넘는 기간 동안 표준이 되었고 대부분의 웹서버(Nginx, IIS, Apache)가 FastCGI 기능을 제공합니다

srcs/wordpress/wp-config.php

<?php
/**
 * The base configuration for WordPress
 *
 * The wp-config.php creation script uses this file during the
 * installation. You don't have to use the web site, you can
 * copy this file to "wp-config.php" and fill in the values.
 *
 * This file contains the following configurations:
 *
 * * MySQL settings
 * * Secret keys
 * * Database table prefix
 * * ABSPATH
 *
 * @link https://wordpress.org/support/article/editing-wp-config-php/
 *
 * @package WordPress
 */

// ** MySQL settings - You can get this info from your web host ** //
/** The name of the database for WordPress */
define( 'DB_NAME', 'wordpress' );

/** MySQL database username */
define( 'DB_USER', 'hoylee' );

/** MySQL database password */
define( 'DB_PASSWORD', 'hoylee' );

/** MySQL hostname */
define( 'DB_HOST', 'cip-mariadb' );
define('WP_HOME', 'http://192.168.99.10:5050' );
define('WP_SITEURL', 'http://192.168.99.10:5050' );
/** Database Charset to use in creating database tables. */
define( 'DB_CHARSET', 'utf8' );

/** The Database Collate type. Don't change this if in doubt. */
define( 'DB_COLLATE', '' );

db와 wordpress를 연결시킨다.
'DB_HOST', 'cip-mariadb' 이렇게 설정했는데, DB_HOST에 mariadb의 services이름을 적어주었다. 그리고 접속할떄 필요한 아이디와 비밀번호, 를 설정해주었다. 이를 통해, mariadb와 wordpress사이에 tcp/ip통신을 구축했다. 같은 쿠버네티스 상의 파드들이지만, tcp/ip로 통신을 시켰다. 다른 좋은 방법도 있을까?

wordpress.yalm

이제 이미지 파일은 모두 만들었고 생성한 이미지 파일을 yaml파일을 통해 container들을 생성해주고 생성된 컨테이너를 service를 통해 관리 및 외부 통신을 해보자.

wordpres.yalm_service

apiVersion: v1
kind: Service
metadata:
  name: service-wordpress
  labels:
    app: wordpress
  annotations:
    metallb.universe.tf/allow-shared-ip: wp
spec:
  externalTrafficPolicy: Cluster
  type: LoadBalancer
  loadBalancerIP: 192.168.99.10
  ports:
    - port: 5050
      name: http
      protocol: TCP
      targetPort: 5050
        # 셀렉터에 해당하는 라벨로트래픽을 보내준다.
        #  targetport는 특정포드로 접근하기 위핸 포트 넘버, (deployment 에서 설정한 pod의 포트 넘버)
  selector:
    app: wordpress

nginx와 같으므로 설명은 생략하겟습니다.

wordpres.yalm_Deployment

apiVersion: apps/v1
kind: Deployment
metadata:
  name: wordpress
spec:
  selector:
    matchLabels:
      app: wordpress
  replicas: 1
  strategy:
    type: Recreate
  template:
    metadata:
      labels:
        app: wordpress
    spec:
      containers:
        - name: wordpress
          image: wordpress
          imagePullPolicy: Never
          ports:
            - containerPort: 5050
          livenessProbe:
            exec:
                command:
                - sh
                - /tmp/healthy.sh
            initialDelaySeconds: 8
            periodSeconds: 5

이 친구도 nginx와 같이 사용했습니다.

phpmyadmin

alpine linux 공식위키 - phpmyadmin 설치방법

FROM alpine:3.12

RUN	echo "http://dl-2.alpinelinux.org/alpine/edge/community" >> /etc/apk/repositories

RUN mkdir -p /run/nginx

RUN	apk update && apk upgrade
RUN		apk add nginx openrc openssl telegraf \
		php7 php7-fpm php7-mysqli php7-xml php7-simplexml php7-json \
    	php7-iconv php7-tokenizer php7-xmlwriter php7-session php7-mbstring

COPY nginx.conf /etc/nginx/conf.d/default.conf
COPY telegraf.conf /etc/telegraf/
COPY ./healthy.sh /tmp/healthy.sh

RUN wget http://files.directadmin.com/services/all/phpMyAdmin/phpMyAdmin-5.0.2-all-languages.tar.gz
RUN tar -zxvf phpMyAdmin-5.0.2-all-languages.tar.gz
RUN rm phpMyAdmin-5.0.2-all-languages.tar.gz
RUN mv phpMyAdmin-5.0.2-all-languages phpmyadmin

COPY config.inc.php phpmyadmin/config.inc.php
RUN chmod 644 phpmyadmin/config.inc.php

COPY	./start_php.sh .
EXPOSE	5000

CMD		sh start_php.sh

nginx랑 phpmyadmin에서와 큰 차이가 없습니다.
openrc는 alpine os가 경량화된 os이다보니, 프로세스를 제어하는 기본 명령이 없습니다.
openrc를 통해 프로세스 재시작 이나 프로세스 종료를 시작하기 위해 추가했습니다.

start_php.sh

#!/bin/sh

openssl req -newkey rsa:4096 -days 365 -nodes -x509 -subj "/C=KR/ST=Seoul/L=Seoul/O=42Seoul/OU=AITEAM/CN=localhost" -keyout localhost.dev.key -out localhost.dev.crt
mv localhost.dev.crt etc/ssl/certs/
mv localhost.dev.key etc/ssl/private/
chmod 600 etc/ssl/certs/localhost.dev.crt etc/ssl/private/localhost.dev.key
telegraf & /usr/sbin/php-fpm7 --nodaemonize & nginx -g 'daemon off;'

크게 다르지 않습니다. 설명은 생략하겟씁니다.

phpmyadmin/config.inc.php

<?php
/* vim: set expandtab sw=4 ts=4 sts=4: */

/**
 * This is needed for cookie based authentication to encrypt password in
 * cookie. Needs to be 32 chars long.
 */
$cfg['blowfish_secret'] = 'hello world'; /* YOU MUST FILL IN THIS FOR COOKIE AUTH! */

/**
 * Servers configuration
 */
$i = 0;

/**
 * First server
 */
$i++;
/* Authentication type */
$cfg['Servers'][$i]['auth_type'] = 'cookie';
/* Server parameters */
$cfg['Servers'][$i]['host'] = 'service-mariadb';
$cfg['Servers'][$i]['port'] = '3306';
$cfg['Servers'][$i]['user'] = 'admin';
$cfg['Servers'][$i]['password'] = 'password';
$cfg['Servers'][$i]['compress'] = false;
$cfg['Servers'][$i]['AllowNoPassword'] = false;

/**
 * Directories for saving/loading files from server
 */
$cfg['UploadDir'] = '';
$cfg['SaveDir'] = '';

mariaDB와 연결해주기위해 사용햇습니다.
다른 부분들도 앞서 진행했던, nginx 와 wordpress와 비슷해서 다른 설명은 생략하겟씁니다.

mariadb 목표

지난시간까지 nginx, wordpress, phpmyadmin을 올렸습니다.
wordpress를 통해, 서버에 회원정보 입력이나, 우편번호 입력등 동적인 입력들을 수행하려면 저장 장소가 필요하다.
이번 시간에는 php같은 응용계층에서 입력 받은 데이터를 저장소인 mySQL로 저장하는 작업을 수행해보자.

워드프레스는 MySQL 데이터베이스랑 같이 작동

The WordPress website will have
several users and an administrator.

저는 mysql대신 mariadb를 사용했습니다. 제 글에선 mysql을 mariadb로 생각하시면 될거 같습니다.

과제는 mysql을 사용하는것이였지만, 저는 몰래 mariaDB를 사용햇습니다. ㅠ..ㅠ

marieadb이미지 빌드

docker build -t MySQL srcs/MySQL/

srcs/MySQL/dockerfile

FROM alpine:3.12

RUN apk update && apk upgrade \
    && apk add mariadb mariadb-client curl \
    && apk add openrc \
    && rm -rf /var/cache/apk/*

ADD https://dl.influxdata.com/telegraf/releases/telegraf-1.6.3-static_linux_amd64.tar.gz ./
RUN tar -C . -xzf telegraf-1.6.3-static_linux_amd64.tar.gz && \
        chmod +x telegraf/* && \
        cp telegraf/telegraf /usr/bin/ && \
        rm -rf *.tar.gz* telegraf/
COPY telegraf.conf /etc/telegraf/

COPY my.cnf /etc/
COPY start_mariadb.sh .
COPY hoylee_db.sql .
COPY create_db .
COPY ./healthy.sh /tmp/healthy.sh
VOLUME ["/var/lib/mysql"]

EXPOSE 3306

ENTRYPOINT sh start_mariadb.sh

다른 내용들은 비슷합니다.
mariadb, mariadb-client 마리아 디비 서버와 클라이언트 두가지를 설치해줍니다. 이렇게 두가지를 설치하는 이유는, mariadb 서버는 말그대로, 실질적인 데이터를 저장하기 위한 공간이며, 클라이언트는 사용자가 서버에 접근하기 위한 라이브러리가 클라이언트 입니다.
mariaDB클라이언트로 입력하는 제어신호를 mariaDB서버로 통신해야합니다. 반대로 DB 서버의 데이터 시트나 정보들을 클라이언트로 받기도 합니다. 이러한 mariaDB서버와 클라이언트 사이의 통신은 소켓 통신으로 이루어집니다. 자세한 내용은 뒤에서 다루겠습니다.
my.cnf : mariaDB의 설정 파일을 my.cnf라고 한다. 아래에 정리해 두었다.
VOLUME ["/var/lib/mysql"] : 저장공간을 위해 볼륨 폴더를 설정했습니다. 이폴더를 쿠버네티스에서 제공하는 PersistentVolumeClaim 으로 PersistentVolume과 연결해주도록 하겠습니다. (연결은 yaml파일에서 진행합니다.)

추가적으로 my.cnf 에서도 datadir 경로를 설저합니다.

my.cnf

my.cnf 는 mariadb(mysql server)의 configure파일이다. mariadb서버와 클라이언트가 소켓통신을 해야하고, php(wordpress)와도 통신을 해야하는데, 이에 필요한 데이터들을 설정해준다.
my.cnf란?

[mysqld]
socket=/run/mysqld/mysqld.sock
port=3306
datadir=/var/lib/mysql
user=root
bind-address=0.0.0.0
skip-networking=false

소켓통신을 하는데 필요한것, ip,port이므로 두가지를 입력해준다. ip는 127.0.0.1로 자기자신 아이피만 허용해주어도 되고 0.0.0.0 으로 모든 아이피를 허용해도 된다. (여기서는!) myriadb와 클라이언트 소켓통신?
일반적으로 클라이언트의 포트는 3306이므로 3306포트를 지정했다.
여기서 소켓에 대한게 나온다. 소켓이 뭘까!!!?
소켓은 소프트웨어로 작성된 통신 접속점이라고 할 수 있는데 네트웍 응용 프로그램은 소켓을 통하여 통신망으로 데이터를 송수신하게 된다.

mysql.sock은 Unix Domain Socket 입니다.
unix domain soket은 컴퓨터가 다른 프로세스와는 통신할수 없고, 같은 컴퓨터에 있는 프로세스끼리 통신이 가능함. (tcp/ip보다 속도가 빠르다., 여기서는 mariadb서버와 mariadb클라이언트 사이를 연결하는데 사용한다., 아무래도 DB데이터 이다보니 소켓중에서도 tcp/ip를 쓰는 통신이 아닌 내부망끼리 연결하는 통신을 사용한거 같다. 추측입니다.)

사진참조

참고 : 소켓이란?

tcp/ip연결는 4계의 계층으로 연결되어 있다. 그림참조 7계층 설명
우리가 만든 워드프레스와 mysql은 응용계층에 해당하고, 이 두개의 응용 개층끼리 통신을 하기 위해서는 아래와 같이 캡슐화 되는 작업이 필요하다.캡슐화그림참조
만약 wordpress에서 marieaDB로 tcp/ip통신을 한다면 wordpress의 http 정보 -> 전송계층형태로 캠슐화 -> 네트워크 계층형태 캡슐화 -> 데이터링크 계층형태 캡슐화 -> 라우터 -> mariadb 데이터링크 -> mariadb 네트워크 계층 -> 전송계층 -> mariadb 응용계층 순으로 정보를 전달하게 된다. osi 7 계층 설명
datadir=/var/lib/mysql : 데이터 디렉토리 경로 지정

데이터 디렉토리란? : 데이터 디렉토리는 시스템 카탈로그에 수록된 데이터를 접근하기 위한 정보를 유지하는 시스템데이터디렉토리란? 참고

시스템 디렉토리란? : 시스템 카탈로그는 데이터베이스 관리자의 도구로, 데이터베이스에 저장되어 있는 모든 데이터 개체들에 대한 정의나 명세에 대한 정보가 수록되어 있는 시스템 테이블이다.시스템 디렉토리?

var/lib 폴더 = 해당 계층은 어플리케이션이나 시스템에 관련된 상태 정보를 수행한다. 상태 정보라 함은 프로그램이 실행되는 동한 수정하고 특정 호스트의 호출과 관련된 데이터를 말한다.var 폴더 정리 사이트 good!

bind-address=0.0.0.0 : bind-address는 mysql server의 listen ip로 맞추어 주면된다. (sudo net stat -ntlp |grep mysqld) 라고 입력해서 나오는 아이피로 입력해도 되고, 지금처럼 0.0.0.0으로 입력해줘도 된다. 클라이언트랑 서버사이에 연결을 위해 입력함.
skip-networking=false : skip-networking 이 지시가 활성화 되면, 오로지 sock 파일로만 통신 됨(우린 포트로 클라이언트랑 통신함.)

start_mariadb.sh

rc default
/usr/bin/telegraf &
/etc/init.d/mariadb setup
rc-service mariadb start
mysql -u root mysql < create_db
mysql -u root my_db < hoylee_db.sql
rc-service mariadb stop
/usr/bin/mysqld_safe & telegraf & /usr/bin/mysqld_safe

mariadb를 설치 해주고, rc를 통해 시작함. (debian os에서는 service mariadb start 이렇게 바로 실행햇는데 alpine에서는 바로 실행할수가 없어서 openrc를 이용함)

앞에도 있는 내용이지만 한번더..
실행한 mysql의 아이디와 설정들을 진행해주고, 설정한 계정을 적용시키기 위해,rc-service mariadb stop를통해 중지시키고 /usr/bin/mysqld_safe로 재시작해준다.
/usr/bin/mysqld_safe 명령어는 mariadb를 실행하는 명령어

create_db

mysql -u root mysql < create_db

CREATE DATABASE my_db;
CREATE USER 'admin'@'%' IDENTIFIED BY 'password';
GRANT ALL ON my_db.* TO 'admin'@'%' WITH GRANT OPTION;

mariadb 사용법

디비를 생성하고 아이디와 비밀번호를 입력해줬다.

hoylee_db.sql

The WordPress website will have several users and an administrator.
과제에서 워드프레스에 접속했을때 유저와 관리자가 있어야한다고 했다.
mysql과 wordpress가 연결된 상태에서 wordpress에 접속하면, sql파일이 생성되는데 이 파일에 관리자 사용자를 추가한 생태로 저장해서 marieadb 이미지를 구울때 업로드 해주는 원리다.(아래와 같이 유저를 추가한 상태로, phpmyadmin 접속)
phpmyadmin 에서 내보내기를 통해 파일을 다운받고, 원하이름으로 파일 명을 변경하면 된다. 나는 hoylee_db.sql로 변경했다.
mysql -u root my_db < hoylee_db.sql 그후 파일을 이렇게 절대 권한으로 들어가서 써주면 적용이된다.

deplyment, service, persistentvolumeclaim

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mariadb-volume-claim
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 500Mi
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: mariadb-deploy
spec:
  selector:
    matchLabels:
      app: mariadb
  replicas: 1
  strategy:
    type: Recreate
  template:
    metadata:
      labels:
        app: mariadb
    spec:
      containers:
        - name: mariadb-container
          image: mysql
          imagePullPolicy: Never
          ports:
            - containerPort: 3306
          volumeMounts:
            - mountPath: "/var/lib/mysql"
              name: mariadb-volume
      volumes:
        - name: mariadb-volume
          persistentVolumeClaim:
            claimName: mariadb-volume-claim
---
apiVersion: v1
kind: Service
metadata:
  name: cip-mariadb
spec:
  type: ClusterIP
  ports:
    - port: 3306
      name: mariadb
      targetPort: 3306
  selector:
    app: mariadb

PersistentVolumeClaim 이란? 일반적으로 디스크 볼륨을 설정하려면 물리적 디스크를 생성해야한다. 쿠버네티스는 물리적 디스크를 생성하는 복잡한 과정을 추상화를 통해서 간단하게 개발자가 볼륨을 생성하는 기능을 제공하는데 그건 바로 PersistentVolumeClaim와 PersistentVolume 을 이용하는 방법이다.

시스템 관리자가 실제 물리 디스크를 생성한 후에, 이 디스크를 PersistentVolume이라는 이름으로 쿠버네티스에 등록한다.
개발자는 Pod를 생성할때, 볼륨을 정의하고, 이 볼륨 정의 부분에 물리적 디스크에 대한 특성을 정의하는 것이 아니라 PVC를 지정하여, 관리자가 생성한 PV와 연결한다.
조대협님의 persistentvolume참고

nginx, wordpress와 차이점은, PersistentVolumeClaim 이 생겼다.
mysql의 경우 데이터를 저장해야하는데, 만약 어떠한 이유로 mysql pod이 꺼져버리면 데이터가 날라가 버린다.
이러한 문제는 docker가 격리를 진행하였고, 어떠한 이유로 컨테이너가 만약 꺼진다면 해당 mysql도 함께 꺼진다. 이러한 문제점을 해결하기 위해 PersistentVolumeClaim을 사용했습니다.
service를 통해 팟들을 외부와 연결 시켜준다. 여기서는 wp-config를 설정할떄, db_host이름과 name 이름을 cip-mariadb으로 통일 시켜주어 연결했습니다.
deployment는 ningx, wordpress와 비슷하고, volume 마운트를 추가해주었고, 해당 볼륨을 persistentvoulumeclaim을 연결 시켜주었습니다.

ftp가 나온이유

HTTP 프로토콜(데이터 전송 규약)을 통해 접속되는 WWW는 일반 문자를 비롯, 사진, 음악/동영상 콘텐츠까지 간편하게 사용할 수 있다는 장점이 있지만, 많은 양의 파일을 일괄적으로 주고 받기에는 결정적으로 속도도 느리고 파일 제어도 번거롭다. 이렇게 대용량 파일을 네트워크로 주고 받을떄는 파일 전송 전용 서비스인 ftp를 이용하는것이 유리하다.

ftp란?

ftp는 file transfer protocol 로 파일을 전송하는 통신규약입니다.
tcp/ip네트워크 상에서 컴퓨터들이 파일을 교환하기위해 1971년 최초로 공개된 통신규약
ftp는 비밀번호가 평문을 전송되어 보안이 떨어진다.
파일 송수신 만을 위해 고안된 서비스 이기 떄문에 동작 방식이 매우 단순하고 직관적이다.
과제에서 사용되서 ftps pod를 만들라고 되어있는데, 이 파드는 ftps클라이언트(filezilla,알ftp,ws ftp 등)으로 제어 할수 있고 ftps pod를 통해, 내가 원하는 파일을 mysql로 tcp/ip전송을 할수 있다.

ssl :(ftp에 tls 또는 ssl프로토콜이 적용된게 ftps이고, ssh프로토콜 기반으로 만들어진게 sftp이다. sftp에도 ftp라는 이름이 들어가지만 ftps와 기술적인 연관겅은 없는 완전히 다른 프로토콜이다.)
ssl은 대칭키를 사용하는데, 대칭키는 2개의 키를 만든다. (공개키, 비공개키) 대칭키의 특징은 공개키로 암호화 해한 데이터는 공개키로 복호화 시키지 못하고 비공개키로 복호화 가능하다. 반대로 비공개키로 암호화 한 데이터는 공개키로 복호화 가능하다. 이러한 비공개키는 server에 저장하고 클라이언트에 공개키를 제공한다. 문제는 이러한 대칭키도 결국엔 키를 전송해야 사용이 가능하기 떄문에 키를 전송할떄 키를 탈취 당할수 있다. 하지만 이러한 키로 악용을 하더라도 이 키는 대칭하는 퍼블릭키를 차단하면 된다. 이러한 개념을 전자서명이라고 한다. 또한 문제점은 사람이 증가 할수록 따로따로 킹교환을 해주어야해서 교환할 키가 방대해진다.
ssl공개키 비공개키

ftp의 동작원리

ftp 서비스를 제공하는 서버와 여기에 접속하는 클라이언트 사이에 두개의 연결이 생성되는데 하나는 제어 하기 위한 포트(일반적으로 21포트), 다른 하나는 실제 데이터를 전송하기 위한 포트(일반적으로 20번 포트)로 구성되어있다.
ftp 클라이언트와 서버간에 데이터 교환시 해킹을 당할 우려가 있고, 이를 보안 하기위해 사용하는 것이 ssl 또는 tls이다. (ftp + ssl or ftp + tls 둘다 ftps라고 한다.)
동작원리 ,(ftp passive모드일떄) 왼쪽 홈페이지에 동작원리가 잘 설명되어있다. 클라이언트(ex cmp1500)를 통해, 서버의 21포트에 제어신호(ex 파일을 업로드 하겟다)를 보내게 되고, 이 신호를 받은 서버의 21포트는 어느 포트로 데이터를 받을지를 클라이언트(cmd1500)로 다시 반환해준다. 클라이언트는, 서버에서 알려준 포트와 연결을 시도해 연결이 성공하면 데이터를 전송한다.

ftps 설치방법

alpine 공식 홈페이지 - ftp 설치
alpine os 에서 기본 ftp는 vsftpd를 사용하고 있다.
vsftpd (서버)
ncftp (클라이언트)
lftpd (클라이언트, 자세한 내용은 아래 참조)
클라이언트로 웹프라우저로 접속을 하는 방법도 있다.

vsftpd란? "UNIX 계열 시스템을위한 가장 안전하고 빠른 FTP 서버"라고 주장합니다. NimbleX, Slackware 등의 기본 FTP 서버입니다. 또한 상대적으로 쉽게 구성 할 수 있으므로 권장됩니다.

ftps dockerfile

FROM alpine:3.12

RUN	echo "http://dl-2.alpinelinux.org/alpine/edge/community" >> /etc/apk/repositories
RUN apk update && apk add vsftpd openssl supervisor telegraf \
	&&	mkdir -p /var/ftp \
	&& rm -rf /var/cache/apk/*

COPY ./telegraf.conf /etc/telegraf/

RUN adduser -D -g 'hoylee' hoylee
RUN echo "hoylee:password" | chpasswd

COPY ./supervisord.conf /etc/
COPY ./start.sh /
COPY ./vsftpd.conf /etc/vsftpd/

EXPOSE 21 21000

CMD sh start.sh

alpine 3.12라 기능을 확장하기 위해 community를 추가로 설치해주었다.
ftp를 실행하기 위해 ,alpine의 기본 ftp 서버인 vsftpd를 설치해주었고 나머지 필요한 툴들도 설치해주었다.
그외 필요한 설정 파일들은 etc폴더에 넣었고,
adduser을 통해 alpine리눅스의 사용자 계정을 만들다.
이렇게 계정을 만든 이유는 vsftpd에서 계정별로 폴더를 나누어 root폴더를 나누어 업로드 한다. (만약 한 다른 계정의 자료들을 접근 못하게 하려면 conf파일에서 설정해주면 된다.)

vsftpd.conf

vsftpd 설정옵션 참고 사이트

pam_service_name=vsftpd

write_enable=YES

local_enable=YES

chroot_local_user=YES

allow_writeable_chroot=YES

ssl_enable=YES
rsa_cert_file=/etc/vsftpd/ftps.crt
rsa_private_key_file=/etc/vsftpd/ftps.key

xferlog_enable=YES

seccomp_sandbox=NO

pasv_address=192.168.99.10
pasv_min_port=21000
pasv_max_port=21000

write_enable : ftp로 접속한뒤 ftp전용 명령어가 여러가지 있다. 그중 write명령어를 허용할지 결정한다. 사용하기 위해 yes
local_enable : 로컬 계정 사용자들의 접속을 허용할것인가 여부 결정. 만약에 허용하지 않으면 로컬계정으로 접속을 시도하면, "530 this ftp server is anonymous only." 와 같은 에러 메세지 출력됨.
chroot_local_user : yes를 하면, 특정 사용자가 아닌 전체 사용자에게 chroot기능을 적용하여 자기 자신의 상위 디렉토리로 이동하지 못하도록 함.
xferlog_enable : ftp 접속후에 파일 업로드와 다운로드에 대한 로그남길 것인지 결정한다. 남긴다면 yes 안남기면 no
seccomp_sandbox : seccomp 필터 sanboxing를 비활성화 하려면 no입력(seccomp ( 보안 컴퓨팅 모드의 약자 )는 Linux 커널 의 컴퓨터 보안 기능입니다)
pasv_address : NAT를 사용하는 클라이언트의 공용 IP를 설정할 때 사용 합니다.
pasv_max_port : 패시브 모드로 연결시 최소포트와 최대 포트를 할당함. (21000 을 사용하는 이유는 data전송용 포트를 설정하기 위해서)
(data port 사용 가능 범위 : 1024~65535포트)

start.sh

#!/bin/sh

openssl req -newkey rsa:4096 -days 365 -nodes -x509 -subj "/C=KR/ST=Seoul/L=Seoul/O=42Seoul/OU=AITEAM/CN=localhost" -keyout /etc/vsftpd/ftps.key -out /etc/vsftpd/ftps.crt
chmod 600 etc/vsftpd/ftps.crt etc/vsftpd/ftps.key
supervisord -c /etc/supervisord.conf

ssl 설정, supervisord

supervisord.conf

[supervisord]
nodaemon=true

[program:vsftpd]
command= sh -c "vsftpd /etc/vsftpd/vsftpd.conf && kill -s SIGTERM $(cat supervisord.pid)"

yaml파일

apiVersion: apps/v1

kind: Deployment
metadata:
    name: ftps-deployment
    labels:
        app   : ftps
spec:
    replicas: 1
    selector:
        matchLabels:
            project: ftps
    template:
        metadata:
            labels:
                project: ftps
        spec:
            containers:
                - name: ftps
                  image: ftps
                  imagePullPolicy: Never
                  ports:
                      - containerPort: 21
                      - containerPort: 21000
---
apiVersion: v1

kind: Service
metadata:
    name: ftps-service
    annotations:
        metallb.universe.tf/allow-shared-ip: wp
    labels:
        app: ftps
        env: ft_services
spec:
    selector:
        project: ftps
    ports:
        - name: ftps
          port: 21
        - name: ftpsd0
          port: 21000
    type: LoadBalancer
    loadBalancerIP: 192.168.99.10

사용할 팟을 디플로이 먼트로 만들어 주고, 21포트와 21000포트를 사용하기 떄문에 포트 설정을 진행해 주었다. 그외 설정들은 nginx 나 wordpress와 같다.

설치 확인 방법

쿠베틱을 확인 하면 위와같이 나온다.

참고 코드 사이트

$ curl -v --ftp-ssl --insecure -T test.jpg ftp://server.com/folder/ --user user:password

업로드 코드

curl --ftp-ssl --insecure -T test.c ftp://192.168.99.10/ --user hoylee:password

다운로드 코드

curl --ftp-ssl --insecure -o check.c ftp://192.168.99.10/test.c --user hoylee:password

자 긴 여정이 거의 다와간다. load balancer도 정상적으로 완성 시켰고, nginx, wordpress,mysql, phpmyadmin, ftps의 설치를 완료했다. 이제 남은건 influxDB, grafana가 남았다. 오늘은 influxDB와 grafana를 진행해보자.

influxDB 목표

InfluxDB 데이터베이스와 grafana플랫폼은 연결되어 있고, grafana는 포트 3000에서 수신 가능합니다.
Grafana는 모든 컨테이너를 모니터링합니다, 서비스 하나당 대시보드 하나를 만들어야합니다.
InﬂuxDB와 Grafana는 두 개의 별개 컨테이너에 있어야합니다.
Inﬂuxdb MySQL의 kind는 “ClusterIP”여야합니다.

Time-series DB: 시계열 데이터를 저장하고 활용하는데에 특화된 database

influxDB.Dockerfile

FROM alpine:3.12

RUN	echo "http://dl-2.alpinelinux.org/alpine/edge/community" >> /etc/apk/repositories
RUN apk update && apk add curl influxdb libc6-compat telegraf \
	&& rm -rf /var/cache/apk/*

RUN wget https://dl.influxdata.com/telegraf/releases/telegraf-1.17.0_linux_amd64.tar.gz \
	&& tar -xf telegraf-1.17.0_linux_amd64.tar.gz --strip-components=2 -C / \
	&& rm telegraf-1.17.0_linux_amd64.tar.gz
COPY telegraf.conf /etc/telegraf/

COPY start.sh /
COPY ./healthy.sh /tmp/healthy.sh
EXPOSE 8086

ENTRYPOINT  sh start.sh

인플럭스 도커 빌드는 매우 간단햇다..
start.sh에서도 influxDB와 텔레그래프를 실행해주는 작업만 진행했다.

telegraf.conf

[global_tags]
[agent]
  interval = "10s"
  round_interval = true
  metric_batch_size = 1000
  metric_buffer_limit = 10000
  collection_jitter = "0s"
  flush_interval = "10s"
  flush_jitter = "0s"
  precision = ""
  hostname = ""
  omit_hostname = false
[[outputs.influxdb]]
  urls = ["http://localhost:8086"]
  database = "influxdb"
[[inputs.cpu]]
  percpu = true
  totalcpu = true
  collect_cpu_time = false
  report_active = false
[[inputs.disk]]
  ignore_fs = ["tmpfs", "devtmpfs", "devfs", "iso9660", "overlay", "aufs", "squashfs"]
[[inputs.diskio]]
[[inputs.kernel]]
[[inputs.mem]]
[[inputs.processes]]
[[inputs.swap]]
[[inputs.system]]

telegraf 는 실시간으로 데이터 정보를 influxDB 로 전송해준다.
conf파일은 지난시간에 했던 nginx와 비슷하지만, database = "influxdb" 부분만 바꾸어주었다.
설정 내용 정리 사이트
저는 거의 기본 값으로 설정했습니다.

Grafana 목표

Grafana 플랫폼은 포트 3000을 리스닝.
Grafana 플랫폼은 InfluxDB 데이터베이스와 연결됨
Grafana는 모든 컨테이너를 모니터링합니다.
서비스 하나 당 대시 보드를 하나 만들어야합니다.
InﬂuxDB와 Grafana는 두 개의 별개 컨테이너에 있어야합니다.

grafana란?

여기 grafana + telegraf + influxdb 설명 잘되어있음!!!!!!!!!!

시계열 데이터에 대한 대시보드를 제공해주는 Data Visualization Tool인 Grafana에 대해 알아보자.
오픈소스로 공개된 influxdata의 tsdb(time series database)인 influxdb와 데이터를 모아주는 telegraf를 통해 시계열 데이터를 적재하고, 오픈소스 대시보드인 grafana를 통해 대시보드 구성 및 알림 통보를 구성하여, 특정 상황에서 사용자가 정의한 동작을 수행하도록 해야한다.
과제에서는 따로 알림통보를 요청하라고는 안했기에, 대시보드를 띄우는걸 목표로한다.

이 그림 너무 좋아서 가져왔다.. 다시 그려서 업로들하자.

그림처럼 서비스 그룹당 하나의 telegraf를 생성하고, 텔레그래프가, influxdb로 데이터를 모아준다.

그라파나 공식홈페이지 에 가면 리눅스일떄 그라파나 설치 방법이 나온다.

grafana 설치방법

FROM alpine:3.12

RUN apk update && apk add libc6-compat supervisor \
	&& rm -rf /var/cache/apk/*

RUN wget https://dl.grafana.com/enterprise/release/grafana-enterprise-7.3.6.linux-amd64.tar.gz \
	&& tar -xf grafana-enterprise-7.3.6.linux-amd64.tar.gz --strip-components=1 -C / \
	&& rm grafana-enterprise-7.3.6.linux-amd64.tar.gz

COPY srcs/supervisord.conf /etc/
COPY srcs/start.sh /

EXPOSE 3000

CMD /start.sh

알파인 os를 설치하고, 그라파나를 설치했다.
설치는 그라파나 공홈 - 다운로드 링크 사이트를 이용해서 설치했는데, 우리는 alpine os에서 설치하는데, lib64가 alpine에서는 없다.
libc6-compat 통해 추가 해주었다.
그라파나 설정파일, 데이터 파일을 넣어주고, sh파일을 실행했다. 그라파나 공홈 - 설치링크

start.sh

#!/bin/sh
telegraf & grafana-server

이제 모든 그림이 완성되었다!

모든 파드들이 잘 돌아가고 있다. 😲

간단한 테스트

1. ftps pod를 꺼보았다.

kubectl delete pod/ftps-deployment-78fdb56cd4-5vcls

2. pod프로세스 죽여보기.

kubectl exec pod/nginx-deployment-59c7cb748b-98h5w -- ps
kubectl exec pod/nginx-deployment-59c7cb748b-98h5w -- pkill nginx

nginx의 사용중인 프로세스를 확인하고 nginx프로세스를 종료시켜 보았다.
restart해서 파드를 새로 실행시켜 nginx프로세스를 다시켰다.
mariadb는 실수로 꺼버려서.. 다시 부팅되었다.

3. ssl 확인

192.168.99.10:80 으로 접속한걸 정상적으로 https로 바꾸어 주었다.

4. phpmyadmin 연동

워드프레스에 접속해서 댓글을 달면 아래처럼 phpmyadmin에도 데이터가 생긴다.

5. grafana 연동

모든 데쉬보드를 불러왔고,

다 눌러보진 못했지만 확인해본 모든 파드는 연동되었다.

이호용

~_~