지식은 날리지

최근 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 컨테이너를 실행하고 있었습니다. 하지만 위와 같은 에러가 지속적으로 발생하며 컨테이너가 제대로 작동하지 않았습니다.

해결 과정

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

1. • 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번에서의 디렉토리 접근 문제는 자주 발생하는 이슈 중 하나입니다. 이 포스트에서는 포트 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

1. Git 설치

1.1. Git 다운로드

• Git 공식 웹사이트로 이동합니다.
• 다운로드 페이지에서 Windows용 Git 설치 파일을 다운로드합니다.

1.2. Git 설치

• 다운로드한 설치 파일을 실행합니다.
• 설치 마법사의 지침에 따라 기본 설정을 유지하면서 설치를 완료합니다.

2. AWS CLI 설치 및 설정

AWS CLI는 AWS 서비스와 상호작용하기 위해 필요한 도구입니다.

2.1. AWS CLI 다운로드 및 설치

• AWS CLI 설치 페이지로 이동합니다.
• Windows 설치 방법에 따라 AWS CLI를 설치합니다.

2.2. AWS CLI 설정

• 명령 프롬프트 또는 PowerShell을 열고 다음 명령어를 실행하여 AWS CLI를 설정합니다:

aws configure

• AWS 액세스 키, 시크릿 액세스 키, 기본 리전 이름(ap-northeast-2 등), 출력 형식을 입력합니다.

3. Git 자격 증명 캐시 설정

AWS CodeCommit에 HTTPS를 통해 접근할 때 Git 자격 증명을 올바르게 설정해야 합니다.

3.1. Git 자격 증명 캐시 설정

• 다음 명령어를 실행하여 Git이 AWS CLI 자격 증명을 사용하도록 설정합니다:

git config --global credential.helper '!aws codecommit credential-helper $@'
git config --global credential.UseHttpPath true

4. 로컬 리포지토리 설정 및 원격 리포지토리 추가

로컬에 이미 소스가 있는 경우, 기존 리포지토리와 AWS CodeCommit을 연결할 수 있습니다.

4.1. 로컬 리포지토리 초기화

• Git 리포지토리 디렉토리로 이동합니다:
• 로컬 디렉토리가 Git 리포지토리가 아닌 경우, Git 리포지토리로 초기화합니다:

git init

4.2. 원격 리포지토리 추가

• AWS CodeCommit의 HTTPS URL을 사용하여 원격 리포지토리를 추가합니다:

git remote add origin https://git-codecommit.ap-northeast-2.amazonaws.com/v1/repos/test

5. 브랜치 생성 및 푸시

5.1. 브랜치 생성 및 커밋

• 새 브랜치를 생성하고 체크아웃합니다:
• 변경 사항을 커밋합니다:
• 원격 리포지토리에 브랜치를 푸시합니다:

git checkout -b dev
git add .
git commit -m "new branch dev"
git push -u origin dev

6. 오류 해결

6.1. 403 Forbidden 오류

• IAM 권한 확인: AWS IAM 사용자에게 AWSCodeCommitPowerUser 정책 또는 필요한 권한이 부여되어 있는지 확인합니다.
• AWS CLI 자격 증명 확인: aws configure 명령어로 자격 증명을 올바르게 설정했는지 확인합니다.
• 자격 증명 캐시 설정: 위의 credential.helper 명령어로 자격 증명 캐시가 올바르게 설정되었는지 확인합니다.

SSH 키를 사용하면 비밀번호 입력 없이 안전하게 서버에 접속할 수 있습니다. 이 글에서는 로컬 머신에서 SSH 키를 생성하고, 타겟 서버에 적용하여 패스워드 없이 로그인하는 방법을 단계별로 설명합니다.

1. 로컬 머신에서 SSH 키 생성하기

우선, 로컬 머신에서 SSH 키를 생성합니다. 이미 SSH 키가 생성되어 있다면 이 단계를 생략해도 됩니다.

SSH 키 생성 명령어:

ssh-keygen -t rsa -b 4096 -C "your_email@example.com"

위 명령을 실행하면 id_rsa (비밀 키)와 id_rsa.pub (공개 키) 파일이 생성됩니다. 기본적으로 ~/.ssh/ 디렉토리에 저장됩니다.

• id_rsa: 비밀 키 (Private Key)
• id_rsa.pub: 공개 키 (Public Key)

2. 타겟 서버에 공개 키 추가하기

SSH 키를 생성한 후, 타겟 서버에 공개 키를 추가해야 합니다. 이를 위해 두 가지 방법을 사용할 수 있습니다.

ssh-copy-id 명령어 사용하기

ssh-copy-id -i /root/.ssh/id_rsa.pub 사용자명@타겟서버주소

