Ansible - 파일 관리, 역할, 쿠버네티스 설치

IaC -> Infrastructure as a Code

source code: 컴파일러 통해서 실행이 가능한 binary 파일

configuration code: 실행 환경과 설정을 정의한 파일

manifest code: 파일, 리소스, 배포, 실행 권한 정의한 파일

git SCM -> Source Code Management

// 요즘은 SCM 대신 VCS라고 불림 (Version Control System)

-Ansible

: 원하는 실험 환경을 통해 서비스를 작동시켜주게 함

특징)

1. 다재다능 (Python) - 여러가지 형태의 작업 처리

2. No Agent - 에이전트 따로 개발하여 솔루션할 필요X, 동적인 환경에 적합

3. yaml 문이기 때문에 코드가 비교적 단순

4. 멱등성 및 예측 가능성

Playbook: 구성 파일 + 인벤토리 파일

변수 관리: 변수는 여러 가지 위치에서 작동되고 우선 순위가 있으니 원하는 상태로 만들어주려면 잘 살펴야 함!

// 전체 scope보다 좁은 scope이 우선순위가 더 높음!

팩트 변수: 시스템에 들어가 있는 정보를 변수화시켜서 해놓은 변수

작업 제어 - Handler, 오류 제어 등..

파일 관리

*파일관리 일반 모듈

모듈	설명
inlinefile	특정행을 찾거나 역참조 정규식을 활용하여 특정행을 변경 ex. listen 80 -> listen 8080 (https)
blockinfile	여러 줄을 한 번에 블록화하여 변경하거나 업데이트 // 일일이 인라인할 필요 X \| (Shift+backslash) > 기호를 사용
copy	전체 파일을 복사하여 특정 호스트, 호스트의 특정 위치로 보냄. 블록으로 해도 많은 경우 사용
fetch	copy와 반대로 동작. 관리 호스트에서 복사하여 controller로 던짐
file	권한, 소유권, 타임 스탬프 등 디렉토리와 같은 속성을 설정 일반 파일, 링크(심볼릭 & 하드) 그리고 디렉토리를 생성/제거
stat	파일의 상태 정보를 조회 (유무, 시간 데이터, 권한 등...)

ad-hoc ) servera 계정 호스트에 test라는 이름의 user 모듈 생성

ansible-user ansible-demo 디렉토리로 이동하여 모든 계정호스트에게 ping 한 결과 success가 나옴.

file.yaml 파일 생성

/etc/samba_file 확인하고 없으면 생성 (touch)

실행을 하고 servera로 접속하여 확인한 결과 있는 것을 확인할 수 있다.

ls -alZ 명령어는 Linux에서 파일 및 디렉터리의 자세한 정보를 표시하는 데 사용된다. 특히, SELinux(보안 강화 Linux) 보안 컨텍스트 정보를 포함하여 출력하는 것이 특징.

파일삭제 yaml파일 작성 state를 absent로

파일을 실행하고 servera에서 탐색한 결과 갑자기 파일 조회되지 않는다는것을 확인할 수 있음

*ansible-doc: 앤서블 명령어에 대한 도움말 문서를 조회해줄 수 있음! // ansible module index 참고

-Copy 실습

testfile 파일 생성 및 yaml파일 편집

yaml 파일 작성

파일을 실행시키고 검증한 결과 return code가 0으로 나온 것을 통해 오류가 없음을 확인할 수 있다.

// fetch는 copy와 반대로 동작, 나중에 쿠버네티스 클러스터로 실습할 것

-Lineinfile

/etc/hosts에 '10.0.0.1 test.example.com'이란 행이 없으면 생성

(absent면 있으면 삭제)

파일을 생성하고 /etc/hosts를 출력한 결과 밑에 행이 추가된 것을 확인

(-m command는 기본값이기에 생략해도 상관없음)

-Blockinfile

yaml 파일을 작성하고 전과 동일하게 출력한 결과,

블록으로 작성한 부분이 나온 것을 확인할 수 있다.

템플릿파일

