Загружаем каталог…
Загружаем каталог…
260917 SKT ALEPH K-뉴딜 아카데미 AI 보안·네트워크 분야의 실무형 AX 교육 프로그램 🖥️실습 목표 Docker Compose로 Web·PEP·PDP를 분리해 실행하고, 컨테이너 간 요청이 전달되는 구조를 확인했다. 또한 자주 변경되는 회사 정보를 이미지 밖으로 분리하고, 동기화·재시작·재Build가 필요한 경우의 차이를 확인했다. ⌨️실습 1. Docker Compose로 여러 서비스 실행하기 📌 1. Service와 Compose Project의 차이 services: 아래의 web , pep , pdp 는 각각 하나의 서비스를 정의한다. Service : 하나의 컨테이너을 어떻게 실행할지 정의한 설정 Compose Project : compose.yaml 을 기준으로 함께 관리하는 서비스 전체 docker compose up -d 를 실행하면 여러 서비스를 한 번에 실행할 수 있다. 📝 image , build , command 가 헷갈렸던 부분 web: image: nginx:1.28 pep: build: ./app command: python pep.py pdp: build: ./app command: python pdp.py image 는 이미 만들어진 이미지를 사용하고, build 는 지정된 폴더를 바탕으로 이미지를 만든다. PEP와 PDP는 모두 build: ./app 을 사용하지만 실행하는 명령이 다르다. 같은 ./app을 바탕으로 만든 이미지 ├─ command: python pep.py → PEP 실행 └─ command: python pdp.py → PDP 실행 따라서 build 는 이미지를 준비하는 과정이고, command 는 컨테이너에서 실제로 실행할 프로그램을 결정한다. ⌨️실습 2. Web → PEP → PDP로 요청 전달하기 📌 2. Windows 포트와 컨테이너 내부 포트 이번 실습에서 가장 헷갈렸던 부분은 8080 , 8090 , 8091 과 80 , 5000 , 5001 의 관계였다. 브라우저 localhost:8080 ↓ web:80 ↓ pep:5000 ↓ pdp:5001 예를 들어 PDP에는 다음과 같이 포트를 연결했다. ports: - "127.0.0.1:8091:5001" Windows에서 PDP에 직접 접근할 때는 localhost:8091 을 사용한다. 반면 PEP와 PDP는 같은 Compose 네트워크 안에 있으므로 PEP가 PDP를 찾을 때는 Windows의 8091 을 거치지 않는다. PEP → http://pdp:5001 📝 127.0.0.1 이 헷갈렸던 부분 127.0.0.1 은 항상 Windows를 의미하는 주소가 아니다. 그 주소를 사용하는 자기 자신 을 의미한다. 따라서 PEP 컨테이너에서 127.0.0.1:5001 로 요청하면 PDP가 아니라 PEP 컨테이너 자신의 5001번 포트를 찾게 된다. Compose 내부에서는 다른 컨테이너를 서비스 이름으로 찾을 수 있기 때문에 PDP는 pdp:5001 로 접근한다. ⌨️실습 3. PEP와 PDP 역할 분리하기 📌 3. PEP와 PDP는 무엇을 나눠서 하는가? 사용자 요청 ↓ PEP ↓ 판단 요청 PDP ↓ ALLOW / DENY PEP ↓ 실제 요청 처리 PDP는 접근 가능 여부를 판단 하고, PEP는 그 판단을 받아 실제 요청에 적용 한다. PDP가 계약서 제목이나 금액을 사용자에게 직접 전달하는 것이 아니라, ALLOW 또는 DENY 판단을 PEP에 돌려준다. PEP가 PDP를 찾을 주소는 환경변수로 전달했다. environment: - PDP_URL=http://pdp:5001 따라서 서비스 이름을 pdp 에서 judge 로 변경한다면 PEP가 사용하는 주소도 함께 변경해야 한다. 📝 403 과 503 의 차이 두 경우 모두 계약서를 받을 수 없지만 의미가 다르다. 403 PEP → PDP 요청 성공 ↓ DENY 판단 503 PEP → PDP 통신 실패 ↓ 판단을 받지 못함 PDP에 장애가 발생해 판단할 수 없는 경우에도 PEP는 계약서를 제공하지 않는다. 즉, 판단할 수 없는 상황에서는 기본적으로 접근을 허용하지 않는 fail-closed 방식으로 동작한다. ⌨️실습 4. 회사 정보를 이미지 밖으로 분리하기 📌 4. company.json 을 매번 Build하지 않도록 변경 기존에는 company.json 이 이미지에 포함되어 있어 회사 정보를 수정하면 이미지를 다시 Build해야 했다. 이번에는 회사 정보를 외부에 두고 volume으로 연결했다. pdp: environment: - COMPANY_FILE=/app/data/company.json volumes: - ./data:/app/data:ro 두 설정의 역할은 다르다. volumes : Windows의 ./data 와 컨테이너의 /app/data 를 연결 COMPANY_FILE : PDP에게 읽어야 할 파일의 위치를 알려줌 :ro : 컨테이너에서는 해당 파일을 읽기만 가능 즉, environment 가 파일을 동기화하는 것이 아니다. 실제 파일 연결은 volumes 가 담당한다. 📝 동기화와 restart가 헷갈렸던 부분 Windows에서 company.json 을 수정하면 volume으로 연결된 컨테이너의 파일도 변경된다. Windows ./data/company.json ↓ volume PDP 컨테이너 /app/data/company.json 여기까지가 동기화 다. 하지만 현재 pdp.py 는 프로그램을 시작할 때 파일을 한 번 읽는다. with open(COMPANY_FILE, encoding="utf-8-sig") as file: company = json.load(file) 따라서 파일이 동기화되더라도 이미 실행 중인 PDP가 기억하고 있는 company 값까지 자동으로 바뀌지는 않는다. 이때 PDP를 재시작하면 파일을 다시 읽는다. company.json 수정 ↓ volume으로 파일 동기화 ↓ PDP restart ↓ 변경된 company.json 다시 읽기 즉, 동기화 : 컨테이너가 최신 파일을 볼 수 있게 한다. restart : 프로그램이 최신 파일을 다시 읽게 한다. rebuild : 변경된 코드 등을 포함하여 이미지를 다시 만든다. company.json 처럼 volume으로 외부에 분리한 데이터는 수정할 때마다 이미지를 다시 Build할 필요가 없다.
То, что RADAR обнаружил и классифицировал для этой возможности. Это опубликованный источником текст, а не подтверждение, что предложение ещё действует.
02. 네트워크·ZT 운영 기초 | Day 8 PEP·PDP 두 서버 운영 — 설정 파일·요청 로그·장애 복구. 260917 SKT ALEPH K-뉴딜 아카데미 AI 보안·네트워크 분야의 실무형 AX 교육 프로그램 🖥️실습 목표 Docker Compose로 Web·PEP·PDP를 분리해 실행하고, 컨테이너 간 요청이 전달되는 구조를 확인했다. 또한 자주 변경되는 회사 정보를 이미지 밖으로 분리하고, 동기화·재시작·재Build가 필요한 경우의 차이를 확인했다. ⌨️실습 1. Docker Compose로 여러 서비스 실행하기 📌 1. Service와 Compose Project의 차이 services: 아래의 web , pep , pdp 는 각각 하나의 서비스를 정의한다. Service : 하나의…
Открыть источник