내 잡다한 노트

**DooD(Docker out of Docker)**는 Docker 컨테이너에서 호스트 시스템의 Docker 엔진을 직접 사용하는 설정 방식입니다. 이는 컨테이너 내부에서 별도의 Docker 설치 없이, 호스트 시스템의 Docker를 활용하여 컨테이너를 실행하거나 관리할 수 있도록 해줍니다.  DooD의 원리DooD는 두 가지 주요 요소를 공유하여 동작합니다:Docker CLI 실행 파일 공유:/usr/bin/docker를 컨테이너에 마운트하여 Docker CLI(Command Line Interface)를 사용 가능하게 함. volume:- /usr/bin/docker:/usr/bin/dockerDocker 데몬 소켓 공유:/var/run/docker.sock을 컨테이너에 마운트하여 컨테이너 내부에서..

PAM은 리눅스에서 사용하는 인증 모듈로 서비스에 대한 사용자의 사용 권한을 제어하는 모듈이다. PAM이 없을 때는 사용자를 인증하기 위해 응용프로그램을 활용해야 했는데, 응용프로그램은 /etc/passwd의 접근 권한을 가지고 있어야 해서 침해사고의 위험이 존재했다. 이를 해결하기 위해 PAM이 등장하게 됐다. 동작 원리- 인증이 필요한 응용프로그램은 더 이상 passwd 파일을 열람하지 않고 PAM 모듈에 사용자 인증을 요청한다.- PAM은 인증을 요청한 사용자의 정보를 가지고 결과를 도출하여 응용프로그램에 전달한다.  PAM의 구성 요소PAM은 다음과 같은 주요 구성 요소로 이루어져 있습니다.1. PAM 모듈실제 인증 작업을 수행하는 소프트웨어./lib/security/ 또는 /usr/lib/sec..

**Reverse DNS(리버스 DNS)**는 IP 주소를 호스트 이름으로 변환하는 시스템입니다. 이는 일반적인 DNS(forward DNS)가 호스트 이름을 IP 주소로 변환하는 것과 반대되는 역할을 합니다. 리버스 DNS는 특정 상황에서 중요하며, 네트워크 및 보안에서 다양한 용도로 사용됩니다. Reverse DNS가 필요한 이유1. 신뢰성과 인증스팸 방지와 메일 서버 인증:많은 이메일 서버는 스팸 메일을 방지하기 위해 발신자의 IP 주소에 대해 리버스 DNS 조회를 수행합니다.발신 IP가 리버스 DNS를 통해 적절한 호스트 이름으로 매핑되지 않으면 스팸으로 간주하거나 메일을 거부할 수 있습니다.예:IP: 192.168.0.28리버스 DNS: mail.example.com리버스 DNS가 설정되어 있으..

**BIND에서 "Zone"**은 DNS 도메인 이름 공간의 일부를 관리하기 위한 데이터 단위를 의미합니다. Zone은 특정 도메인과 그 하위 도메인에 대한 정보를 포함하며, DNS 서버가 해당 Zone에 대한 질의(쿼리)를 처리할 수 있도록 구성됩니다. Zone의 주요 개념도메인과의 관계:Zone은 도메인의 정보와 DNS 레코드(A, MX, NS 등)를 정의하는 파일입니다.DNS 서버는 해당 Zone 파일을 사용하여 해당 도메인과 관련된 요청을 처리합니다.권한(authority):Zone은 **권한이 있는 DNS 서버(Authoritative DNS Server)**에서 관리됩니다.권한이 있는 서버는 해당 Zone에 대해 정확하고 신뢰할 수 있는 응답을 제공합니다.하위 도메인 관리:하나의 Zone이 여..

LDAP(Lightweight Directory Access Protocol)을 사용하는 시스템에서 /etc/nsswitch.conf, /etc/pam.d/common-password, /etc/pam.d/common-session, /etc/pam.d/common-auth 파일들은 사용자 인증 및 시스템 자원 접근을 관리하는 중요한 역할을 합니다. 1. /etc/nsswitch.conf역할: nsswitch.conf 파일은 Name Service Switch의 설정 파일로, 시스템이 사용자, 그룹, 호스트 이름 등 다양한 정보 소스를 어떻게 조회할지 정의합니다. 이 파일을 통해 시스템은 로컬 파일, LDAP, NIS 등 여러 소스에서 정보를 가져올 수 있습니다.LDAP와의 관계: LDAP을 사용자 정보..

Stateless 애플리케이션이란?Stateless 애플리케이션은 클라이언트의 요청을 처리할 때 어떠한 상태를 유지하지 않는 애플리케이션입니다. 요청 간에 데이터나 상태를 저장하지 않으므로, 모든 요청은 독립적으로 처리됩니다. 이 특성 덕분에 수평 확장(Scaling) 및 **HA(High Availability)**를 구현하기 쉽습니다.  Stateless 애플리케이션의 예시API 서버예: Node.js, Flask, Express, Spring Boot 등으로 작성된 RESTful API.클라이언트 요청을 처리하고 데이터베이스와 통신한 후 결과를 반환하지만, 요청 처리 완료 후 상태를 유지하지 않음.웹 서버예: Nginx, Apache HTTP Server, Node.js로 만들어진 정적/동적 웹 서..

Stateful 애플리케이션은 데이터를 지속적으로 저장하고, 해당 데이터의 상태에 따라 작동하는 애플리케이션을 의미합니다. 이 애플리케이션은 이전 작업의 상태를 기억해야 하며, 이를 기반으로 다음 작업을 처리합니다. 1. 데이터베이스예시:MySQLPostgreSQLMongoDBRedisCassandra특징:데이터베이스는 클라이언트 요청을 처리하고 데이터를 저장해야 합니다.노드 간 데이터 일관성(consistency)을 유지하는 것이 중요합니다.Kubernetes에서 **Persistent Volume(PV)**을 사용해 데이터를 지속적으로 유지해야 합니다. 2. 메시지 브로커예시:RabbitMQApache KafkaActiveMQ특징:메시지 브로커는 메시지를 큐(queue)에 저장하여 처리하거나 전달해야..

1. 노드가 다운되었을 때 발생하는 문제클러스터에서 **노드(Node)**가 다운되면, 해당 노드에서 실행 중이던 Pod에 접근할 수 없게 됩니다.Pod가 여러 복제본(Replicas)으로 구성된 경우:예: 블루 Pod는 여러 복제본이 있어 다른 노드에서 서비스가 계속 제공되므로 사용자에게 영향이 없음.Pod가 단일 인스턴스로 실행 중인 경우:예: 그린 Pod는 다른 복제본이 없으므로 사용자에게 서비스가 중단됨.2. Kubernetes의 동작 원리노드가 빠르게 복구된 경우:노드가 빠르게 복구되면, kubelet이 다시 시작되어 Pod가 정상적으로 실행됩니다.노드가 5분 이상 다운된 경우:Kubernetes는 기본적으로 5분간 노드 상태를 감시하다가 노드가 복구되지 않으면 Pod을 종료(terminate)..