: 변수를 활용하기 때문에 동적으로 파일을 업데이트

(lineinfile과 blockinfile은 정적)

config.j2 파일 생성 (j2 : jinja2)

파일 내용 업데이트

fqdn - Full Qualified Domanin Name

vi jinja.yaml 파일 통해 내용 업데이트

파일을 실행하고 나서 결과가 제대로 됐음을 확인할 수 있다.

역할

: 복잡한 작업을 처리할 때 여러 개의 플레이북 필요 -> 각각의 플레이북을 통합 플레이북에 결합시켜 실행해주도록 함

- 역할은 roles 디렉토리의 하위에 역할 이름으로 디렉토리를 구성한다. roles 디렉토리의 위치는 기본적으로 /usr/share/ansible/roles 혹은 /etc/ansible/roles 등으로 지정 되어 있지만 ansible.cfg 파일에서 defaults 섹션의 roles_path 속성으로 재정의 할 수 있다.

-가져오기(import)와 포함하기(include)

- ansible-galaxy 명령어를 통해 기본 구조 스켈레톤 (skeleton)을 자동으로 생성 (일일이 mkdir, touch 할 필요 X)

*하위 디렉토리

-역할 설치

galaxy.ansible.com 들어가서 역할 검색해서 코드 복사하여 붙여넣는다

하나의 예시로 wordpress 들고와서 설치했다. 설치한 역할 하위 디렉토리에 아까 배운 목록들이 나온 것을 확인할 수 있다.

역할 yaml 파일 // 이 때 tasks 대신 roles 작성

ansible.cfg 파일에서 roles_path = ./roles를 추가해준다.

모듈로 역할 사용하기

- tasks의 모듈로 정적 혹은 동적으로 추가

- play에서 roles 키워드 추가 (이걸 더 많이 사용)

*우선순위 (Ansible Variables Precedence 참고)

