최근 Windows 환경에서 Docker를 사용해 Python Django 앱을 실행하던 중 예상치 못한 문제가 발생했습니다. uWSGI를 통해 서버를 구동하려고 했으나, 아래와 같은 에러 메시지가 출력되었습니다

 

Thu Nov 21 16:29:43 2024 - *** uWSGI listen queue of socket ":8000" (fd: 3) full !!! (18956672/16384) ***

 

문제 상황

Docker Desktop for Windows와 WSL 2를 사용 중이었으며, Ubuntu 배포판을 기본 WSL 환경으로 설정해 Docker 컨테이너를 실행하고 있었습니다. 하지만 위와 같은 에러가 지속적으로 발생하며 컨테이너가 제대로 작동하지 않았습니다.

해결 과정

이 문제를 해결하기 위해 다음 단계를 진행했습니다:

    • WSL 설정 확인 및 수정
      • Docker Desktop 설정에서 Resources > WSL integration 항목을 확인했습니다.
      • 아래 이미지처럼 기본 WSL 통합 설정이 활성화되어 있었고, 추가로 Ubuntu 배포판도 통합 대상으로 설정되어 있었습니다.

 

 

 

  • Refetch Distros
    • "Refetch distros" 버튼을 클릭해 WSL 통합 배포판 정보를 다시 가져왔습니다.
  • Docker 재시작
    • Docker Desktop을 완전히 종료하고 다시 실행했습니다.
  • 컨테이너 및 이미지 초기화
    • 문제를 일으킨 컨테이너를 중지하고 삭제했습니다.
    • 관련 이미지를 모두 삭제한 후, docker-compose를 사용해 빌드를 새로 진행했습니다.

 

결과

위 단계를 수행한 후 uWSGI 관련 에러가 더 이상 발생하지 않았습니다. Django 앱은 정상적으로 실행되었고, Docker와 WSL 통합 설정의 문제가 원인이었음을 확인할 수 있었습니다.

결론

Windows에서 Docker와 WSL 2를 활용할 때, 설정 불일치로 인해 다양한 문제가 발생할 수 있습니다. 특히 WSL 통합 설정과 관련하여 문제가 발생했을 경우:

  • WSL 통합 설정을 확인 및 업데이트
  • Docker Desktop 재시작
  • 컨테이너와 이미지를 초기화하고 새로 빌드

 

 

 

드물게 사용자에게 SSMS 설치 문제가 발생하는 경우가 있으며 일반적인 오류 메시지는 다음과 같습니다.

  • "MSI 패키지를 설치할 수 없음"
  • “Microsoft ODBC Driver 17 for SQL Server: 이전 설치에서는 변경 사항을 적용하려면 컴퓨터를 재부팅해야 했습니다.”
  • “설치 중에 오류 발생(0x80070643)”

제안된 해결 방법

앞서 언급한 또는 유사한 오류 메시지 중 하나가 표시되면서 설치가 실패하는 경우 일반적으로 SSMS 설치를 시작하기 전에 다음 단계에 따라 "Microsoft ODBC driver 17 for SQL Server"를 제거하면 설치가 성공할 수 있습니다.

  1. SSMS, Visual Studio 또는 SQL Server Profiler를 비롯한 모든 관련 애플리케이션을 닫습니다.
  2. 제어판 > 프로그램 추가/제거로 이동합니다.
  3. "Microsoft ODBC Driver 17 for SQL Server" 항목을 찾아 제거합니다. 이 단계에서 다시 시작해야 할 수 있습니다.
  4. SSMS 설치를 시작합니다. 최신 버전은 여기에서 사용할 수 있습니다.

 

방법이 안된다면

레지스트리 에디터 (실행 win + R -> regedit)

 

컴퓨터\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager

위 경로로 이동

PendingFileRenameOperations 삭제 후 재설치

소개

FTP 서버는 액티브 모드와 패시브 모드를 지원합니다. 패시브 모드는 클라이언트가 서버에 연결할 때 방화벽 및 NAT(Network Address Translation) 환경에서의 문제를 줄이기 위해 사용됩니다. 이 블로그 포스트에서는 패시브 모드를 설정하고, 일반적인 문제를 해결하는 방법을 안내합니다.

 

패시브 모드란?

패시브 모드는 클라이언트가 서버에 연결할 때, 서버가 클라이언트에게 데이터 전송을 위한 포트 정보를 제공하는 방식입니다. 액티브 모드와 달리, 패시브 모드에서는 클라이언트가 데이터 연결을 설정하므로 방화벽과 NAT 환경에서의 문제를 줄일 수 있습니다.

 

