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,

 

 

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

 

1. 환경 설명

1.1. 프로젝트 개요

PHP 5.6 버전을 사용하는 웹 애플리케이션의 CI/CD(지속적 통합 및 지속적 배포) 파이프라인을 구축합니다. 이 파이프라인은 자동화된 빌드, 테스트, 배포 과정을 통해 효율적인 개발과 배포를 지원합니다.

1.2. 사용 기술

  • PHP 5.6: 웹 애플리케이션을 위한 서버 사이드 스크립팅 언어
  • Linux 2: AWS EC2 인스턴스에서 사용할 운영 체제
  • Git: 소스 코드 버전 관리
  • Docker: 애플리케이션 컨테이너화
  • Amazon ECR (Elastic Container Registry): Docker 이미지를 저장하는 컨테이너 레지스트리
  • Amazon Elastic Beanstalk (EB): 애플리케이션 배포 및 관리 플랫폼
  • AWS CodeCommit: Git 기반의 소스 코드 리포지토리
  • AWS CodeBuild: 소스 코드의 빌드 및 테스트 자동화
  • AWS CodePipeline: CI/CD 파이프라인 구성 및 관리

 

2. 환경 설정

2.1. Git 설정

  • CodeRepository를 저장소로 사용하였고, git 설정 가이드가 필요하다면 아래 링크를 이용하시기 바랍니다.
  • https://yes5.tistory.com/42
 

git 설치와 AWS code repository 생성

Git 설치Git 설치는 운영 체제에 따라 다릅니다. 아래에 Windows, macOS, 그리고 Linux에 대한 설치 방법을 설명합니다.WindowsGit 공식 사이트에 접속하여 최신 Git 설치 파일을 다운로드합니다.다운로드한

yes5.tistory.com

 

 

2.2. Docker 설정

  • Docker 설치 및 설정: PHP 5.6을 위한 Docker 이미지를 설정합니다.
  • 아래  코드를 Dockerfile로 생성합니다.
  • 파일 생성 후 git push 하여 Dockerfile을 Git repository의 root 디렉토리에 push합니다.
# Step 1: Base Image from AWS ECR Public Gallery
FROM public.ecr.aws/amazonlinux/amazonlinux:2

# Step 2: Install EPEL repository and Remi repository
RUN yum install -y amazon-linux-extras \
    && amazon-linux-extras install epel -y \
    && yum install -y yum-utils \
    && yum install -y https://rpms.remirepo.net/enterprise/remi-release-7.rpm \
    && yum install -y sed

# Step 3: Enable PHP 5.6 repository
RUN yum-config-manager --enable remi-php56

# Step 4: Install Apache and PHP 5.6 with required extensions
RUN yum install -y \
    httpd \
    php \
    php-cli \
    php-common \
    php-devel \
    php-mbstring \
    php-xml \
    php-mysqlnd

# Step 5: Update all packages to apply latest security patches
RUN yum update -y

# Step 6: Clean up cached files to reduce image size
RUN yum clean all \
    && rm -rf /var/cache/yum

# Step 7: Use sed to modify php.ini configuration
# Note: php.ini should exist in the container by default
RUN sed -i 's/short_open_tag = Off/short_open_tag = On/' /etc/php.ini

# Step 8: Copy application source code to the container
COPY . /var/www/html/

# Step 9: Expose the necessary port (default: 80 for Apache)
EXPOSE 80

# Step 10: Start the Apache server
CMD ["/usr/sbin/httpd", "-D", "FOREGROUND"]

 

  • Docker 빌드 및 로그 확인 : 빌드 후 로그 확인과 브라우저에서 동작을 확인합니다.
#빌드 및 실행(-v /var/www:/var/www: 호스트의 /var/www 디렉토리를 컨테이너의 /var/www 디렉토리에 마운트)
docker build -t my-php-app .
docker run -d -p 80:80 --name my-php-app -v /var/www:/var/www my-php-app

#컨테이너 로그 확인
docker logs my-php-app

 

 

3. Docker 이미지 ECR에 푸시하기

이제 로컬에서 빌드한 Docker 이미지를 Amazon ECR로 푸시하는 방법을 알아보겠습니다.

3.1 ECR 로그인

