날아가는 개발자

서비스

수달형아 — Mon, 28 Mar 2022 23:35:23 +0900

Service

- 파드의 IP 구성정보
-> 파드마다 특정 IP 주소를 할당받음 (고정되지 않음)
매번(재부팅/파드재시작 자동으로 생성) 변경
- 어플리케이션 접근을 위해 고정된 주소가 필요 (어플리케이션 하나 당 IP 주소 하나)
=> 컨트롤러에 의해 실행되는 파드들 전체에 대해 하나

- 개념 : 파드 / 외부 간의 통신을 위해 고정된 IP 주소를 할당하는 오브젝트
-> 노드에 구애받지 않고 여러 파드(동일 컨트롤러)에 주소 하나
파드에 대한 로드벨런싱 기능 등을 제공
파드 하나에 여러 개의 서비스가 연결될 수도 있다.

컨트롤러의 셀렉터 = 파드 레이블
서비스의 셀렉터 = 파드 레이블
컨트롤러의 셀렉터 != 서비스의 셀렉터 ( 꼭 같을 필요는 없음 )

- 종류
1. ClusterIP - 내부용(파드끼리) IP 주소를 사용
내부용 IP 주소를 굳이 사용하는 이유 : 고정IP , 로드밸런싱
파드와 연결 시 label / selector 사용

---------------------------------
2. NodePort - 물리적인 시스템(노드)의 IP 주소를 사용하면서 포트포워딩 설정

3. LoadBalancer - 쿠버네티스 클러스터 외부에 로드벨런싱 장치를 연결해서 구성
=> 클라우드 환경은 자체적인 LB 사용
=> 온프레미스 환경에서는 MetalLB 등을 사용

=> 클라우드에서 제공하는 로드밸런서와 파드를 연결한 후 해당 로드밸런서 IP 이용해 접근
--------------------------------- 외부용(쿠버네티스 클러스터 외부에서도 접근 가능)

ExternalName - 안에서 외부로 접근할 때 사용할 이름주소를 제공
내부적으로 사용하는 FQDN 을 통해서 외부의 시스템으로 접근 (CNAME)

- 서비스 FQDN
각 서비스는 이름에 따라 할당된 FQDN 을 보유
SERVICENAME . NAMESPACE . svc . cluster . local
svc : 오브젝트 종류
cluster.local : 쿠버네티스 클러스터의 도메인 이름

Kube-proxy

- 역할 : 파드 간의 통신을 담당 (네트워크 구성)
- 방식 : userspace / iptables / IPVS
userspace -> iptables ( 성능 )
kube-proxy 가 아닌 iptables 를 통해 트래픽을 전달받고 전달하는 방식
kube-proxy 는 iptables 를 관리

C1 = 10.233.101.145
C2 = 10.233.103.86

C1 컨테이너(파드)에서 C2 주소로 요청
C1 컨테이너 -> 브릿지(쿠버네티스) -> 1번 노드(물리인터페이스)
-> Dest IP 주소를 파드에서 노드 변경 ( Netfilter + iptables )
=> 노드는 파드의 주소를 모를 수 있으니까 동일한 네트워크인 노드의 주소로 변경
-> 1번 노드에서 라우터로 전달 -> 라우팅 테이블 확인 -> 해당노드(2번)로 전달
-> Dest IP 주소를 노드에서 파드 변경 ( Netfilter + iptables )
-> 노드 -> 브릿지 -> C2컨테이너

실습

ClusterIP

- yaml 파일 작성

spec.ports.port: 서비스가 생성할 Port

spec.ports.tragetPort: 서비스가 접근할 Pod의 Port (기본 : port랑 동일)

spec.selector: 서비스가 접근할 Pod의 label 조건

spec.type: 서비스 타입; (default: ClusterIP)

spec.clusterIP: 10.0.10.10 (default: 자동설정)

ClusterIP 서비스 작성

작성한 ClusterIP 접속하는 서비스 작성

NodePort

LoadBalancer

컨트롤러 (Daemonset, Statefulset, Job, CronJob)

수달형아 — Mon, 28 Mar 2022 22:21:18 +0900

Daemonset

- 클러스터 전체 노드에 특정 파드 실행할 때 사용하는 컨트롤러

