네이버 부동산 데이터 스크래퍼 소개 & 컨테이너 배포 가이드 (파이썬)

📌 네이버 부동산 데이터 스크래퍼를 소개합니다!

네이버 부동산에서 매물을 지도 기반으로만 보다 보면, 모든 매물을 한눈에 확인하기 어렵고, 원하는 조건의 매물을 빠르게 찾기 힘든 경우가 많습니다.

이제는 네이버 지도 그래픽 환경의 검색 뿐만 아니라, 엑셀처럼 정리된 데이터 형태로 부동산 매물을 검색해보세요!
지역별, 가격별, 평형별로 필터링하며 원하는 정보를 손쉽게 찾을 수 있습니다.

누구나 쉽게 사용할 수 있도록 만든 도구입니다.
필요한 정보를 빠르게 찾고, 현명한 선택에 도움되길 바랍니다.


사용 방법은 네이버 부동산 들어가셔서 URL에서 숫자를 확인하고 입력하시기만 하면 됩니다. 이 화면에서는 131345를 사용하시면 됩니다.


그리고 나서 131455 숫자를 입력하시고 매물 검색을 합니다.




이제부터는 깃코드로 애플리케이션을 컨테이너 환경으로 만드는 절차를 설명 합니다.

코드는 다음과 깃허브 참고하세요.
https://github.com/dslee1371/scraper_trade_rs_stream

컨테이너화

1. 깃 클론
2. 빌드
3. 도커 이미지 태그 변경

4. 도커 푸쉬


앱배포

Deployments

apiVersion: v1
items:
- apiVersion: apps/v1
  kind: Deployment
  metadata:
    labels:
      workload.user.cattle.io/workloadselector: apps.deployment-naver-rs-scraper-deploy-naver-rs-scraper
    name: deploy-naver-rs-scraper
    namespace: naver-rs-scraper
  spec:
    progressDeadlineSeconds: 600
    replicas: 1
    revisionHistoryLimit: 10
    selector:
      matchLabels:
        workload.user.cattle.io/workloadselector: apps.deployment-naver-rs-scraper-deploy-naver-rs-scraper
    strategy:
      rollingUpdate:
        maxSurge: 25%
        maxUnavailable: 25%
      type: RollingUpdate
    template:
      metadata:
        creationTimestamp: null
        labels:
          workload.user.cattle.io/workloadselector: apps.deployment-naver-rs-scraper-deploy-naver-rs-scraper
        namespace: naver-rs-scraper
      spec:
        affinity: {}
        containers:
        - image: 172.10.30.11:5000/dslee/scraper_trade_rs_stream:v0.1
          ports:
          - containerPort: 8501
          imagePullPolicy: Always
          name: container-0
          resources: {}
          securityContext:
            allowPrivilegeEscalation: false
            privileged: false
            readOnlyRootFilesystem: false
            runAsNonRoot: false
          terminationMessagePath: /dev/termination-log
          terminationMessagePolicy: File
        dnsPolicy: ClusterFirst
        restartPolicy: Always
        schedulerName: default-scheduler
        securityContext: {}
        terminationGracePeriodSeconds: 30
kind: List
metadata:
  resourceVersion: ""

Service

apiVersion: v1
kind: Service
metadata:
  name: svc-naver-rs-scraper
  namespace: naver-rs-scraper
spec:
  selector:
    workload.user.cattle.io/workloadselector: apps.deployment-naver-rs-scraper-deploy-naver-rs-scraper
  ports:
    - name: http
      port: 8501
      protocol: TCP
      targetPort: 8501
  type: ClusterIP

Ingress

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/proxy-connect-timeout: "30"
    nginx.ingress.kubernetes.io/proxy-read-timeout: "1800"
    nginx.ingress.kubernetes.io/proxy-send-timeout: "1800"
    nginx.ingress.kubernetes.io/ssl-redirect: "false"
  name: ingress-naver-rs-scraper
  namespace: naver-rs-scraper
spec:
  ingressClassName: nginx
  rules:
  - host: naver-rs-scraper.apps.lab3.dslee.lab
    http:
      paths:
      - backend:
          service:
            name: svc-naver-rs-scraper
            port:
              number: 8501
        path: /

참고

통신검증 예시 - 외부파드에서 서비스 포트 체크

kubectl run tmp-shell -n naver-rs-scraper --rm -it --image=busybox -- /bin/sh
wget -qO- http://svc-naver-rs-scraper:8501

댓글

댓글 쓰기

이 블로그의 인기 게시물

10.15 부동산 대책, 오피스텔도 LTV 40%인가요? 혼선 정리