먼저, AWS CLI를 사용하여 Docker를 ECR에 로그인시켜야 합니다. 아래 명령어를 실행하면 됩니다

aws ecr get-login-password --region ap-northeast-2 | docker login --username AWS --password-stdin <ECR URI 주소>

 

이 명령어는 ECR에 대한 Docker 인증 정보를 구성합니다.

 

3.2 이미지 태그 지정

이미 로컬에서 빌드된 my-amazonlinux-php-app 이미지를 ECR에 맞게 태그를 지정합니다

docker tag my-amazonlinux-php-app:latest <ECR URI 주소>/my-php-app:latest

 

3.3 Docker 이미지 푸시

이제 이미지를 ECR 리포지토리로 푸시합니다

docker push <ECR URI 주소>/my-php-app:latest

 

 

4. ECR에서 이미지 풀(pull) 받아 Docker 컨테이너 실행하기

푸시된 이미지를 다른 서버나 로컬에서 사용할 수 있도록 ECR에서 풀(pull) 받아 Docker 컨테이너로 실행하는 방법을 설명하겠습니다.

 

이미 실행중인 컨테이너가 있다면 종료 후 삭제합니다.

docker ps
docker stop my-php-app
docker rm my-php-app

[실행중인 컨테이너 삭제]
docker stop $(docker ps -q)
docker rm $(docker ps -aq)

 

4.1 ECR 로그인

다른 서버나 로컬 환경에서 ECR에서 이미지를 풀(pull) 받기 전에, 먼저 ECR에 로그인해야 합니다

aws ecr get-login-password --region ap-northeast-2 | docker login --username AWS --password-stdin <ECR URI 주소>

 

4.2 ECR에서 이미지 풀(pull)

ECR에서 이미지를 풀(pull) 받습니다

docker pull <ECR URI 주소>/my-php-app:latest

 

4.3 Docker 컨테이너 실행

풀(pull) 받은 이미지를 사용하여 Docker 컨테이너를 실행합니다

docker run -d -p 80:80 --name my-php-app -v /var/www:/var/www <ECR URI 주소>/my-php-app:latest

 

 

5. AWS CodeBuild 설정 및 사용

AWS CodeBuild는 소스 코드를 빌드하고, 자동으로 테스트와 패키징을 진행하는 빌드 서비스입니다. 이 단계에서는 CodeBuild를 생성하고 설정하여, 애플리케이션 빌드 및 배포 파이프라인을 완성하겠습니다.

 

5.1 CodeBuild 프로젝트 생성

  1. AWS 콘솔에 로그인한 후, CodeBuild 서비스로 이동합니다.
  2. 프로젝트 생성 버튼을 클릭합니다.
  3. 프로젝트 이름을 설정합니다. 예를 들어, my-php-app-build와 같이 명명할 수 있습니다.

 

5.2 환경 설정

  1. 소스 공급자에서 AWS CodeCommit을 선택하고, 앞서 만든 리포지토리(2번 항목 Git 생성)와 브랜치(master)를 선택합니다.
  2. 빌드 환경에서 환경 이미지를 설정합니다.
    • 운영체제: Amazon Linux를 선택합니다.
    • 런타임: Standard를 선택합니다.
    • 이미지: aws/codebuild/amazonlinux2-x86_64-standard:5.0 등 최신 버전의 이미지를 선택합니다.
    • 빌드 사양: 빌드 명령 삽입을 선택합니다. 아래 buildspec.yml 내용을 입력합니다.
version: 0.2

env:
  variables:
    REPOSITORY_URI: <생성된 ECR의 URI주소로 변경>
    IMAGE_TAG: latest
    AWS_REGION: ap-northeast-2
    IMAGE_NAME: my-php-app

phases:
  install:
    commands:
      - echo Installing dependencies...
      # Docker는 기본적으로 설치되어 있어야 하므로, 필요 시 추가 작업을 여기에 명시할 수 있습니다.
      # 예: sudo yum install -y docker

  pre_build:
    commands:
      - echo Logging in to Amazon ECR...
      - aws ecr get-login-password --region $AWS_REGION | docker login --username AWS --password-stdin $REPOSITORY_URI

  build:
    commands:
      - echo Building the Docker image...
      - docker build -t $IMAGE_NAME .
      - docker tag $IMAGE_NAME:$IMAGE_TAG $REPOSITORY_URI:$IMAGE_TAG

  post_build:
    commands:
      - echo Pushing the Docker image to ECR...
      - docker push $REPOSITORY_URI:$IMAGE_TAG