-> 모니터링용 데몬 등 클러스터 전체에 항상 실행시켜두어야 하는 파드에 사용

- 업데이트 정책 변경 가능
RollingUpdate : 수정 시 바로 반영 (파드를 자동으로 재생성)
OnDelete : 수정 시 반영X (파드를 수동으로 삭제하면 재생성 시 반영)
- 노드 추가/제거 시 파드도 자동으로 생성 및 삭제
- 노드셀렉터라는 값을 설정하면 노드를 지정할 수 있음 (모든 리소스 해당)

Statefulset

- 기본적으로 파드는 상태를 저장하지 않는다.
- 파드의 상태를 유지 ( 파드이름, 네트워크, 스토리지 )
- 파드 배포 및 복제본 개수 유지 (스케일링)
-> 파드의 순서 / 고유속성을 유지
- 각각의 파드마다 고유한 볼륨을 연결
- 기본적으로 스테이트풀셋은 파드를 순서대로 하나씩 생성 및 삭제 (배포/스케일링)
- 병렬설정 시 배포 및 스케일링 작업 시 한 번에 실행 (.spec.podManagementPolicy: Parallel)
-> 업데이트 정책은 별개 (기본값: rollingUpdate)
- 롤링업데이트 시 기존 파드를 하나씩 삭제 후 생성
- 업데이트 정책은 rollingUpdate와 on-delete 방식 선택 (데몬셋과 동일)

실습

- 파트 제거 및 확인

$ kubectl edit stateful web

$ .spec.replicas: 2로 변경

- Parallel로 변경하면 파드들이 순서 없이 병렬로 실행되거나 종료되게 할 수 있음

Job

- 파드(어플리케이션)의 상태가 완료/종료 (일회성)
- 실행 후 완료 시 파드를 종료
-> 완료로 카운트되기 전에 파드를 제거하거나 문제가 생기면 새로운 파드 생성
하지만, 완료 카운트 후에는 제거해도 다시 만들지 않음
- 완료 횟수를 지정 가능
- 레이블/셀렉터가 사용 가능하긴 하지만 권장하지 않음
-> 컨트롤러에 부여된 고유값(UUID)
- restartPolicy 속성이 기본값은 Always
-> 정상종료/비정상종료 관계없이 종료하면 재시작
=> Onfailure 속성으로 설정하는 것을 권장
- parallerism 항목으로 동시 생성 파드의 개수 지정
- 작업 실패 처리
activeDeadlineSeconds 항목으로 실패/성공 여부 결정을 할 판단 시간
backofflimit 항목으로 실패 시 재시도 횟수

실습

CronJob

- 잡을 주기적으로 반복 실행하는 방식
- 리눅스의 크론탭처럼 반복 주기를 설정
- 작업 완료 시간과 반복 주기에 대한 고려가 필요
-> startingDeadlineSeconds : 예약된 시각에 실행을 못할 경우 기다릴 시간 (중복허용X)
=> 기다려도 실행할 수 없을 경우에는 해당 시각의 작업은 포기
-> concurrencyPolicy : 동시 실행 여부
- 작업이 완료해도 파드를 바로 제거하지 않음

- 시간 설정(schedule)
분 시 일 월 요일
* * * * * => 1분 단위로 실행
*/1 * * * * => 1분 단위로 실행
*/2 * * * * => 2분 단위로 실행
* */2 * * * => 2시간 단위로 실행
0 1 1 1 * => 매년 1월 1일 1시 정각
0 1 -3 1 1 * => 매년 1월 1일 1시 정각. 2시, 3시 정각에 실행

컨트롤러 (ReplicaSet, Deployment)

수달형아 — Sat, 26 Mar 2022 16:44:13 +0900

컨트롤러

- 개념 : 파드를 관리하는 오브젝트

- 파드 관리 방식 : Label과 Selector 사용 ( Label은 파드에 설정. Selector는 컨트롤러에 설정 )

- 종류 :

레플리카셋

디플로이먼트

데몬셋

스테이트풀셋

잡

크론잡

레플리카셋

- 파드의 정해진 수 만큼 복제하고 관리
- 레플리케이션 컨트롤러의 업그레이드 버전 (균등기반+집합기반)

- 기존버전 (레플리케이션 컨트롤러 사용)
- 기능 : 업데이트 + 복제본 관리(등호기반)