패시브 모드 설정 방법

1. vsftpd.conf 파일 설정

패시브 모드를 활성화하려면 /etc/vsftpd/vsftpd.conf 파일에서 적절한 설정을 추가해야 합니다.

  1. 패시브 모드 활성화
  2. 패시브 모드를 활성화하려면 다음 설정을 추가합니다:
pasv_enable=YES

 

포트 범위 지정

패시브 모드에서는 서버가 클라이언트에 사용할 포트 범위를 알려줘야 합니다. 다음 설정을 통해 포트 범위를 지정합니다:

pasv_min_port=12000
pasv_max_port=12100

 

 

EC2 인스턴스에서 포트 방화벽 설정

AWS EC2에서는 보안 그룹(Security Groups)과 네트워크 ACLs(Network Access Control Lists)를 사용하여 인스턴스의 네트워크 트래픽을 제어합니다. 패시브 모드 포트를 열어주려면 다음 단계를 따르세요.

1. 보안 그룹 설정

  1. AWS Management Console에 로그인합니다.
  2. EC2 대시보드에서 '보안 그룹'을 선택합니다.
  3. 해당 보안 그룹을 선택하고, '인바운드 규칙' 탭을 클릭합니다.
  4. '편집' 버튼을 클릭하여 인바운드 규칙을 추가합니다:
    • 프로토콜: TCP
    • 포트 범위: 21, 12000-12100
    • 소스: 원하는 IP 범위 (예: 0.0.0.0/0 또는 특정 IP)
  5. '저장' 버튼을 클릭하여 규칙을 적용합니다.

2. 네트워크 ACLs 설정

  1. AWS Management Console에 로그인합니다.
  2. VPC 대시보드에서 '네트워크 ACLs'를 선택합니다.
  3. 해당 네트워크 ACL을 선택하고, '인바운드 규칙' 탭을 클릭합니다.
  4. '편집' 버튼을 클릭하여 인바운드 규칙을 추가합니다:
    • 소스: 원하는 IP 범위 (예: 0.0.0.0/0 또는 특정 IP)
    • 프로토콜: TCP
    • 포트 범위: 21, 12000-12100
    • 허용: 허용
  5. '저장' 버튼을 클릭하여 규칙을 적용합니다.

 

계정의 홈 디렉토리가 디폴트와 다른 경우 아래 포스팅 설정을 적용합니다.

https://yes5.tistory.com/60

 

FTP 서버 설정 문제 해결 가이드: 21번 포트와 22번 포트에서의 디렉토리 접근 문제

소개FTP 서버를 설정할 때, 여러 가지 문제에 직면할 수 있습니다. 특히 포트 21번과 22번에서의 디렉토리 접근 문제는 자주 발생하는 이슈 중 하나입니다. 이 포스트에서는 포트 21번에서 디렉토

yes5.tistory.com

 

소개

FTP 서버를 설정할 때, 여러 가지 문제에 직면할 수 있습니다. 특히 포트 21번과 22번에서의 디렉토리 접근 문제는 자주 발생하는 이슈 중 하나입니다. 이 포스트에서는 포트 21번에서 디렉토리 접근이 제대로 되지 않는 문제를 해결하기 위한 단계별 가이드를 제공합니다.

 

문제 설명

FTP 서버를 설정한 후, 포트 22번에서는 홈 디렉토리 접근이 잘 되지만 포트 21번에서는 디렉토리 접근이 제대로 되지 않는 경우가 있습니다. 특히, uploaduser라는 계정의 홈 디렉토리가 기본 디렉토리가 아닌 /home/upload로 설정된 경우, 포트 22번에서는 정상적으로 접근되지만, 포트 21번에서는 루트 디렉토리(/)만 보이는 문제가 발생할 수 있습니다.

 

문제 원인

포트 21번의 문제는 chroot 설정과 관련이 있습니다. chroot는 사용자가 자신의 홈 디렉토리 외부로 접근하지 못하도록 제한하는 기능입니다. chroot가 적용되면, 사용자는 홈 디렉토리의 루트(/)를 볼 수 있게 됩니다.

 

문제 해결 방법

1. vsftpd.conf 파일 수정

  1. chroot_local_user 설정 확인: vsftpd.conf 파일에서 chroot_local_user와 관련된 설정을 확인합니다.