artifacts:
  files:
    - '**/*'

 

 

5.3 artifact  설정 

  1. 유형으로 S3를 선택합니다. 
  2. 사용할 서비스명으로 S3를 생성합니다.
  3. 아티팩트 패키징에서 Zip 설정합니다.

 

 5.3 build 실행 

  1. 빌드 시작으로 오류가 없는지 Test합니다. 
  2. 이상이 없다면 빌드 상태가 성공함으로 표시됩니다.

 

 

 

6. Elastic Beanstalk(EB)에 애플리케이션 배포하기

AWS Elastic Beanstalk는 애플리케이션을 쉽고 빠르게 배포할 수 있는 관리형 서비스로, 인프라 프로비저닝, 로드 밸런싱, 오토스케일링 등의 기능을 자동으로 제공합니다. 이 과정에서는 ECR에 저장된 Docker 이미지를 사용해 Elastic Beanstalk 환경에 애플리케이션을 배포하는 방법을 설명하겠습니다.

 

6.1 Elastic Beanstalk 환경 생성

  1. AWS 콘솔에 로그인한 후, Elastic Beanstalk 서비스로 이동합니다.
  2. 환경 생성 단계로 이동하여 아래와 같이 설정합니다.
    • 어플리케이션 이름: 적절한 이름을 지정합니다. 예를 들어, my-php-app와 같이 설정할 수 있습니다.
    • 환경 이름: 예를 들어, my-php-app-prod와 같이 설정할 수 있습니다.
    • 환경 정보: 여기서 환경 유형으로 웹 서버 환경을 선택합니다.

 

6.2 플랫폼 설정

Elastic Beanstalk는 Docker 컨테이너 이미지를 통해 애플리케이션을 실행할 수 있습니다. 

  1. Docker 플랫폼을 선택:
    • 플랫폼 브랜치: Docker running on 64bit Amazon Linux2
    • 플랫폼 버전:  4.0.1
  2.  애플리케이션 코드 와 서전 설정은 기본 설정으로 선택합니다. (고가용성, LB 배포 설정 등은 다루지 않습니다.)

 

 

6.3 서비스 액세스 설정

 

https://yes5.tistory.com/55

 

Elastic Beanstalk을 위한 IAM 정책 및 역할 생성

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

yes5.tistory.com

 

 

6.4 기타 설정

  1. 네트워크 VPC는 어플리케이션 서비스에 맞게 설정합니다.
  2. 데이터베이스는 이 포스팅에선 EC2로 사용하고 있기 때문에 설정하지 않습니다.
  3. Autoscale, 모니터링, 업데이트 등 기본 설정.
  4. Nginx Proxy도 설정하지 않습니다. 

 

 

7. CodePipeline으로 CI/CD 파이프라인 구성하기

AWS CodePipeline은 CI/CD 파이프라인을 자동으로 구성하고 관리하는 서비스입니다. 이 서비스를 통해 코드 변경이 발생할 때마다 소스 코드가 자동으로 빌드되고, 테스트된 후 배포까지 진행될 수 있습니다.

7.1 CodePipeline 생성

  1. AWS 콘솔에 로그인한 후, CodePipeline 서비스로 이동합니다.
  2. 파이프라인 생성 버튼을 클릭합니다.
    • 파이프라인 이름: 적절한 이름을 설정합니다. 예를 들어, my-php-app-pipeline과 같이 설정할 수 있습니다.
    • 새 서비스 역할 생성을 선택하여 CodePipeline이 리소스에 접근할 수 있도록 권한을 설정합니다.
    • 고급 설정: code build 단계에서 생성한 S3 버킷을 지정합니다.

 

7.2 소스(Stage 1) 설정

소스는 애플리케이션 코드가 저장된 곳에서 가져옵니다. 우리는 AWS CodeCommit을 사용하고 있으므로 이를 연결합니다.

  1. 소스 공급자: AWS CodeCommit을 선택합니다.
  2. 리포지토리 이름: 애플리케이션의 리포지토리를 선택합니다. 예: php56-app-repo
  3. 브랜치: 트리거할 브랜치를 선택합니다. 예: main 또는 master
  4. CodePipeline은 이 브랜치에 코드가 푸시될 때마다 자동으로 파이프라인을 실행합니다.

 

 