- 현재 (레플리카셋)
- 기능 : 복제본 관리 (집합기반)
- 업데이트 기능은 디플로이먼트로 관리
=> 디플로이먼트를 통해서 레플리카셋 및 파드를 생성하고 관리: 실전에서는 주로 Deployment 사용

레플리카셋 실습

디플로이먼트

- 레플리카셋을 관리해주는 컨트롤러
- 업데이트 정책(배포 방식)을 지원
롤링업데이트 - 새로운 RS 및 파드 생성 (순차적으로 하나씩)
maxSurge : 파드 생성 시 비율(개수) 지정
maxUnavailable : 오류가 발생한 파드의 허용 비율(개수)
리크리에이트 - 기존의 파드 제거 후 새로운 RS 및 파드 생성

- 버전관리를 위한 목적이 크다.
- 수정 작업 시 명령어
$ kubectl  set image : 이미지를 변경
$ kubectl  edit : 이미지 포함 설정 변경 가능
$ kubectl  apply : 템플릿파일 수정 및 배포
-> 리비전 넘버는 항상 증가
따로 이유는 기록되지 않음 (관리가 힘들 수 있다)
--record 옵션으로 명령어 자체를 기록
혹은 annotations 항목에서 kubernetes.io/change-cause 를 설정하면 원하는 메시지를 기록 가능

- 리비전 넘버는 항상 증가
-> undo 명령어로 롤백 시에도 증가
기존의 리비전넘버는 제거

- rollout 명령어 정리
$ kubectl rollout history : 업데이트 기록
$ kubectl rollout status : 현재 배포 작업의 상태
$ kubectl rollout undo : 지정한 상태로 롤백

$ kubectl rollout pause, resume, restart: 일시정지, 계속진행, 재시작

디플로이먼트 실습

- 생성 및 확인

- 이미지 교체 및 확인 (set image)

$ kubectl set image

$ kubectl edit deploy nginx-deployment

-> 위의 명령어는 vi편집기 바로 실행하여 종료 시 적용

- rollout 명령어로 업데이트 내역 확인 / 취소

$ kubectl rollout undo deploy nginx-deployment --to-revision=1 도 사용 가능

- annotation 설정 / --record

- strategy 설정

spec 아래에 추가

파드 관리

수달형아 — Sat, 26 Mar 2022 15:34:21 +0900

파드

- 쿠버네티스에서 컨테이너를 관리하는 최소 단위
- 컨테이너가 하나 이상
- 하나의 목적을 위해서 하나의 파드를 구성
- 목적을 위해서 필요한 기능이 여러 가지
- 파드의 목적으로는 컨테이너 간의 리소스를 서로 공유
- 여러 컨테이너(동일목적)를 동시에 제어

파드 라이프 사이클

1. Pending : 스케줄링, 이미지 다운로드 및 컨테이너 실행 (모든 컨테이너가 실행되기 전)
2. Running : 모든 컨테이너가 정상 실행
3. Succeeded / Failed : 작업이 성공적으로 완료, 실패
4. Unknown : 파드의 상태를 확인할 수 없을 때

프로브

- 파드의 상태를 확인해주는 방식/상태 -> 유지
- 종류
livenessProbe : 컨테이너의 실행여부를 확인해서 오류 발생 시 재실행 기능 지원
readinessProbe : 컨테이너 내부의 어플리케이션이 응답 가능한지 확인 및 재실행
startupProbe : 컨테이너 내부의 어플리케이션이 실행했는지 확인

- 장점 : 상태를 확인하고 유지해줄 수 있다.
- 확인 방식
Exec : 지정한 프로그램(명령어)을 실행해서 결과값으로 확인
Http : Get으로 요청해서 응답코드로 확인
TCP : 특정 포트에 대한 요청으로 포트 확인

- 진단 결과
Success : 정상 ( exec - 리턴코드 0 , http - 2xx / 3xx , tcp - open )
Failure : 오류 ( exec - 리턴코드 0이 아닐 때 , http - 400이상 , tcp - close )
Unknown : 확인불가

- 확인 후 컨테이너의 재시작 정책에 따라 처리 (기본값은 항상 재시작)

초기화 컨테이너 (init Container)

- 파드 실행 시 우선적으로 실행해야 하는 컨테이너를 지정
- 순서대로 실행
- 프로브 사용 불가