sudo vi /etc/vsftpd/vsftpd.conf

 

 

  • chroot_local_user=YES가 설정되어 있으면, 모든 로컬 사용자가 자신의 홈 디렉토리로 제한됩니다.
  • allow_writeable_chroot=YES는 홈 디렉토리에서 쓰기 권한을 허용합니다.
chroot_local_user=YES
allow_writeable_chroot=YES

 

 

 

특정 사용자에 대한 예외 설정: rankingfiles와 같은 특정 사용자에게 예외를 설정할 수 있습니다.

  • chroot_list_enable=YES와 chroot_list_file 옵션을 활성화합니다.
chroot_list_enable=YES
chroot_list_file=/etc/vsftpd/chroot_list

 

  • /etc/vsftpd/chroot_list 파일에 rankingfiles 사용자를 추가합니다.
sudo echo "uploaduser" >> /etc/vsftpd/chroot_list

 

Dockerfile을 작성할 때 Amazon Linux 2 이미지를 사용하려면, 보통 Docker Hub에서 다음과 같은 명령어를 사용해 가져옵니다:

FROM amazonlinux:2

 

이 명령어는 Docker Hub에서 Amazon Linux 2 이미지를 다운로드합니다. 하지만 이미지 요청 수 제한으로 인해 에러가 발생할 수 있습니다.

 

요청 수 제한 문제

Docker Hub는 익명 사용자와 무료 계정 사용자의 이미지 풀 요청 수에 제한을 두고 있습니다. 이에 따라 다음과 같은 에러 메시지를 볼 수 있습니다:

toomanyrequests: too many requests: You have reached your pull rate limit. You may increase the limit by authenticating and upgrading: https://www.docker.com/increase-rate-limit

익명 사용자는 6시간 동안 100개의 요청 제한, 무료 계정 사용자는 6시간 동안 200개의 요청 제한을 받습니다.

 

해결 방법: AWS ECR Public Gallery 사용

이 문제를 해결하는 한 가지 방법은 Docker Hub 대신 AWS ECR Public Gallery에서 이미지를 가져오는 것입니다. AWS ECR은 이미지에 대한 요청 제한이 없으며, 특히 Amazon Linux 이미지를 제공하는 신뢰할 수 있는 리포지토리입니다. 다음과 같이 Dockerfile을 수정하여 AWS ECR에서 이미지를 가져올 수 있습니다:

FROM public.ecr.aws/amazonlinux/amazonlinux:2

 

 

이 오류는 원격 저장소에 이미 존재하는 커밋이 있고, 그 내용이 로컬 저장소와 충돌하기 때문에 발생한 것입니다. 이런 상황에서는 로컬 저장소와 원격 저장소의 변경 사항을 통합해야 합니다. 이를 해결하는 방법은 git pull 명령어로 원격 저장소의 변경 사항을 로컬에 가져온 후, 충돌을 해결하고 다시 push하는 것입니다.

다음 절차로 진행하세요:

1. 원격 변경 사항을 로컬로 가져오기 (pull)

먼저, 원격 저장소에서 최신 변경 사항을 로컬로 가져옵니다.

git pull origin main --rebase



2. 다시 Push

변경 사항을 통합하고 나서, 이제 다시 push합니다.

git push origin main

 

 

 

전제 조건

  • Windows 버전: Windows 10 버전 2004 이상 (빌드 19041 이상) 또는 Windows 11이 필요합니다.

 

CMD창에 아래 명령어를 입력합니다.

wsl --shutdown

 

 

bios에서 가상화 기술(VT-x / AMD-V) 활성화

 