이 명령어는 자동으로 공개 키를 타겟 서버의 ~/.ssh/authorized_keys 파일에 추가합니다.

3. 패스워드 없는 접근 확인하기

타겟 서버에 공개 키를 성공적으로 추가한 후에는 SSH 비밀 키를 사용하여 패스워드 없이 타겟 서버에 접속할 수 있습니다.

접속 명령어:

ssh -i /root/.ssh/id_rsa 사용자명@타겟서버주소

이 명령어는 비밀 키 파일을 사용하여 타겟 서버에 접속합니다. 패스워드를 입력할 필요 없이 안전하게 서버에 접근할 수 있습니다.

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

Elastic Beanstalk 소개

Elastic Beanstalk은 AWS에서 제공하는 관리형 서비스로, 웹 애플리케이션과 서비스를 쉽게 배포하고 관리할 수 있게 해줍니다. 개발자는 인프라 관리에 신경 쓰지 않고 코드를 업로드하기만 하면, Elastic Beanstalk이 자동으로 인프라를 프로비저닝하고 애플리케이션을 배포해줍니다.

IAM 역할과 정책의 중요성

Elastic Beanstalk은 다양한 AWS 서비스와 상호작용하기 때문에, 필요한 권한을 관리하기 위해 IAM(Identity and Access Management) 역할과 정책이 중요합니다. 올바른 IAM 역할과 정책을 설정하면 애플리케이션이 안전하게 운영되며, 불필요한 권한으로 인한 보안 리스크를 줄일 수 있습니다.

1. Elastic Beanstalk을 위한 IAM 역할 및 정책 이해

IAM 역할(Role)과 정책(Policy) 개요

IAM 역할(Role)은 특정 AWS 리소스에 접근할 수 있는 권한을 가진 엔터티입니다. 사용자는 역할을 통해 AWS 서비스와 상호작용할 수 있으며, 역할에는 정책(Policy)이 연결되어 있어, 허용된 액션과 리소스를 정의합니다.

Elastic Beanstalk에서의 IAM 역할 사용 사례

Elastic Beanstalk에서 IAM 역할은 애플리케이션이 다른 AWS 서비스 (예: S3, DynamoDB, RDS)와 상호작용할 수 있도록 하는 중요한 구성 요소입니다. 예를 들어, 애플리케이션이 S3에서 파일을 읽거나 쓰기 위해서는 적절한 권한이 있는 IAM 역할이 필요합니다.

2. Elastic Beanstalk을 위한 IAM 역할 생성

필요한 권한 식별

Elastic Beanstalk에는 기본적으로 EC2 인스턴스, Auto Scaling, Load Balancer 등의 서비스에 대한 권한이 필요합니다. 하지만, 애플리케이션에 따라 추가적으로 S3, CloudWatch, RDS 등 다른 AWS 서비스에 접근해야 할 수도 있습니다.

IAM 역할 생성 단계별 가이드