인프라 컨테이너 (infra Container)

- /pause 를 실행하는 컨테이너
- 파드 생성 시 기본적으로 함께 생성
- IP 주소를 할당 (파드의 어플리케이션 컨테이너가 재시작해도 IP주소를 유지, 여러 개의 컨테이너가 존재해도 모두 동일 IP 사용)

스태틱 파드

- 일반적인 파드는 kube-apiserver 를 통해서 파드를 관리
- kube-apiserver 를 통하지 않고 만들고 관리하는 파드
- 쿠버네티스의 구성요소(컴포넌트)들도 파드 형태로 관리
- kubelet 이 직접 관리
- 노드 변경 없이 동일한 노드에서만 재실행
- 클러스터(쿠버네티스시스템) 환경을 구성하는 데에 필요한 파드들을 주로 설정
- /etc/kubernetes/manifest 디렉토리에 yaml 파일로 작성
- 각 컨트롤플레인 및 노드마다 구성

파드 리소스 관리

- 쿠버네티스에서는 컨테이너를 파드 단위로 관리
- 따라서 리소스 설정도 파드 단위로 구성
- limit : 최대 사용 가능한 리소스(제한)
- request : 최소 사용 가능한 리소스(보장)
- cpu / memory 에 대한 설정
- memory 는 사이즈를 기준으로 설정
- cpu 는 코어개수(퍼센트)로 설정
- 할당한 리소스에 따라 파드의 실행이 어려울 수 있음

테스트 시나리오
1. 최대사용량을 실제 노드의 스펙보다 크게 설정했을 때 생성 가능한 지 확인
2. 최소보장 크기가 오버했을 때 생성 여부
3. 사용량이 실제 최대까지만 사용되는지 확인
4. 추가적인 파드를 생성했을 때 제한 조건 ( 실제 2G , 사용량 1.5G , 새로운 파드의 최소 1G가 필요한 경우 )

$ kubectl top node/pod : 각 대상에 대한 사용량 확인 가능

파드 환경 변수

- 파드 실행 시 컨테이너 내부에서 사용할 환경변수 설정 가능
- 값을 템플릿에서 직접 지정 가능 ( value )
- 오브젝트의 설정값을 불러와서 지정 ( valueFrom.fieldRef )
- 컨테이너의 리소스 할당량을 값으로 지정 ( valueFrom.resourceFieldRef )
- 컨피그맵 또는 시크릿의 값도 사용 가능
- 명령어로 파드 실행 시에도 환경변수 설정 가능 ( kubectl run --env 이름=값 )
- 확인은 kubectl describe 로 가능 (직접 컨테이너 내부에서 확인도 가능)

파드의 컨테이너 패턴

- 사이드카 : 확장된 기능을 위한 구성 (리소스공유)
- 엠베서더 : 프록시 컨테이너로 간접접근 및 로드밸런싱 역할
- 어뎁터 : 어플리케이션이 동작하는 컨테이너에 대한 접근 및 데이터 수집 (모니터링 등)

=> 다양한 패턴으로 파드 내부의 컨테이너가 구성된다.
관리 시에는 파드 단위로 관리

실습

- 사용법
생성
$ kubectl run : 파드의 특성을 명령어 라인에서 정의하고 실행 (재사용성이 떨어짐)
$ kubectl create -f FILE : 파드를 포함한 여러 오브젝트를 생성 (템플릿 사용 -> 새로 생성)
$ kubectl apply -f FILE : 파드를 포함한 여러 오브젝트를 생성 (템플릿 사용 -> 새로 생성 + 수정)

삭제
$ kubectl delete : 종류와 이름을 직접 지정하거나 생성 시 사용한 파일을 이용해서 삭제 가능

확인
$ kubectl get : 간단한 확인 ( -o 옵션으로 출력방식 지정 )
$ kubectl describe : 조금 더 상세한 정보 확인 ( 대상을 지정해서 보는 경우가 많음 )

$ kubectl explain : 템플릿의 작성 방식 (설정항목)
$ kubectl api-resources : 템플릿에서 정의할 대상의 kind / api-version ( kubectl api-versions )

$ kubectl logs : 파드의 동작 내역 확인

- yaml 파일 작성

