[ft_services] 5. nginx deplyment 만들기, nginx servise 만들기

이호용·2021년 5월 7일
42subjectft_services
0

42_ft_services

목록 보기
5/8

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

해야할 일

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

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

1. nginx - Dockerfile

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 생성
  • 이미지 빌드와 쿠버네티스 적용
profile
이호용
~_~
이전 포스트

[ft_services] 4. sh파일 생성하기. , grafana란? nginx란? influxDB란?

다음 포스트

[ft_services] 6. wordpress 이미지파일을 만들고, 쿠버네티스를 통해 배포해보자.

0개의 댓글

관련 채용 정보