라벨: 부동산대책 , 10·15대책 , 오피스텔 , LTV , 비주택대출 , 부동산정책 , 서울규제지역 , 대출규제 , 토지거래허가구역 , 정책해설 10월 15일 발표된 부동산 대책(10·15 대책) 이후 “오피스텔도 LTV 40% 로 줄었다”는 말이 돌고 있습니다. 하지만 이는 초기 문서와 보도 간 혼선 에서 비롯된 것으로, 정부 공식 해명에 따르면 비주택(오피스텔·상가)은 기존 LTV 70% 유지 가 맞습니다. 즉, 주택만 규제지역 지정으로 LTV 70% → 40% 이 적용됩니다. 1️⃣ 이번 대책의 핵심 변경점 규제지역 확대: 서울 전역과 경기 12곳이 조정대상지역·투기과열지구로 지정되었습니다. 주택 LTV: 규제지역 내 주택 구입 시 LTV 70% → 40% 로 하향 조정되었습니다. 토지거래허가구역: 서울 전역이 포함되며, 10월 20일경부터 효력이 발생합니다. 즉, 이번 대책의 직접적 영향은 **아파트 등 주택담보대출** 중심으로 적용됩니다. 2️⃣ “오피스텔도 40%?” — 혼선의 원인 정부 발표문 초안에는 “비주택 담보대출(오피스텔·상가) LTV 70% → 40%” 라는 문구가 포함되어 있었습니다. 언론이 이 문장을 그대로 인용하면서 “오피스텔도 40%로 제한된다”는 보도가 확산되었습니다. 하지만 이후 국토교통부와 금융위원회는 “ 비주택은 이번 규제 적용 대상이 아니다 ”라고 정정했습니다. 따라서 실제로는 **오피스텔 대출은 기존 70% LTV가 유지됩니다.** 3️⃣ 정부의 공식 정정 내용 오피스텔·상가 등은 비주택 으로 분류되어, 이번 주택담보대출 규제의 직접 적용 대상이 아님. ‘비주택 LTV 40%’ 표기는 자료 작성 오류 또는 과도한 포괄 표현 이었다고 정부가 해명함. 따라서 실무상으로는 기존처럼 LTV 70% 수준의 대출이 유지됩니다. 4️⃣ 실제로 어떻게 확인하면 될까요? 현재 금융기관별로 시행령 및 세부지...
자세한 내용 보기

Kubernetes Pod Pending 해결법: FailedScheduling 원인별 실전 점검 가이드

이미지
Kubernetes를 운영하다 보면 Deployment를 배포했는데 Pod가 Pending 상태에서 움직이지 않는 경우가 있습니다. 재시작부터 해보거나 무작정 노드를 증설하기 전에, 스케줄러가 남긴 이벤트를 읽으면 대부분의 원인을 빠르게 찾을 수 있습니다. 이 글에서는 실무에서 자주 만나는 FailedScheduling 메시지를 기준으로 CPU·메모리 부족, taint, nodeSelector, PVC, Pod 수 제한 문제를 순서대로 점검하는 방법을 정리합니다. 1. Pending은 장애 원인이 아니라 현재 상태다 Pending은 Pod 객체가 생성됐지만 아직 실행할 노드가 결정되지 않았거나, 컨테이너 실행에 필요한 준비가 끝나지 않았다는 뜻입니다. 따라서 kubectl get pods 결과만 보고는 원인을 알 수 없습니다. kubectl get pods -A --field-selector=status.phase=Pending 문제가 발생한 Pod를 찾았다면 가장 먼저 상세 정보와 이벤트를 확인합니다. kubectl describe pod <pod-name> -n <namespace> kubectl events -n <namespace> --for pod/<pod-name> describe 출력의 맨 아래 Events 영역에 있는 Reason과 Message가 핵심입니다. 여러 메시지가 반복된다면 가장 최근의 Warning / FailedScheduling 부터 읽습니다. 2. 가장 흔한 원인: CPU 또는 메모리 부족 다음과 같은 메시지가 보인다면 Pod가 요청한 리소스를 수용할 노드가 없다는 뜻입니다. 0/3 nodes are available: 3 Insufficient cpu. 0/3 nodes are available: 2 Insufficient memory. Kubernetes 스케줄러는 현재 사용률이 아니라 Pod에 설정된 resources.requests 의 합계를 기준으로...
자세한 내용 보기

애플 비전 프로 새 밴드 착용감 어떨까? Dual Knit Band 착용 경험 리뷰

새 밴드 착용감 어떨까? Dual Knit Band 착용 경험 리뷰 Apple Vision Pro의 Dual Knit Band 는 착용감과 안정성을 개선하기 위한 새로운 밴드 설계입니다. 본 글은 공개된 정보와 초기 평가를 참고해 착용 체감, 무게 분산, 통기성, 핏 조절 을 중심으로 정리했습니다. (실제 체감은 두상·머리 형태 및 사용 환경에 따라 달라질 수 있습니다.) 1) Dual Knit Band는 무엇이 달라졌습니까? 이중(dual) 구조 : 상단/후면 스트랩 분리 설계로 무게를 분산합니다. 통기성 니트 소재 : 장시간 착용 시 답답함을 줄이는 것을 목표로 합니다. Fit Dial 조절: 좌우 다이얼로 상·하 스트랩을 미세 조정해 개개인 핏을 맞출 수 있습니다. 사이즈 옵션 : 보통 Small / Medium / Large 선택지를 제공합니다. 호환성 : 지역/판매 정책에 따라 다를 수 있으나, 기존 모델과 호환 가능하다는 보도가 있습니다. 2) 착용감 체감 포인트 항목 체감 요약 코멘트 압박감 얼굴 전면 압박이 다소 완화 상·후면으로 무게가 나뉘어 이마/광대 압박이 줄어드는 느낌입니다. 무게 분산 뒤쪽 밸런스 향상 후두부 쪽 지지가 늘어 장시간 사용에서 안정감이 개선되었습니다. 통기성 열감/답답함 완화 니트 소재 특성상 땀·열 배출이 이전 대비 자연스럽습니다. 핏 조절 미세 조정 용이 ...
자세한 내용 보기