- 아래의 내용에 따라 kubectl explain 명령어 사용하여 내용 확인 가능

출처: https://subicura.com/k8s/guide/pod.html#yaml로-설정파일spec-작성하기

- yaml 기반으로 파드 실행 및 확인

# 실행
kubectl apply -f sample.yml

# 확인
kubectl get pods

# 종료
kubectl delete pod nginx

- LivenessProbe 실습 예시

아키텍쳐 및 명령어 기본

수달형아 — Sat, 26 Mar 2022 14:57:50 +0900

도커 - 하나의 시스템에서 컨테이너를 하나씩 관리
도커 컴포즈 - 하나의 시스템에서 컨테이너를 여러 개를 묶어서 관리
쿠버네티스 - 여러 대의 시스템에서 여러 컨테이너를 묶어서 관리

쿠버네티스

개념 - 여러 시스템에서 동작하는 여러 개의 컨테이너들을 세트로 관리

구성환경 - 온프레미스 / 클라우드 ( 직접구성 / 관리형 쿠버네티스 )
=> 관리형 쿠버네티스 사용 시
장점은 사용하기 편리, 초기 구성 비용이 없음
단점은 유지비용이 증가, 세부항목에 대한 관리가 어려움

설치 방식
- kops : 클라우드(AWS)에서 쿠버네티스 환경 구성
- kubeadm : 온프레미스 환경에서 쿠버네티스를 구성 (명령어를 사용) => 버전 관리가 어려움
- kubespray : kubeadm + ansible => 각종 플레이북 / 변수파일 / 인벤토리 등을 설정
- docker-desktop : 리눅스컨테이너를 윈도우 등에서 사용할 수 있게 환경을 구성
- minikube : 테스트환경을 구성하기 좋은 간소화된 쿠버네티스 환경 배포 (기본은 원노드)

오브젝트

- 워크로드 : 컨테이너를 관리하는 방식
- 파드 : 컨테이너를 관리하는 최소 단위
하나 이상의 컨테이너로 구성 (목적)
- 컨트롤러 : 파드를 관리 (관리 방식에 따라 여러 종류)
- 레플리카셋 : 복제본의 개수를 관리
- 디플로이먼트 : 레플리카셋의 업데이트 정책 관리
- 데몬셋 : 노드마다 파드를 실행
- 스테이트풀셋 : 상태 저장을 위해 사용
- 잡 : 일회성 작업을 한번 실행
- 크론잡 : 일회성 작업을 반복 실행

- 서비스 : 컨테이너에 대한 네트워크 연결
ClusterIP
NodePort
LoadBalancer

쿠버네티스 클러스터

- control-plane 을 클러스터 구성
1대로도 동작은 가능 (HA 기능 없음)
기본 3대 권장 (HA 기능 제공)
최대 7대 권장
- node (worker) 는 필요에 따라 개수 증가

쿠버네티스 특징

- 선언적 API : 상태를 정의해서 유지
- 커뮤니티가 활발

아키텍쳐

1. Control-plane (master)
kube-apiserver : 각각의 컴포넌트 및 리소스 제어를 위해 접근하는 포인트(전달자)
kube-controller-manager : 각각의 컨트롤러(파드)를 관리/제어
etcd : 쿠버네티스 환경(클러스터) 구성에 필요한 정보들을 저장
kube-scheduler : 컨테이너를 실행할 위치(노드)를 지정
(cloud-controller-manager) : 클라우드 환경에서 컨트롤러 등의 개체를 제어/관리

2. Node (worker)
kube-proxy : 컨테이너의 네트워크 구성
kubelet : 명령어 등을 통해 전달한 내역을 전달받고, 컨테이너를 생성 및 상태유지
container-runtime (docker) : 컨테이너 생성 및 관리

쿠버네티스 명령어

- kubectl 명령어 사용
- 수동으로 설치가 필요할 수 있음 (kubeadm/kubespray 등은 자동설치)
- root사용자(설치를 진행한) 로만 설정
추가 구성
1) 다른사용자에서 명령어 설정
/etc/kubernetest/admin.conf 파일을 ~/.kube/config 파일로 복사 (소유권)
2) 자동완성기능
kubectl completion bash > /etc/bash_completion.d/XXXX (재접속)

- 기본구문

kubectl 동작 대상 이름 옵션