가상화 기술 활성화 방법 (일반적인 단계)

  1. 컴퓨터를 재부팅합니다:
    • 컴퓨터를 완전히 종료한 후 다시 켭니다.
  2. BIOS 설정으로 들어갑니다:
    • 부팅 과정에서 BIOS 설정으로 들어가기 위해 특정 키를 눌러야 합니다. 일반적으로 사용하는 키는 F2, F10, Del, Esc, 또는 F12입니다. 제조사마다 다를 수 있으므로 부팅 시 화면에 표시되는 메시지를 참고하세요.
  3. BIOS 메뉴 탐색:
    • BIOS 설정에 들어가면 키보드의 방향키를 사용하여 메뉴를 탐색합니다. Advanced, Configuration, Security, 또는 System Configuration 같은 메뉴를 찾습니다.
  4. 가상화 옵션 찾기:
    • 가상화 기술을 활성화하는 옵션은 Intel Virtualization Technology, VT-x, Vanderpool, AMD-V, SVM 등으로 표시될 수 있습니다. 이는 CPU의 제조사에 따라 다릅니다.
    • Advanced 또는 CPU Configuration 섹션에 위치해 있을 가능성이 높습니다.
  5. 가상화 기술 활성화:
    • 해당 옵션을 찾은 후 Disabled로 설정되어 있으면 이를 Enabled로 변경합니다. 이를 위해 Enter 키를 눌러 설정을 변경합니다.
  6. 변경 사항 저장 및 종료:
    • 설정을 변경한 후 BIOS 메뉴에서 Save & Exit 또는 Exit를 선택하여 변경 사항을 저장하고 BIOS 설정에서 나옵니다. 일반적으로 F10 키를 눌러 저장하고 종료할 수 있습니다.
  7. 컴퓨터 재부팅:
    • 변경 사항을 저장하고 BIOS 설정에서 나가면 컴퓨터가 재부팅됩니다. 이제 가상화 기술이 활성화된 상태에서 운영체제가 부팅됩니다.

참고 이미지 예시

  1. Intel BIOS 예시:
    • Advanced > CPU Configuration > Intel Virtualization Technology로 이동하여 Enabled로 설정합니다.
  2. AMD BIOS 예시:
    • Advanced > CPU Configuration > SVM Mode 또는 Advanced > Advanced Chipset Settings > SVM로 이동하여 Enabled로 설정합니다.

BIOS 메뉴에서 가상화 기술 활성화

  • ASUS:
    • Advanced > CPU Configuration > Intel Virtualization Technology > Enabled
  • Gigabyte:
    • M.I.T. > Advanced Frequency Settings > Advanced CPU Core Features > Intel Virtualization Technology > Enabled
  • HP:
    • Security > System Security > Virtualization Technology > Enabled
  • Dell:
    • Virtualization Support > Virtualization > Enabled

위 절차를 통해 BIOS에서 가상화 기술을 활성화하면, 가상 머신 소프트웨어(VMware, VirtualBox 등)에서 가상화를 사용할 수 있게 됩니다. BIOS 메뉴는 제조사와 모델에 따라 다를 수 있으므로, 정확한 메뉴 위치는 해당 메인보드나 노트북의 사용자 매뉴얼을 참고하는 것이 좋습니다.

 

가상화 기술(VT-x / AMD-V) 활성화 후 cmd창에서 아래 명령어를 입력합니다.

wsl --install

 

1. jenkins 배포 중 No space left on device 발생

2.  /var/lib/docker/overlay2 용량 문제 확인

원인

/var/lib/docker/overlay2 가 용량이 큰 경우 diff/tmp 에 컨테이너 내부 파일구조 변경 사항들이 과도하게 쌓였기 때문.

 

  1. Docker 컨테이너는 여러 레이어로 구성된 이미지를 기반으로 실행됩니다. 각 레이어는 독립적인 파일 시스템을 가지며, Docker는 이를 효율적으로 관리하기 위해 스토리지 드라이버를 사용합니다.
  2. 이번 문제의 원인인 overlay2 드라이버는 Linux의 OverlayFS를 활용해 여러 디렉토리를 하나로 겹쳐 사용하는 유니온 파일 시스템입니다. 컨테이너 실행 중 기존 레이어에 변경 사항이 생기면, 해당 변경 사항만 새로운 레이어에 저장하는 Copy-on-Write(CoW) 전략을 사용하여 필요한 부분만 저장합니다. overlay2의 diff/tmp에 변경 사항이 과도하게 쌓이면 /var/lib/docker/overlay2 경로의 용량이 커질 수 있습니다.

해결

  1. 미사용 이미지, 컨테이너, 볼륨 정리: docker system prune -a --volumes 명령어를 사용하면 중지된 컨테이너와 사용하지 않는 이미지, 네트워크, 볼륨을 안전하게 삭제할 수 있습니다.
  2. 특정 이미지 또는 컨테이너 삭제: 더 이상 필요하지 않은 이미지나 컨테이너만 개별적으로 삭제할 수 있습니다 (docker rmi와 docker rm 명령어 사용).

이처럼 안전하게 정리할 수 있는 명령어로 overlay2의 공간을 확보하는 것이 좋습니다.

+ Recent posts