Loading the catalog…
Loading the catalog…
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할 필요가 없다.
What RADAR observed and classified to build this opportunity. It is what the source published, not a verification that the offer is still active.
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 : 하나의…
Open source