$ kubectl explain 대상 : 대상에 대한 템플릿 설정 방법 확인
$ kubectl api-resources : 사용할 수 있는 리소스 목록 확인
$ kubectl api-versions : 사용할 리소스의 버전 확인

-> kubectl create / apply : 템플릿으로 리소스 배포 (많이사용)

$ kubectl run : 간단하게 파드 배포
$ kubectl expose : 간단하게 서비스 배포
$ kubectl create : 컨트롤러 배포 (템플릿 없이도 가능)

도커 네트워크

수달형아 — Tue, 15 Mar 2022 11:56:22 +0900

도커 네트워크

- 도커는 컨테이너를 이용해서 어플리케이션을 격리된 환경에서 실행

- 대부분의 어플리케이션은 외부의 사용자에게 서비스 제공이 목적

- 서비스를 제공하기 위해 네트워크 구성이 필요

- 어플리케이션 (컨테이너)끼리 서로 연동 시에도 필요

- 가상 브릿지와 가상 네트워크 인터페이스 등을 사용

- 컨테이너 생성 시 기본적으로 bridge 네트워크로 설정

네트워크 종류 (driver)

1) 기본제공

- bridge: 내부적으로 컨테이너끼리 서로 연결되어 있으며 가상브릿지 (docker0)를 통해 외부와 연결 (추가 가능)

- 기본 설정일 경우 외부에서 컨테이너로 접속 제한
- 필요에 따라 docker run 명령어에서 -p 옵션으로 포트포워딩 설정

- host: 호스트 (물리적인 시스템)의 네트워크 인터페이스 (스택)을 공유하는 형태

- 현재 시스템의 IP 주소를 통해 접근 가능
- 단, 포트 번호가 겹치는 이미지를 함께 사용할 수 없음
- 별도의 설정 없이 외부에서 컨테이너 접근 가능

- null (none): 네트워크를 사용하지 않는 형태

2) 추가 제공

- macvlan: mac 주소를 별도로 할당하는 방식

- 컨테이너에 mac 주소 할당해서 외부에서는 호스트에 물리적인 인터페이스를 추가한 것처럼 인식하도록 IP주소 따로 할당
- 실제 IP주소가 필요하고 인터페이스의 부하 증가, 보인 위험 증가

- ipvlan: macvlan과 유사한 형태 (기능적으로 경량화)

- overlay: docker swarm을 사용할 경우 필요

도커 볼륨 관리 실습

수달형아 — Mon, 14 Mar 2022 16:30:49 +0900

1. 컨테이너에 디렉토리 연결

docker run -v HOST Path:CONTAINER Path --name NAME ubuntu:latest

2. 볼륨 생성 및 연결

1) contents 라는 이름의 볼륨 생성

docker volume create contents
# /var/lib/docker/volumes/contents

2) httpd 이미지로 컨테이너 실행

docker container run -d -v contents:/usr/local/apache2/htdocs:ro httpd:latest

3) 볼륨에서 파일 확인 및 curl 명령어로 컨테이너 접속 확인

ls /var/lib/docker/volumes/contents/_data/

docker container inspect NAME

curl 172.17.0.X

4) centos 이미지로 컨테이너 실행

docker container run -itd -v contents:/mnt --name os1 centos:7

5) centos 컨테이너에서 파일 내용 확인 및 수정

docker container exec os1 ls /mnt

docker attach os1
ls /mnt
echo "test volume" > /mnt/index.html

3. 컨테이너 및 볼륨 제거

docker container rm -f

docker volume prune

도커 이미지 및 도커파일 관리 실습

수달형아 — Mon, 14 Mar 2022 16:22:55 +0900

1. 이미지 백업

1) 현재 모든 이미지를 test.tar 파일로 백업

docker image save test.tar -o XXXX # 태그 생략 시 모든 태크

2) 모든 이미지 삭제

docker image prune -a

3) test.tar 파일 이용해서 모든 이미지 복원

docker image load -i test.tar

2. 이미지 수정

1) httpd:lastest 이미지를 web 이라는 이름의 컨테이너로 실행

docker container run --name web -d httpd:latest

2) web 컨테이너에 쉘을 실행하고 index.html 파일 내용 수정

docker container exec web bash

3) 쉘을 종료하고 web 컨테이너를 httpd:custom 이름의 이미지로 생성