command line values (for example, -u my_user, these are not variables)
role defaults (as defined in Role directory structure) 1
inventory file or script group vars 2
inventory group_vars/all 3
playbook group_vars/all 3
inventory group_vars/* 3
playbook group_vars/* 3
inventory file or script host vars 2
inventory host_vars/* 3
playbook host_vars/* 3
host facts / cached set_facts 4
play vars
play vars_prompt
play vars_files
role vars (as defined in Role directory structure)
block vars (only for tasks in block)
task vars (only for the task)
include_vars
set_facts / registered vars
role (and include_role) params
include params
extra vars (for example, -e "user=my_user")(always win precedence)

- 역할과 함께 많이 사용하는 작업 순서를 조절하는 키워드로 pre_tasks와 post_tasks가 있다. pre_tasks는 roles 보다 우선 실행된다. 그리고 알림을 받은 핸들러 역시 먼저 실행된다. post_tasks는 모든 tasks가 끝난 뒤 핸들러 까지 실행을 마치고 나면 실행된다.

1. pre_tasks

handler

2. roles

3. tasks

handler

4. post_tasks

handler

handler -> 모든 작업이 끝나고 실행되는 게 아니라 pre_tasks, tasks, post_tasks 끝날때마다 실행된다.

컬렉션

: 특정한 벤더에서 자신의 장비 특성에 적합하게 모듈 개발 + 배포

*가상머신에 서비스 올리기

- epel-release

yum install epel-release

- remi

yum install http://rpms.remirepo.net/enterprise/remi-release-9.rpm

- php

yum install -y php httpd

-httpd service

systemctl start httpd

ansible -m service -a 'name=httpd state=started' servera

다음 yaml 파일 작성을 하여 playbook 실행을 한다.

실행이 제대로 되고나서 serverB의 주소인 172.16.0.202로 했을 때 방화벽 차단으로 인해 통신이 안되는 것이 보인다.

따라서 ansible firewalld를 통해 방화벽 작업을 해준다. (http에 대해 포트를 열어주도록)

permanent - 재부팅했을 때 통신이 되도록

immediate - 즉시 실행이 되게끔

다시 접속한 결과, 방화벽으로 안되던 serverB의 ip주소가 다시 접속되는 것을 확인할 수 있다.

(간혹 다른 주소가 나오는 경우가 있는데 serverB의 httpd를 재실행해주면 된다.)

Kubernetes

/etc/hosts 들어가서 (sudo vi) controlplane 및 node 지정

- serverA (controlplane)

- serverB (node01)

- serverC (node02)

각 서버에 대한 핑거프린트 및 이름 재지정 (서버a와 b도 같은 방식으로 재지정)

-Control Plane: 워커노드 조정 , 중앙 집중형 방식, HA - High Availability, 반드시 3개로 구성 (3중화)

구성요소

etcd: 워커노드 상태, 사용자가 던진 정보들을 저장하는 데이터베이스

그리고 그 정보를 controller 쪽으로 던져서 controller가 워커노드를 조정 (replica나 deployment 등..)

sheduler: scheduling 정책관리 // scheduling: pod 배치 관련 - 노드 셀렉터, 라벨 통해 배치

워커노드에서 kubelet, container runtime 무조건 필요 -> 이거 통해 파드를 노드에 배치, 패키지 설치

요즘, kube-proxy는 파드형태로 존재할 수도 있어서 무조건적인건 아님

배치하는 작업은 kubeadm 이라는 자동화 도구 통해 수행됨

kubernetes cluster install

1. kubeadm

2. kubelet

3. container runtime (docker, containerd, cri-o)

vi roles/k8s/tasks/main.yml 통해 내용 확인

selinux 모드:

enforcing (실행) / permissive ( 중지 + 로그는 남음 ) / disabled ( 중지 + 메모리도 아예 삭제)

-> 만약에 중지하고 싶다면 disbled보다는 permissive를 권고

디스크에 저장된 파일이 메모리에 적재하도록

근데 만약에 메모리 용량이 부족하다면? 디스크가 대신해서 사용하도록 여분의 공간(Swap)을 활용

(VMware에서 많이 활용되고 있음, 그러나 컨테이너에서는 사용되진 않음)

when: ansible_swaptotal_mb -> 뭐라도 하나 잡히면 꺼라!

설치안된 얘들만 설치하도록!

로컬호스트로부터 전달받기 때문에 copy가 아닌 fetch 사용하고

목적지 주소를 위와 같이 수정

마지막으로 서버A 중지된 상태에서 cpu 개수를 2개로 조정한 후 플레이북 파일을 실행한다.

그렇지 않으면 이런 오류가 뜸..

서버A cpu 2개로 늘리고 재부팅하여 통신이되고나서 k8s.yaml 실행이 제대로 되었다.

그리고 노드들이 조회되는 것을 확인할 수 있다.

근데 노드의 status가 NotReady 이유는? 네트워크가 아직 구성 안되어있음, 클라우드도 아직 활성화X

CRI -> Container Runtime Interface (docker, containerd, cri-o)

CNI -> Container Network Interface (calico, flannel, weave, .....)

CSI -> Container Storage Interface

*Calico Kubernetes (네트워크 구성)

kubectl create -f https://raw.githubusercontent.com/projectcalico/calico/v3.29.1/manifests/tigera-operator.yaml

kubectl create -f https://raw.githubusercontent.com/projectcalico/calico/v3.29.1/manifests/custom-resources.yaml

위 calico 네트워크 구성 명령어 넣고 시간이 좀 지나고나서 모든 노드 상태가 ready인 것을 확인할 수 있다.

-Kubernetes config

cluster:

name: kubernetes

certificate-data:

server:

user: kubernetes-admin

client-certificate-data:

contexts:

- cluster: kubernetes

user: kubernetes-admin

namespace: demo

- cluster:

'IT > Ansible' 카테고리의 다른 글

Ansible - 변수 관리, 작업 제어, Handler, 오류제어 (1)	2025.01.24
Ansible - Baseline, Ansible-Playbook (0)	2025.01.23

박성훈 님의 블로그

Ansible - 파일 관리, 역할, 쿠버네티스 설치