7.3 빌드(Stage 2) 설정

빌드 단계에서는 AWS CodeBuild를 사용하여 Docker 이미지를 빌드하고 ECR에 푸시하는 작업을 자동화합니다.

  1. 빌드 공급자: AWS CodeBuild를 선택합니다.
  2. 프로젝트 이름: 이전 단계에서 설정한 CodeBuild 프로젝트를 선택합니다. 예: my-php-app-build
  3. CodeBuild가 소스 코드를 가져와 Docker 이미지를 빌드하고, ECR로 푸시하는 작업을 수행합니다.

 

7.4 배포(Stage 3) 설정

배포 단계에서는 Amazon Elastic Beanstalk를 사용하여 애플리케이션을 자동으로 배포합니다.

  1. 배포 공급자: Amazon Elastic Beanstalk를 선택합니다.
  2. 애플리케이션 이름: Elastic Beanstalk에서 설정한 애플리케이션을 선택합니다. 예: my-php-app
  3. 환경 이름: 이전 단계에서 생성한 환경을 선택합니다. 예: my-php-app-prod

 

7.5 파이프라인 실행

설정이 완료되면 파이프라인 생성 버튼을 클릭합니다. 생성된 파이프라인은 지정된 소스 브랜치에 새로운 코드가 푸시되면 자동으로 실행됩니다.

  • 소스 변경: 개발자가 Git 리포지토리에 코드를 푸시합니다.
  • 빌드 단계: CodeBuild가 트리거되어 Docker 이미지를 빌드하고 ECR로 푸시합니다.
  • 배포 단계: 빌드된 이미지를 Elastic Beanstalk가 받아서 애플리케이션 환경에 배포합니다.

7.6 파이프라인 모니터링 및 관리

파이프라인이 실행될 때마다 AWS 콘솔에서 파이프라인의 상태를 실시간으로 모니터링할 수 있습니다.

  • 실행 상태 확인: 각 단계가 정상적으로 완료되었는지 확인할 수 있습니다. 빌드 실패나 배포 실패 등의 오류가 발생하면 자세한 로그를 통해 문제를 분석할 수 있습니다.
  • 재실행 및 수정: 오류가 발생한 경우, 파이프라인을 수정하거나 개별 단계만 다시 실행할 수 있습니다.

Gabia에서 도메인을 구매하는 방법은 간단합니다.

  1. Gabia 홈페이지 접속 후, 원하는 도메인 이름을 검색합니다.
  2. 사용 가능한 도메인을 선택하고 장바구니에 담기 버튼을 클릭합니다.
  3. 회원 가입 또는 로그인 후, 결제를 완료하면 도메인 구매가 완료됩니다.
  4. 구매한 도메인은 내 도메인 관리에서 확인할 수 있으며, 도메인 설정을 통해 네임서버 변경, DNS 설정 등을 할 수 있습니다.

 

 

SSL 인증서를 발급받으려면 AWS Certificate Manager(ACM)를 사용하여 무료로 SSL 인증서를 발급받을 수 있습니다. 다음은 AWS ACM을 통해 SSL 인증서를 발급받는 절차입니다.

1. AWS Certificate Manager(ACM)에서 SSL 인증서 요청

  1. AWS Management Console에 로그인한 후, 상단 검색창에 Certificate Manager를 입력하고 **ACM(AWS Certificate Manager)**로 이동합니다.
  2. 좌측 메뉴에서 Provision certificates를 클릭한 후 Request a certificate 버튼을 누릅니다.
  3. Request a public certificate를 선택하고 Next를 클릭합니다.

2. 도메인 이름 입력

  1. Fully qualified domain name (FQDN) 입력란에 SSL 인증서를 적용할 도메인 이름을 입력합니다.
    • 예를 들어, 도메인이 example.com인 경우, 도메인 이름을 example.com 또는 *.example.com으로 입력합니다.
    • *.example.com으로 입력하면 와일드카드 인증서가 발급되며, 모든 하위 도메인(www.example.com, blog.example.com 등)을 인증할 수 있습니다.

 

3. 검증 방법 선택