docker container commit web httpd:custom

4) httpd:custom 이미지를 web02 컨테이너로 실행하고 index.html 파일 내용 확인

docker container run --name web02 -d httpd:custom

3. Dockerfile 사용법

1) centos:7 이미지를 컨테이너로 실행하고 파일시스템 구조만 뽑아서 이미지로 생성

docker container run --name os1 -itd centos:7

docker container export os1 -o FILE

docker image import <file name> <iamge name>

2) Dockerfile 작성하면서 위 이미지를 베이스 이미지로 사용

3) httpd 서비스가 동작하는 이미지 생성 (패키지설치, 서비스 실행, index.html 복사)

echo "test dockerfile" > index.html

vi Dockerfile

"""Dockerfile"""
FROM	base
RUN		yum install -y httpd
CMD		httpd -D FOREGROUND
COPY	index.html /var/www/html/
"""End Dockerfile"""

docker image build -t <docker file name>

4) 다음 조건에 맞는 이미지 생성

- testuser 사용자생성

- /mnt 디렉토리를 볼륨으로 설정

- 환경변수 VARS=abc 설정

- 작업디렉토리 /mnt 디렉토리 지정

- 접속 시 사용자를 testuser로 지정

"""Dockerfile"""
FROM	base
RUN		useradd testuser
VOLUME	/mnt
ENV		VARS=abc
WORKDIR	/mnt
USER	testuser
"""End Dockerfile"""

5) 지시어

- FROM: 사용할 베이스 이미지 지정

- CMD: 이미지로 컨테이너를 실행하면 동작할 내용 (프로세스)

- ENTRYPOINT: 이미지로 컨테이너를 실행하면 동작할 내용 (프로세스)

- ENTRYPOINT의 우선순위가 더 높음
- 둘 다 설정하면 ENTRYPOINT를 실행하면서 인자값으로 CMD 사용
- 하나만 설정할 경우, CMD만 설정하면 이미지를 실행할 때 명령어 대체 가능; ENTRYPOINT는 명령어 대체 불가능

- RUN: 이미지 생성 전 해야할 작업

- COPY: 파일 / 디렉토리를 이미지에 추가 (로컬)

- ADD: 파일 / 디렉토리를 이미지에 추가 (로컬 / 원격)

- EXPOSE: 이미지에서 사용하는 포트 지정

- VOLUME: 이미지 자체적으로 볼륨이 필요한 디렉토리 지정

- ENV: 환경 변수

- USER: 사용자 이름 지정 (사용자가 만들어진 상태에서 사용)

- WORKDIR: 작업 디렉토리 지정

- SHELL: 컨테이너에서 사용할 기본 쉘

- LABEL: 에몯

- ARG: Dockerfile 내부에서 사용할 변수

- ONBUILD: 새로 만든 이미지를 베이스 이미지로 지정할 때 사용할 구문 (예약)

- STOPSIGNAL: 시스템 콜 설정

- HEALTHCHECK: 상태 확인

도커 컨테이너 관리 실습

수달형아 — Mon, 14 Mar 2022 16:08:26 +0900

1. 이미지 다운로드

- httpd:latest, centos:7, ubuntu:latest

docker image pull httpd

docker image pull centos:7

docker image pull ubuntu

2. 다운로드 한 이미지 확인

docker image ls
# docker image inspect ubuntu:latest

3. 이미지를 이용해서 컨테이너 실행

1) create 명령어와 start 명령어로 centos:7 이미지 실행 - 이름: centos

docker container create -it --name centos -it centos:7
docker container start centos

# 만약 start 명령어 사용 시 -ai 옵션으로 연결한다면, Ctrl + p + q 사용하여 연결만 해제

2) create 명령어와 start 명령어로 httpd:latest 이미지가 정상 동작하도록 실행 - 이름: web1

docker container create --name web1 httpd:latest
docker container start web1

3) run 명령어로 ubuntu:latest 이미지 실행 - 이름: ubuntu

docker container run --itd --name ubuntu ubuntu:latest

4) run 명령어로 httpd:latest 이미지 실행 - 이름: web2

docker container run --name web2 -d httpd:latest

4. 컨테이너 상태 확인

1) 동작 중인 컨테이너 상태 확인

docker container ps

2) 모든 컨테이너 상태 확인