• 서비스 정책 생성 : 아래 JSON을 복사하여 " AWSElasticBeanstalkService"  이름으로 IAM 정책을 생성합니다. 

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowCloudformationOperationsOnElasticBeanstalkStacks",
            "Effect": "Allow",
            "Action": [
                "cloudformation:*"
            ],
            "Resource": [
                "arn:aws:cloudformation:*:*:stack/awseb-*",
                "arn:aws:cloudformation:*:*:stack/eb-*"
            ]
        },
        {
            "Sid": "AllowDeleteCloudwatchLogGroups",
            "Effect": "Allow",
            "Action": [
                "logs:DeleteLogGroup"
            ],
            "Resource": [
                "arn:aws:logs:*:*:log-group:/aws/elasticbeanstalk*"
            ]
        },
        {
            "Sid": "AllowECSTagResource",
            "Effect": "Allow",
            "Action": [
                "ecs:TagResource"
            ],
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "ecs:CreateAction": [
                        "CreateCluster",
                        "RegisterTaskDefinition"
                    ]
                }
            }
        },
        {
            "Sid": "AllowS3OperationsOnElasticBeanstalkBuckets",
            "Effect": "Allow",
            "Action": [
                "s3:*"
            ],
            "Resource": [
                "arn:aws:s3:::elasticbeanstalk-*",
                "arn:aws:s3:::elasticbeanstalk-*/*"
            ]
        },
        {
            "Sid": "AllowLaunchTemplateRunInstances",
            "Effect": "Allow",
            "Action": "ec2:RunInstances",
            "Resource": "*",
            "Condition": {
                "ArnLike": {
                    "ec2:LaunchTemplate": "arn:aws:ec2:*:*:launch-template/*"
                }
            }
        },
        {
            "Sid": "AllowELBAddTags",
            "Effect": "Allow",
            "Action": [
                "elasticloadbalancing:AddTags"
            ],
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "elasticloadbalancing:CreateAction": [
                        "CreateLoadBalancer"
                    ]
                }
            }
        },
        {
            "Sid": "AllowOperations",
            "Effect": "Allow",
            "Action": [
                "autoscaling:AttachInstances",
                "autoscaling:CreateAutoScalingGroup",
                "autoscaling:CreateLaunchConfiguration",
                "autoscaling:CreateOrUpdateTags",
                "autoscaling:DeleteLaunchConfiguration",
                "autoscaling:DeleteAutoScalingGroup",
                "autoscaling:DeleteScheduledAction",
                "autoscaling:DescribeAccountLimits",
                "autoscaling:DescribeAutoScalingGroups",
                "autoscaling:DescribeAutoScalingInstances",
                "autoscaling:DescribeLaunchConfigurations",
                "autoscaling:DescribeLoadBalancers",
                "autoscaling:DescribeNotificationConfigurations",
                "autoscaling:DescribeScalingActivities",
                "autoscaling:DescribeScheduledActions",
                "autoscaling:DetachInstances",
                "autoscaling:DeletePolicy",
                "autoscaling:PutScalingPolicy",
                "autoscaling:PutScheduledUpdateGroupAction",
                "autoscaling:PutNotificationConfiguration",
                "autoscaling:ResumeProcesses",
                "autoscaling:SetDesiredCapacity",
                "autoscaling:SuspendProcesses",
                "autoscaling:TerminateInstanceInAutoScalingGroup",
                "autoscaling:UpdateAutoScalingGroup",
                "cloudwatch:PutMetricAlarm",
                "ec2:AssociateAddress",
                "ec2:AllocateAddress",
                "ec2:AuthorizeSecurityGroupEgress",
                "ec2:AuthorizeSecurityGroupIngress",
                "ec2:CreateLaunchTemplate",
                "ec2:CreateLaunchTemplateVersion",
                "ec2:DescribeLaunchTemplates",
                "ec2:DescribeLaunchTemplateVersions",
                "ec2:DeleteLaunchTemplate",
                "ec2:DeleteLaunchTemplateVersions",
                "ec2:CreateSecurityGroup",
                "ec2:DeleteSecurityGroup",
                "ec2:DescribeAccountAttributes",
                "ec2:DescribeAddresses",
                "ec2:DescribeImages",
                "ec2:DescribeInstances",
                "ec2:DescribeKeyPairs",
                "ec2:DescribeSecurityGroups",
                "ec2:DescribeSnapshots",
                "ec2:DescribeSubnets",
                "ec2:DescribeVpcs",
                "ec2:DescribeInstanceAttribute",
                "ec2:DescribeSpotInstanceRequests",
                "ec2:DescribeVpcClassicLink",
                "ec2:DisassociateAddress",
                "ec2:ReleaseAddress",
                "ec2:RevokeSecurityGroupEgress",
                "ec2:RevokeSecurityGroupIngress",
                "ec2:TerminateInstances",
                "ecs:CreateCluster",
                "ecs:DeleteCluster",
                "ecs:DescribeClusters",
                "ecs:RegisterTaskDefinition",
                "elasticbeanstalk:*",
                "elasticloadbalancing:ApplySecurityGroupsToLoadBalancer",
                "elasticloadbalancing:ConfigureHealthCheck",
                "elasticloadbalancing:CreateLoadBalancer",
                "elasticloadbalancing:DeleteLoadBalancer",
                "elasticloadbalancing:DeregisterInstancesFromLoadBalancer",
                "elasticloadbalancing:DescribeInstanceHealth",
                "elasticloadbalancing:DescribeLoadBalancers",
                "elasticloadbalancing:DescribeTargetHealth",
                "elasticloadbalancing:RegisterInstancesWithLoadBalancer",
                "elasticloadbalancing:DescribeTargetGroups",
                "elasticloadbalancing:RegisterTargets",
                "elasticloadbalancing:DeregisterTargets",
                "iam:ListRoles",
                "iam:PassRole",
                "logs:CreateLogGroup",
                "logs:PutRetentionPolicy",
                "logs:DescribeLogGroups",
                "rds:DescribeDBEngineVersions",
                "rds:DescribeDBInstances",
                "rds:DescribeOrderableDBInstanceOptions",
                "s3:GetObject",
                "s3:GetObjectAcl",
                "s3:ListBucket",
                "sns:CreateTopic",
                "sns:GetTopicAttributes",
                "sns:ListSubscriptionsByTopic",
                "sns:Subscribe",
                "sns:SetTopicAttributes",
                "sqs:GetQueueAttributes",
                "sqs:GetQueueUrl",
                "codebuild:CreateProject",
                "codebuild:DeleteProject",
                "codebuild:BatchGetBuilds",
                "codebuild:StartBuild"
            ],
            "Resource": [
                "*"
            ]
        }
    ]
}