AWS는 도메인 소유권을 검증하기 위해 두 가지 방법을 제공합니다:

  • DNS 검증: AWS Route 53을 사용하거나 DNS 제공자의 레코드에 TXT 레코드를 추가하여 도메인 소유권을 증명합니다. Route 53을 사용할 경우 자동으로 설정할 수 있어 더 간편합니다.
  • Email 검증: 도메인에 연결된 이메일로 확인 이메일을 보내서 소유권을 확인합니다.

DNS 검증을 선택:

  • DNS validation을 선택하고 Next를 클릭합니다.
  • Route 53을 사용 중이라면 AWS가 자동으로 필요한 DNS 레코드를 생성해줍니다.
  • ACM에서 Route 53에서 레코드를 생성을 실행합니다.

ACM에서 확인
Route 53에서 레코드 생성

 

 

4. AWS Route 53에서 호스팅 영역(Hosted Zone) 생성

  1. ACM에서 Route 53에서 레코드를 생성 시 CNAME 유형으로 인증서 설정 레코드가 생성됩니다.
  2. 호스팅 영역이 생성되면, AWS가 네임서버(NS) 레코드 4개를 자동으로 생성해줍니다. 이 네임서버 정보를 복사해 둡니다.

 

5. Gabia에서 네임서버 설정 변경

  1. Gabia 홈페이지에 로그인합니다.
  2. 상단 메뉴에서 도메인 관리로 이동한 후, 내 도메인 관리를 클릭합니다.
  3. 사용 중인 도메인 목록에서 AWS에 연결할 도메인을 선택합니다.
  4. 도메인 상세 설정에서 네임서버 변경 항목을 찾습니다.
  5. Gabia에서 기본으로 제공하는 네임서버 대신, AWS Route 53에서 생성한 네임서버 4개를 입력합니다.
    • AWS Route 53에서 제공한 NS 레코드를 Gabia의 네임서버 설정에 복사하여 붙여넣기 합니다.
    • 이 때 AWS에서 제공하는 NS에서 마지막 .은 제외하고 복 사하여 붙여넣기 합니다 .
  6. 변경 내용을 저장합니다. 네임서버 변경은 최대 24~48시간 정도 소요될 수 있습니다.

 

 

6. Route 53에서 레코드 추가

  1. 다시 AWS Route 53 콘솔로 이동하여, 방금 생성한 Hosted Zone을 클릭합니다.
  2. 도메인에 필요한 레코드를 추가합니다. 일반적으로 다음과 같은 레코드를 설정할 수 있습니다.
    • A (Alias) 레코드: ALB(Elastic Load Balancer)와 연결
    • CNAME 레코드: 서브도메인 연결

 

'Security > Network' 카테고리의 다른 글

AWS site to site VPN - UTM(TrusGuard)  (0) 2024.07.17

* 불가피하게 Amazon linux2에서 실행해야 할 상황에서의 대처입니다. 가능하면 ubuntu 사용을 추천드립니다.

 

Amazon linux2에서 node18버전 이상 yum 설치 시 GLIBC 버전 호환 문제로 아래와 같은 에러가 발생합니다.

Error: Package: 2:nodejs-18.20.4-1nodesource.x86_64 (nodesource-nodejs)
           Requires: libc.so.6(GLIBC_2.28)(64bit)
Error: Package: 2:nodejs-18.20.4-1nodesource.x86_64 (nodesource-nodejs)
           Requires: libm.so.6(GLIBC_2.27)(64bit)
Error: Package: 2:nodejs-18.20.4-1nodesource.x86_64 (nodesource-nodejs)
           Requires: glibc >= 2.28

 

Node.js 18.x 설치 방법 (바이너리 다운로드 방식)

이 가이드는 Node.js 18.x을 바이너리 파일을 사용하여 설치하는 방법을 설명합니다. 이 방법은 GLIBC 버전 문제를 피하고 직접 바이너리를 다운로드하여 설치할 수 있습니다. 이 예제에서는 Node.js 18.17.1 버전을 사용합니다.

1. Node.js 바이너리 다운로드

Node.js 18.x 바이너리를 다운로드합니다. 아래 명령어를 사용합니다:

wget -nv https://d3rnber7ry90et.cloudfront.net/linux-x86_64/node-v18.17.1.tar.gz