docker container ps -a

3) 특정 컨테이너 하나 자세한 정보 확인

docker container inspect <name>

5. 컨테이너 동작 확인

1) ubuntu 컨테이너 중지

docker container stop ubuntu

2) web1 컨테이너 강제 삭제

docker container rm -f web1

6. 컨테이너에 다른 어플리케이션 실행

1) centos 이미지로 ls 명령어 실행

docker container run --name centos_ls centos:7 ls

2) httpd 이미지로 bash 실행

docker container run --name web_bash -itd httpd:latest bash

Apache 웹 서버

수달형아 — Thu, 3 Feb 2022 16:30:41 +0900

1. Web Server

1) 소개

- 네트워크를 이용해서 사용자가 요청한 컨텐츠를 제공 (정적인 컨텐츠; html, image 등)

- 동적인 컨텐츠 제공 (별도의 구성 또는 어플리케이션 서버 / 데이터베이스 등을 연동) -> WAS

- Apache / Nginx / IIS 등의 구성방식이 존재

# 기본구성
# 패키지 설치
yum -y install httpd

# 시작
systemctl enable httpd.service
systemctl start httpd
firewall-cmd --add-service=http --permanent
firewall-cmd --reload

# 확인
firefox http://127.0.0.1

2) 3 Tier 구성

- 클라이언트가 요청하면 응답해줄 웹서버

- 웹서버 동작에 필요한 어플리케이션 서버

- 어플리케이션이 동작할 때 사용할 데이터가 저장되어 있는 데이터베이스 서버

웹서버 구성 시 팁
1. 로드벨런서를 구성해서 웹서버 이중화
2. 웹서버를 통해서만 어플리케이션 서버에 접근할 수 있게 보안 설정
3. 어플리케이션을 통해서만 데이터베이스에 접근할 수 있게 보안 설정
4. 데이터베이스도 이중화 구성

3) Apache 서버 구성

- 설정파일: /etc/httpd 디렉토리

- 컨텐츠파일: /var/www 디렉토리

- 샘플파일: /usr/share/doc/http-XXX 디렉토리

2. 가상 호스트 구성

- 하나의 물리적인 서버에서 여러 컨텐츠를 IP주소/포트번호/DNS주소 등에 따라서 서로 다르게 제공

- /etc/httpd/conf.d/XXX.conf 파일 작성 -> 확인 순서는 가나다순

- 설정파일 내용물로는 ServerName, DocumentRoot, Directory 블록 등을 사용

- 일반적으로 이름 기반의 가상호스트를 사용 -> DNS서비스 제공 필수 (/etc/hosts 파일)

1) 이름 기반 (Name-base virtual host)

- cat /etc/httpd/conf.d/test.conf

- DocumentRoot는 각 가상호스트가 사용할 웹 페이지 파일의 경로

2) IP 기반 (IP-base virtual host)

- 웹 서버가 하나 이상의 네트워크 인터페이스를 가지고 있으면 인터페이스별로 들어온 요청 구분 가능

- 별도의 포트 지정이 없으면 기본 포트 80/TCP 포트 사용

- nmcli connection modify Static +ipv4.addresses 192.168.100.11/24로 포트 추가

3) 포트 기반 (Port-base virtual host)

- /etc/httpd/conf/httpd.conf 파일의 Listen 설정에 포트 설정을 추가해야함

- 방화벽 수정도 요구됨 (firewall-cmd --add-port=8080/tcp --permanent

3. HTTPS

- 데이터를 암호화 해서 주고받는 방식의 프로토콜

- 대칭키 / 비대칭키 암호화 방식을 이용 (하이브리드)

1) 동작 방식

가) Client Hello(클라): 웹 브라우저를 통해 https연결 요청

나) Server Hello(서버): 서버가 가지고 있는 인증서 전달 (공개키 포함)

다) 인증서 확인 및 대칭키 전송 (서버): 서버의 인증서 검증 & 공개키를 서버의 공개키로 암호화하여 전송

라) 컨텐츠 전송(서버): 서버의 개인키로 복호화 하여 획득 & 연결 종료 시 까지 모든 컨텐츠 대칭키로 암호화하여 전송

암호화 방식
원격접속: telnet -> ssh
파일전송: rcp -> scp
웹: http -> https