AWS Elastic Beanstalk과 관련된 리소스에 대해 다양한 권한을 부여하는 정책입니다. 각 섹션(Statement)별로 설명드리겠습니다.

1. AllowCloudformationOperationsOnElasticBeanstalkStacks

• 설명: 이 섹션은 CloudFormation 스택에서 모든 작업(cloudformation:*)을 허용합니다. 하지만, 해당 스택의 이름이 awseb-* 또는 eb-*로 시작하는 경우에만 허용됩니다.
• 주요 권한: CloudFormation 관련 작업 전체(cloudformation:*).
• 적용 대상 리소스: arn:aws:cloudformation:*:*:stack/awseb-*, arn:aws:cloudformation:*:*:stack/eb-*.

2. AllowDeleteCloudwatchLogGroups

• 설명: 이 섹션은 Elastic Beanstalk과 관련된 CloudWatch 로그 그룹을 삭제할 수 있는 권한을 부여합니다.
• 주요 권한: CloudWatch 로그 그룹 삭제(logs:DeleteLogGroup).
• 적용 대상 리소스: arn:aws:logs:*:*:log-group:/aws/elasticbeanstalk*.

3. AllowECSTagResource

• 설명: 이 섹션은 ECS 리소스에 태그를 붙일 수 있는 권한을 부여합니다. 단, 이 권한은 CreateCluster나 RegisterTaskDefinition과 같은 작업이 수행될 때만 유효합니다.
• 주요 권한: ECS 리소스에 태그 부착(ecs:TagResource).
• 적용 대상 리소스: 모든 리소스(*).
• 조건: ecs:CreateAction이 CreateCluster 또는 RegisterTaskDefinition일 때.

4. AllowS3OperationsOnElasticBeanstalkBuckets

• 설명: Elastic Beanstalk과 관련된 S3 버킷에 대해 모든 S3 작업을 허용합니다.
• 주요 권한: S3 관련 작업 전체(s3:*).
• 적용 대상 리소스: arn:aws:s3:::elasticbeanstalk-*, arn:aws:s3:::elasticbeanstalk-*/*.

5. AllowLaunchTemplateRunInstances

• 설명: 이 섹션은 EC2 인스턴스를 실행(RunInstances)할 수 있는 권한을 부여합니다. 단, 실행되는 인스턴스는 특정 조건에 따라야 합니다.
• 주요 권한: EC2 인스턴스 실행(ec2:RunInstances).
• 적용 대상 리소스: 모든 리소스(*).
• 조건: ec2:LaunchTemplate ARN이 arn:aws:ec2:*:*:launch-template/*와 일치해야 합니다.

6. AllowELBAddTags

• 설명: Elastic Load Balancer(ELB)에 태그를 추가할 수 있는 권한을 부여합니다. 단, 이 권한은 로드 밸런서가 생성될 때만 유효합니다.
• 주요 권한: ELB 태그 추가(elasticloadbalancing:AddTags).
• 적용 대상 리소스: 모든 리소스(*).
• 조건: elasticloadbalancing:CreateAction이 CreateLoadBalancer일 때.

7. AllowOperations

• 설명: 이 섹션은 Elastic Beanstalk 환경에서 애플리케이션을 운영하는 데 필요한 다양한 AWS 서비스에 대한 권한을 광범위하게 허용합니다.
• 주요 권한: Auto Scaling, EC2, ECS, Elastic Beanstalk, ELB, IAM, CloudWatch, RDS, S3, SNS, SQS, CodeBuild 등 여러 서비스에 대한 권한.
• 적용 대상 리소스: 모든 리소스(*).

이 정책은 Elastic Beanstalk 환경에서의 인프라와 애플리케이션 관리를 위한 매우 광범위한 권한을 포함하고 있으며, Elastic Beanstalk에 필요한 거의 모든 작업을 수행할 수 있도록 설계되었습니다. 각 권한은 특정 리소스에 제한을 두거나 특정 조건 하에서만 허용되도록 구성되어 있어, 보안성을 유지하면서도 필요한 작업을 수행할 수 있게 합니다.

• 서비스 역할 생성 : "aws-elasticbeanstalk-service-role"  이름으로 elastic beanstalk 역할 생성

• AWSElasticBeanstalkService 정책에 aws-elasticbeanstalk-service-role 역할 연결

• aws-elasticbeanstalk-ec2-role 역할 생성, 아래 정책을 추가합니다.
• AmazonEC2ContainerRegistryReadOnly,AWSElasticBeanstalkWebTier,
• AWSElasticBeanstalkWorkerTier
• AWSElasticBeanstalkMulticontainerDocker,

• 생성한 두 역할을 할당 합니다.