2. Node.js 바이너리 압축 해제 및 이동

다운로드한 바이너리 파일을 압축 해제한 후, /usr/local/lib/node 디렉토리에 이동합니다:

mkdir /usr/local/lib/node

tar -xf node-v18.17.1.tar.gz

mv node-v18.17.1 /usr/local/lib/node/nodejs

3. 환경 변수 설정

Node.js를 사용할 수 있도록 환경 변수를 설정합니다. NVM이 이미 설치되어 있는 경우, NVM의 환경 설정을 비우고 Node.js의 경로를 추가합니다:

echo "export NVM_DIR=''" >> /home/ec2-user/.bashrc

echo "export NODEJS_HOME=/usr/local/lib/node/nodejs" >> /home/ec2-user/.bashrc

echo "export PATH=\$NODEJS_HOME/bin:\$PATH" >> /home/ec2-user/.bashrc

4. 환경 변수 적용

변경된 환경 변수를 적용하기 위해 .bashrc 파일을 다시 로드합니다:

. /home/ec2-user/.bashrc

5. Node.js 설치 확인

Node.js가 제대로 설치되었는지 확인합니다. 아래 명령어를 실행하여 현재 설치된 Node.js 버전을 확인합니다:

node -e "console.log('Running Node.js ' + process.version)"

node -v

'Dev > Node.js' 카테고리의 다른 글

node.js express docker실행  (0) 2024.08.02
Node.js Express 실행 확인 index.html 포함  (1) 2024.07.30

 

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

다음 절차로 진행하세요:

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

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

git pull origin main --rebase



2. 다시 Push

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

git push origin main

 

 

 

AWS Access Key ID 생성 방법

  • AWS Management Console 로그인
  • IAM 콘솔로 이동
    • 콘솔 상단의 검색창에 IAM을 입력하고, IAM (Identity and Access Management)을 선택하여 IAM 콘솔로 이동합니다.
  • 사용자(User) 선택
    • IAM 대시보드에서 왼쪽 메뉴에서 Users를 클릭합니다.
    • Access Key를 생성할 사용자를 선택합니다. (만약 사용자가 없다면, 새 사용자를 생성해야 합니다.)

 

 

 

  • 사용자(User) 생성
    • Provide user access to the AWS Management Console의 경우 Console 로그인이 필요할 경우만 체크 합니다.
    • 현재 단계에선 group, permission, policy등 설정하지 않고 Next 후 create user 합니다.

 

 

  • 사용자 세부 정보에서 ‘보안 자격 증명’으로 이동
    • 선택한 사용자의 이름을 클릭하여 사용자의 세부 정보를 엽니다.
    • ‘Security credentials’ 탭을 클릭합니다.
  • Access Keys (Access Key ID 및 Secret Access Key) 생성
    • ‘Access keys’ 섹션에서 Create access key 버튼을 클릭합니다.
    • 팝업창이 나타나면, Create access key 버튼을 클릭하여 새 Access Key ID와 Secret Access Key를 생성합니다.

  • Access Keys (Access Key ID 및 Secret Access Key) 생성
    • Command Line Interface를 선택 후 생성합니다.

 

  •  Access Key ID와 Secret Access Key 저장
    • 생성된 Access Key ID와 Secret Access Key를 즉시 안전한 장소에 저장합니다. Secret Access Key는 한 번만 표시되므로, 이후에 복구할 수 없습니다.

 

1. Windows

AWS CLI 설치

  1. 설치 파일 다운로드:
  2. 설치:
    • 다운로드한 .msi 파일을 실행하여 설치 마법사의 지침을 따릅니다.
  3. 설치 확인:
    • 명령 프롬프트 또는 PowerShell을 열고 다음 명령어를 입력하여 설치가 성공적으로 되었는지 확인합니다:
aws --version

 

AWS CLI 설정

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


AWS Access Key ID: AWS Management Console에서 생성한 액세스 키 ID를 입력합니다.
AWS Secret Access Key: Access Key ID에 대한 비밀 액세스 키를 입력합니다.
Default region name: ap-northeast-2 리전을 입력합니다.
Default output format: JSON을 사용합니다.

 

 

 

2. macOS

AWS CLI 설치

Homebrew 사용 (권장):

  • Homebrew가 설치되어 있다면 다음 명령어를 사용하여 AWS CLI를 설치합니다:
brew install awscli

 

설치 확인:

  • 터미널을 열고 다음 명령어를 입력하여 설치가 성공적으로 되었는지 확인합니다:
aws --version

 

AWS CLI 설정

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


AWS Access Key ID: AWS Management Console에서 생성한 액세스 키 ID를 입력합니다.
AWS Secret Access Key: Access Key ID에 대한 비밀 액세스 키를 입력합니다.
Default region name: ap-northeast-2 리전을 입력합니다.
Default output format: JSON을 사용합니다.

 

 

3. Linux

AWS CLI 설치

  • 대부분의 리눅스 배포판에서는 패키지 관리자를 통해 AWS CLI를 설치할 수 있습니다.
  • Ubuntu에서는 다음 명령어를 사용합니다:
sudo apt update
sudo apt install awscli

 

  • CentOS에서는:
sudo yum install awscli

 

설치 확인:

  • 터미널을 열고 다음 명령어를 입력하여 설치가 성공적으로 되었는지 확인합니다:
aws --version

 

AWS CLI 설정

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


AWS Access Key ID: AWS Management Console에서 생성한 액세스 키 ID를 입력합니다.
AWS Secret Access Key: Access Key ID에 대한 비밀 액세스 키를 입력합니다.
Default region name: ap-northeast-2 리전을 입력합니다.
Default output format: JSON을 사용합니다.

 

Node.js 프로젝트 준비

먼저, Node.js 프로젝트를 준비해야 합니다. 프로젝트 루트 디렉토리에 package.json 파일이 있어야 합니다.

 

Node.js Test 코드가 없다면 아래 링크를 통해 간단하게 작성합니다.

https://yes5.tistory.com/45

 

Node.js Express 실행 확인 index.html 포함

Node.js 설치먼저, Node.js를 설치해야 합니다.Node.js 다운로드:Node.js 공식 웹사이트로 이동합니다.LTS (Long Term Support) 버전을 다운로드합니다. 이는 안정적이고 장기적으로 지원되는 버전입니다.Node.js

yes5.tistory.com

 

docker 설치

https://yes5.tistory.com/46

 

Docker 설치 및 설정 deploying WSL2 distributionsensuring main distro is deployed error 해결

1. Docker 설치Docker는 대부분의 운영 체제에서 설치할 수 있습니다. 아래는 주요 운영 체제별 설치 방법입니다.WindowsDocker Desktop for Windows를 다운로드하고 설치합니다.설치 과정에서 기본 설정을 따

yes5.tistory.com

 

Dockerfile 작성

프로젝트 루트 디렉토리에 Dockerfile을 작성합니다. Dockerfile은 Docker 이미지를 빌드하기 위한 설정 파일입니다. 다음은 예시 Dockerfile입니다:

# Node.js 이미지를 기반으로 합니다
FROM node:18

# 작업 디렉토리를 설정합니다
WORKDIR /app

# 패키지 파일들을 컨테이너로 복사합니다
COPY package*.json ./

# 의존성 패키지를 설치합니다
RUN npm install

# 애플리케이션 소스 파일들을 컨테이너로 복사합니다
COPY . .

# 애플리케이션이 실행될 포트를 설정합니다
EXPOSE 3000

# 애플리케이션을 실행합니다
CMD ["node", "index.js"]

 

 

.dockerignore 작성

Docker 빌드 컨텍스트에 포함시키지 않을 파일들을 지정하기 위해 .dockerignore 파일을 작성합니다. 일반적으로 node_modules 폴더와 로그 파일 등을 제외합니다.

node_modules
npm-debug.log

 

디렉토리 위치

 

Docker 이미지 빌드

VSCode 터미널이나 명령 프롬프트를 열고, 프로젝트 디렉토리로 이동한 후 다음 명령어를 실행하여 Docker 이미지를 빌드합니다:

 

docker build -t my-express-app .

 

Docker 컨테이너 실행

이미지 빌드가 완료되면 다음 명령어로 Docker 컨테이너를 실행할 수 있습니다:

docker run -p 3000:3000 my-express-app

 

Docker 컨테이너 내 express 앱 실행 확인

http://localhost:3000 

+ Recent posts