cloudpark

AWS CodePipeline을 이용하여 정적 웹 사이트를 S3에 배포

CloudLee — Mon, 25 Mar 2024 18:50:45 +0900

AWS CodePipeline을 이용하여 정적 웹 사이트를 S3에 배포

CodePipeline + S3

CodePipeline이란?

소프트웨어 릴리스에 필요한 단계를 모델링, 시각화 및 자동화하는 데 사용할 수 있는 지속적 전달하는 서비스로, 릴리스 프로세스의 여러 단계를 신속하게 모델링하고 구성할 뿐 아니라 소프트웨어 변경 사항을 지속적으로 릴리스하는 데 필요한 단계를 자동화합니다.

S3란?

최고의 확장성, 데이터 가용성, 보안 및 성능을 제공하는 객체 스토리지 서비스로, 데이터 레이크, 웹사이트, 모바일 애플리케이션, 백업 및 복원, 아카이브, 엔터프라이즈 애플리케이션, IoT 디바이스, 빅 데이터 분석 등 다양한 사용 사례에서 원하는 양의 데이터를 저장할 뿐 아니라 보호합니다.

# TL;DR

CloudFormation 템플릿을 활용하여 CodePipeline과 S3 서비스 구축하여 정적 웹 사이트를 배포합니다.

웹사이트 호스트 설정을 한 S3 Bucket을 Management console 상에서 미리 생성한 후에 진행합니다.

GitHub 리포지토리와 CodePipeline과 연동한 후에 git push, merge 를 계기로 vue.js 소스코드를 빌드하여 S3 bucket에 배포합니다.

buildspec.yml을 이용하여 CodeBuild를 정의하며. Cloudformation템플릿으로 CodePipeline.yml을 작성하여 CodePipeline을 정의합니다.

서비스 구축은 아래와 같은 순서로 진행합니다.

CodePipeline 구축 순서

Codebuild에서 수행할 작업을 정의하는 buildspec.yml 작성
Cloudformation템플릿(CodePipeline.yml)의 파라미터를 정의한 Parameters.json 작성
CodePipeline을 구성하기 위한 Cloudformation템플릿(CodePipeline.yml) 작성
AWS CLI로 CloudFormation 스택 생성
CodePipeline 실행 테스트
AWS CLI로 CloudFormation 스택 삭제

# 아키텍처 다이어그램

GitHub Repository의 소스 코드를 git clone, 빌드하여 S3 Bucket에 배포하는 다이어그램입니다.
CodeBuild와 CodePipeline에서 S3 bucket에 엑세스하기 위하여 권한을 부여하는 IAM role이 필요합니다.

# 개요

CI/CD 파이프라인을 Codepipeline으로 구현하여 GitHub 리포지토리에 있는 소스 코드를 빌드하여 자동으로 S3 bucket으로 배포하는 서비스를 구축합니다.

서비스	역할
AWS CloudFormation	스택 생성
AWS IAM	액세스 권한 추가
AWS S3	콘텐츠 배치, 아티팩트
CodeBuild	코드 빌드
CodeDeploy	코드 배포
CodePipeline	CI/CD 파이프라인 구축
GitHub	리포지토리

# Codebuild에서 실행하는 작업을 명시하는 buildspec.yml 작성

version: 0.2

phases:
  install:
    runtime-versions:
      nodejs: 14
  pre_build:
    commands:
      - echo cache clear
      - npm cache clear --force
      - echo npm install
      - npm install 
  build:
    commands:
      - echo code build
      - npm run build
artifacts:  
  files:
    - "**/*"
  base-directory: dist

nodejs : 14 -> nodejs버전을 지정합니다.
base-directory : dist -> 아티팩트의 base(root)를 빌드한 소스가 저장되는 dist 디렉토리로 지정하며 files: **/* 로 dist 디렉토리의 모든 파일을 아티팩터로 저장합니다. codedeploy에서 아티팩터에 저장된 빌드된 소스를 s3 bucket에 배포하기 위하여 필요합니다.

# GitHub와 CodePipeline을 연동

우선 AWS Management console에서 Create connection을 통해 GitHub와 CodePipeline을 연동하도록 설정합니다.

connection 생성한 후엔 ConnectionArn의 값을 메모하여 다음 cloudformation parameter 파일에 추가하도록 합니다.

AWS management console을 통해 GitHub와 CodePipeline 연동하는 방법

https://docs.aws.amazon.com/dtconsole/latest/userguide/connections-create-github.html

# Cloudformation작성에 필요한 파라미터 파일 codepipeline.json 작성

[
    {
      "ParameterKey": "Env",
      "ParameterValue": "dev"
    },
    {
      "ParameterKey": "Branch",
      "ParameterValue": "${git의 branch명}"
    },
    {
        "ParameterKey": "Repository",
        "ParameterValue": "${git의 리포지토리명}"
    },
    {
      "ParameterKey": "AppBucketName",
      "ParameterValue": "${정적웹사이트의 S3 bucket명}"
    },
    {
      "ParameterKey": "GitConnectionArn",
      "ParameterValue": "${ConnectionArn의 값}"
    }
  ]

Codepipeline과 연동할 git의 branch명, 리포지토리명, CodeConnetction Arn을 파라미터로 지정합니다.
미리 생성한 S3 bucket명을 파라미터로 지정합니다.

#CodePipeline을 구성하기 위한 Cloudformation 파일 (codepipeline.yml) 작성

AWSTemplateFormatVersion: "2010-09-09"
Description: CodePipeline S3 stack.

# ------------------------------------------------------------
# Parameter
# ------------------------------------------------------------

Parameters:
  Env:
    Type: String
    Default: "dev"
  Branch:
    Type: String
    Default: ""
  Repository:
    Type: String
    Default: ""
  AppBucketName:
    Type: String
    Default: ""
  GitConnectionArn
    Type: String
    Default: ""
    
Resources:
  # ------------------------------------------------------------
  # Artifact용 S3 Bucket
  # ------------------------------------------------------------

  ArtifactBucket:
    Type: AWS::S3::Bucket
    Properties:
      BucketName: !Sub ${Env}-artifact
      VersioningConfiguration:
        Status: Enabled

  # ------------------------------------------------------------
  # CodeBuild
  # ------------------------------------------------------------

  CodeBuild:
    Type: AWS::CodeBuild::Project
    Properties:
      Name: !Sub ${Env}-codebuild
      Source:
        BuildSpec: buildspec.yml
        Type: CODEPIPELINE
      Artifacts:
        Name: !Sub ${Env}-codepipeline
        Packaging: NONE
        Type: CODEPIPELINE
      Cache:
        Type: NO_CACHE
        
      # 환경설정
      Environment:
        ComputeType: BUILD_GENERAL1_SMALL
        Image: aws/codebuild/standard:5.0
        ImagePullCredentialsType: CODEBUILD
        PrivilegedMode: false
        Type: LINUX_CONTAINER
      ServiceRole: !GetAtt CodebuildServiceRole.Arn
      TimeoutInMinutes: 60
      QueuedTimeoutInMinutes: 480
      BadgeEnabled: false

      # 로그 설정
      LogsConfig:
        CloudWatchLogs:
          Status: ENABLED
        S3Logs:
          Status: DISABLED

  # ------------------------------------------------------------
  # CodePipeline
  # ------------------------------------------------------------

  CodePipeline:
    Type: AWS::CodePipeline::Pipeline
    Properties:
      Name: !Sub ${Env}-pipeline
      RoleArn: !GetAtt CodepipelineServiceRole.Arn
      ArtifactStore:
        Location: !Ref ArtifactBucket
        Type: S3
      Stages:
        - Name: Source
          Actions:
            - Name: Source
              ActionTypeId:
                Category: Source
                Owner: AWS
                Provider: CodeStarSourceConnection
                Version: "1"
              Configuration:
                # 브랜치 지정
                BranchName: !Ref Branch
                # github 연동
                ConnectionArn: 
                 - !Ref GitConnectionArn
                # 리포지토리 지정
                FullRepositoryId: !Ref Repository
                OutputArtifactFormat: CODE_ZIP
              OutputArtifacts:
                - Name: SourceArtifact
              Namespace: SourceVariables
              RunOrder: 1
        - Name: Build
          Actions:
            - Name: Build
              ActionTypeId:
                Category: Build
                Owner: AWS
                Provider: CodeBuild
                Version: "1"
              Configuration:
                EnvironmentVariables: !Sub |
                  [
                    {"name":"STAGE","value":"dev","type":"PLAINTEXT"}
                  ]
                ProjectName: !Ref CodeBuild
              InputArtifacts:
                - Name: SourceArtifact
              OutputArtifacts:
                - Name: BuildArtifact
              Namespace: BuildVariables
              RunOrder: 1
        - Name: Deploy
          Actions:
            - Name: Deploy
              ActionTypeId:
                Category: Deploy
                Owner: AWS
                Provider: S3
                Version: "1"
              Configuration:
                BucketName: !Ref AppBucketName
                Extract: true
              InputArtifacts:
                - Name: BuildArtifact
              Namespace: DeployVariables
              RunOrder: 1
              
  # ------------------------------------------------------------
  # IAM
  # ------------------------------------------------------------

  #### CodeBuild Role 생성
  CodebuildServiceRole:
    Type: AWS::IAM::Role
    Properties:
      Path: /
      RoleName: !Sub ${Env}-codebuild-service-role
      AssumeRolePolicyDocument:
        Version: "2012-10-17"
        Statement:
          - Effect: Allow
            Principal:
              Service:
                - codebuild.amazonaws.com
            Action:
              - sts:AssumeRole
      Policies:
        - PolicyName: !Sub ${Env}-build-policy
          PolicyDocument:
            Version: "2012-10-17"
            Statement:
              - Resource:
                  - !GetAtt LogGroup.Arn
                Effect: Allow
                Action:
                  - logs:CreateLogGroup
                  - logs:CreateLogStream
                  - logs:PutLogEvents
              - Resource:
                  - arn:aws:s3:::codepipeline-ap-northeast-2-*
                  - !Sub arn:aws:s3:::${ArtifactBucket}/
                  - !Sub arn:aws:s3:::${ArtifactBucket}/*
                Effect: Allow
                Action:
                  - s3:GetObject
                  - s3:PutObject
                  - s3:GetObjectVersion
                  - s3:GetBucketAcl
                  - s3:GetBucketLocation
                  - s3:List*
              - Resource:
                  - !Ref ReportGroup
                Effect: Allow
                Action:
                  - codebuild:CreateReportGroup
                  - codebuild:CreateReport
                  - codebuild:UpdateReport
                  - codebuild:BatchPutTestCases
                  - codebuild:BatchPutCodeCoverages

  ### CodePipeline Role 생성
  CodepipelineServiceRole:
    Type: AWS::IAM::Role
    Properties:
      Path: /
      RoleName: !Sub ${Env}-codepipeline-service-role
      AssumeRolePolicyDocument:
        Version: "2012-10-17"
        Statement:
          - Effect: Allow
            Principal:
              Service:
                - codepipeline.amazonaws.com
            Action:
              - sts:AssumeRole
      Policies:
        - PolicyName: !Sub ${Env}-codepipeline-base-policy
          PolicyDocument:
            Version: "2012-10-17"
            Statement:
              - Resource:
                  - "*"
                Effect: Allow
                Action: 
                  - codedeploy:CreateDeployment
                  - codedeploy:GetApplicationRevision
                  - codedeploy:GetDeployment
                  - codedeploy:GetDeploymentConfig
                  - codedeploy:RegisterApplicationRevision
              - Resource:
                  - "*"
                Effect: Allow
                Action:
                  - codestar-connections:UseConnection  
              - Resource:
                  - "*"
                Effect: Allow 
                Action: 
                  - s3:*
              - Resource:
                  - "*"
                Effect: Allow 
                Action:
                  - codebuild:BatchGetBuilds
                  - codebuild:StartBuild
              - Resource: "*"
                Effect: Allow
                Action:
                  - servicecatalog:ListProvisioningArtifacts
                  - servicecatalog:CreateProvisioningArtifacts
                  - servicecatalog:DescribeProvisioningArtifacts
                  - servicecatalog:DeleteProvisioningArtifacts
                  - servicecatalog:UpdateProduct

  # ------------------------------------------------------------
  # log-group && report-group 생성
  # ------------------------------------------------------------

  LogGroup:
    Type: AWS::Logs::LogGroup
    Properties:
      LogGroupName: !Sub /aws/codebuild/${Env}-codebuild

  ReportGroup:
    Type: AWS::CodeBuild::ReportGroup
    Properties:
      Name: !Sub ${Env}-report-group
      Type: TEST
      ExportConfig:
        ExportConfigType: NO_EXPORT

CodePipeline 아티팩트용 S3 Bucket을 생성합니다.
Codepipleline과 CodeBuild에는 필요한 IAM role을 생성합니다.
CodeBuild를 통해 소스 코드 빌드 시 에러 로그를 확인할 수 있도록 로그 그룹을 생성합니다.

# AWS CLI로 CloudFormation 스택 생성

# 스택생성
$ ENV=dev
$ aws cloudformation create-stack \
  --stack-name "$ENV-stack" \ 
  --template-body file://codepipeline.yml \
  --parameters file://codepipeline.json \
  --capabilities CAPABILITY_NAMED_IAM

CloudFormation 스택 생성을 위한 AWS CLI는 위 내용과 같이 command를 실행합니다.
--stack-name에는 생성되는 스택명, --template-body에는 cloudformation template명 , --parameters에는 파라미터의 json을 지정합니다.
--capabilities의 경우 IAM role생성 시 필수로 적용해야 하는 옵션입니다.

# CodePipeline 실행 테스트

Codepipeline 실행 성공 여부는 Management console의 Codepipeline의 Pipelines에서 확인합니다.

Git 리포지토리에 있는 소드 코드가 문제없이 성공적으로 업데이트된 화면입니다.

CodeBuild를 실행된 화면입니다.

빌드된 소스 코드가 S3 bucket에 성공적으로 배포된 화면입니다.

# AWS CLI로 CloudFormation 스택 삭제

# 스택삭제
$ ENV=dev
$ aws cloudformation delete-stack --stack-name "$ENV-stack"

CloudFormation 스택 삭제를 위한 AWS CLI는 상기 command로 삭제합니다.

# 요약

CodePipeline을 활용하면 CI/CD 파이프라인을 쉽게 구축하는 것이 가능합니다.
CodePipeline을 사용하면 소스 코드가 업데이트될 때마다 자동으로 빌드하고 배포시킬 수 있게 됩니다.
CloudFormation을 활용하면 빠르게 AWS Service를 구축할 수 있어 유용합니다.

# 참고 공식문서

S3 Bucket 생성

https://docs.aws.amazon.com/ko_kr/AmazonS3/latest/userguide/create-bucket-overview.html

버킷 생성 - Amazon Simple Storage Service

객체 잠금을 사용하는 버킷을 생성하려면 s3:CreateBucket, s3:PutBucketVersioning 및 s3:PutBucketObjectLockConfiguration 권한이 있어야 합니다.

docs.aws.amazon.com

GitHub 연동 콘솔활용

https://docs.aws.amazon.com/ko_kr/codepipeline/latest/userguide/connections-github.html

GitHub 연결 - AWS CodePipeline

AWS CLI 또는 AWS CloudFormation을 통해 생성된 연결은 기본적으로 PENDING 상태입니다. CLI 또는 AWS CloudFormation을 사용하여 연결을 생성한 후 콘솔을 통해 연결을 편집하여 상태를 AVAILABLE로 설정합니다.

docs.aws.amazon.com

CodePipeline CodestarConnetion 참고

https://docs.aws.amazon.com/codepipeline/latest/userguide/action-reference-CodestarConnectionSource.html

CodeStarSourceConnection for Bitbucket Cloud, GitHub, GitHub Enterprise Server, GitLab.com, and GitLab self-managed actions - AW

This feature is not available in the Asia Pacific (Hong Kong), Asia Pacific (Hyderabad), Asia Pacific (Jakarta), Asia Pacific (Melbourne), Asia Pacific (Osaka), Africa (Cape Town), Middle East (Bahrain), Middle East (UAE), Europe (Spain), Europe (Zurich),

docs.aws.amazon.com

AWS EC2 Instance로 Redmine 5.1.0 구축(Amazonlinux 2023)

CloudLee — Tue, 12 Dec 2023 16:14:26 +0900

AWS EC2 Instance로 Redmine 구축(Amazonlinux 2023)

레드마인(Redmine)이란?

레드마인(Redmine)은 웹 기반의 프로젝트 관리와 버그 추적 기능을 제공하는 오픈 소스 프로그램입니다. 소프트웨어 개발 및 여러 협업 작업을 관리하는 데 사용됩니다. Ruby on Rails에 기반하여 작성되었으며, 멀티플랫폼을 지원할 뿐 아니라 여러 가지 종류의 데이터베이스 및 34개의 언어를 지원합니다.

주요 기능

화면기반의 관리에 도움이 되도록 달력과 간트 차트를 제공합니다. 일정관리 및 통합된 프로젝트관리가 가능합니다. 이슈추적 및 여러 가지 형상관리 기능을 제공합니다.

# TL;DR

이번 튜토리얼에서는 AWS EC2로 Redmine 서버를 간단히 구성하고 구축합니다.

VPC에 Public Subnet 1개만 사용하며, EC2 Instance에 Apache, Redmine과 별도로 RDS를 구성하지 않고 Mysql/MariaDB를 인스톨하는 방법을 소개합니다.

Redmine 서버 액세스 시 default port 3000번을 그대로 사용하며, SSH Client을 통한 EC2 Instance 연결을 위해 port 22번을 허용하는 보안그룹을 구성합니다.

OS는 Amazon Linux 2023을 사용하며, EC2 Instance는 기존에 초기설정을 완료하였던 AMI를 적용한 뒤 시작합니다.

서버 구축 시 Redmine 5.1.0를 사용하며, Apache 2.4.58, Ruby 3.2.2, Passenger 6.0.19, Mysql/MariaDB 15.1/10.5.20을 사용합니다.

Redmine 서버 구성 및 구축은 아래와 같은 순서로 진행합니다.

Redmine 서버 구성 및 구축순서

Redmine 시스템 사용자 생성
Apache 서버 설치
Redmine MariaDB 데이터베이스 설치 및 mysql 사용자 생성
Redmine 다운로드와 Ruby 및 필수 Package(dependencies) 설치
Redmine 데이터 베이스 연결 설정 구성
Ruby Package(dependencies) 설치
세선 토큰과 스키마 객체 생성
파일 시스템 권한 구성
Redmine 설치 테스트
Apache Passenger module 설치와 Redmine Apache 구성파일 생성 및 수정
Apache Passenger module 설치 후 포트 확인 및 브라우저 액세스

# 개요

AWS EC2 Instance에 Redmine을 설치하여 서버를 구성, 구축하는 과정을 설명합니다. 데이터베이스로 MariaDB를 사용하고, Ruby on Rails 및 Passenger와 Apache를 설치하여 사용합니다.

이름	버전	설치
Redmine	5.1.0	download
Apache	2.4.58	dnf
Ruby	3.2.2	dnf
Passenger	6.0.19	gem
Mysql/MariaDB	15.1/10.5.20	dnf

* 레드마인 설치 시 버전정보 참고 : https://www.redmine.org/projects/redmine/wiki/RedmineInstall

RedmineInstall - Redmine

Installing Redmine¶ This is the installation documentation for Redmine 4.0 and higher. You can still read the document for older versions: 3.x , 1.4.x - 2.6.x, 1.3.x Requirements¶ Operating system¶ Redmine should run on most Unix, Linux, macOS and Windo

www.redmine.org

# 인프라 구성

VPC와 IPv4를 할당하여 Public Subnet을 생성합니다.
Internet Gateway를 생성하고, Public Subnet과 연결합니다.
Route tables Routes 대상에 0.0.0.0/0을 추가하고 Internet Gateway를 연결합니다.
EC2 Instance 시작하여 생성한 VPC, Public Subnet과 연결하고, key pair를 생성한 뒤 다운로드를 진행합니다.
Security Groups는 Port 22는 MyIP(현재본인아이피)로 3000은 0.0.0.0/0으로 액세스를 허용하도록 구성합니다.
EC2 Instance에 연결하고 단계적으로 Redmine 설치를 진행합니다.

# Redmine 시스템 사용자 생성

$ sudo su
$ useradd -r -m -d /opt/redmine redmine 

# 시스템 사용자 생성확인
$ cat /etc/passwd | grep "redmine"

Redmine 설치 시에는 시스템 사용자 생성이 필요합니다. command로는 useradd를 사용합니다. 기본적으로 useradd -r command 만으로 사용자 생성이 가능하지만 별도의 디렉터리에 Redmine을 설치하고 홈 디렉터리로 지정하기기 위해 추가적으로 -m과 -d 옵션을 함께 사용해야 합니다. 시스템 사용자 생성에 필요한 모든 절차가 끝난 후 생성 여부를 재확인합니다.

# Apache 서버 설치

$ sudo su
$ dnf isntall httpd 

# Apache 버전확인
$ httpd -v

# 시스템 시작 시 자동기동 설정
$ systemctl enable httpd --now

# redmine 그룹에 apache 사용자 추가
usermod -aG redmine apache

# 그룹추가 여부 확인
$ cat /etc/group | grep "redmine"

우선 Apache를 설치합니다. 설치완료되면 버전을 확인하여 설치가 제대로 되었는지 확인합니다. 또한 시스템 시작 시 자동적으로 기동 될 수 있도록 설정합니다. redmine 그룹에 apache 사용자를 추가합니다.

# Redmine MariaDB 데이터베이스 설치 및 Mysql 사용자 생성

$ sudo su

# mariadb-server 설치 
$ dnf install mariadb-server

# mariadb 자동기동설정
$ systemctl enable --now mariadb

Redmine 데이터베이스 생성을 위해 MariaDB를 설치합니다. Redmine은 PostgerSQL, MS-SAL, SQLite 여러 데이터베이스 백엔드를 지원하기에 선택적으로 진행하는 것이 가능합니다. 설치 후 시스템 부팅 시에는 MariaDB 서버를 시작하고 활성화할 수 있도록 command를 적용합니다.

# 데이터베이스 보완관련 설정
$ mysql_secure_installation

초기 MariaDB 데이터베이스 보안 스크립트를 실행하여 적절하게 보안을 설정하는 것이 필요합니다. 기본 데이터 베이스, 테스트 테이블을 제거해야 합니다. 또한 원격 루트 로그인을 비활성화합니다.

# root 암호로 mysql 사용자 접속
$ mysql -u root -p

# 데이터베이스 생성
mysql> create database redminedb;

# 사용자 생성
mysql> grant all on redminedb.* to redmineadmin@localhost identified by 'my-pwd';

# 설정사항 적용
mysql> flush privileges;
mysql> quit

데이터베이스 백엔드가 설치된 후에는 mysql 사용자로 접속합니다. 접속 후 Redmine용 데이터베이스 및 사용자를 생성한 뒤 데이터베이스 이름을 지정해야 합니다. 생성된 데이터베이스에 대한 모든 권한은 사용자에게 부여하고, 이에 따라 사용자와 비밀번호를 변경합니다. 모든 설정사항이 적용된 후 권한 테이블은 다시 로드하고, 종료합니다.

# Redmine 다운로드와 Ruby 및 필수 Package(dependencies) 설치

$ sudo su
$ dnf install ruby-devel \
    rpm-build \
    wget \
    libxml2-devel \
    vim \
    make \
    openssl-devel \
    automake \
    libtool \
    ImageMagick \
    ImageMagick-devel \
    mariadb-devel \
    gcc \
    httpd-devel \
    libcurl-devel \
    gcc-c++ -y

# ruby 버전확인
$ ruby -v

Redmine을 다운로드하게 될 시 빌드에 필요한 다양한 Package(dependencies)들을 설치하는 게 필수입니다. 자동으로 설치되는 Ruby interpreter도 필요합니다. Redmine 버전마다 Ruby 지원 버전이 다르기에 Ruby의 원활한 작동을 위해선 버전을 확인해야 합니다.

$ sudo su
$ VER=5.1.0

# Redmine 5.1.0 다운로드 및 설치폴더 생성
$ curl -s https://www.redmine.org/releases/redmine-$VER.tar.gz | \
sudo -u redmine tar xz -C /opt/redmine/ --strip-components=1

# Redmine 5.1.0 여러 구성파일 확인
$ ls -alh /opt/redmine

Ruby 버전 지원 여부를 확인한 뒤 공식 페이지로 이동하여 Redmine 5.1.0 압축 파일을 다운로드합니다. 압축해제는 redmine설치를 위해 생성한 /opt/redmine에서 진행합니다. 모든 과정이 끝났을 경우, 여러 구성파일들을 /opt/redmine/ 경로에서 확인할 수 있어야 합니다.

# Redmine 데이터베이스 연결 설정 구성

$ sudo su
$ su - redmine

# 여러 구성파일 변경 및 복사
$ cp config/configuration.yml{.example,}
$ cp public/dispatch.fcgi{.example,}
$ cp config/database.yml{.example,}

# 데이터베이스 구성파일 수정
$ vi config/database.yml

Redmine 데이터베이스는 연결 설정 구성을 적절하게 변경하거나 수정해야 합니다. 앞선 과정을 진행하기 위해선 Redmine의 사용자 계정으로 전환하는 것이 필요합니다. 순차적으로 샘플 Redmine 구성파일, public 디렉터리 내에 있는 샘플 디스패치 CGI 구성파일, 샘플 데이터베이스 구성파일의 이름을 변경하고 복사합니다. 샘플 데이터 베이스의 경우, 별도로 데이터베이스 이름, 사용자 및 비밀번호를 앞서 설정한 대로 동일하게 수정한 뒤 저장합니다.

# database.yml 파일구성 및 변경방법
production:
  adapter: mysql2
  database: redminedb # 작성한 database명으로 변경
  host: localhost
  username: redmineadmin # 작성한 mysql 사용자로 변경
  password: "my_pwd"     # 작성한 mysql 사용자의 패스워드로 변경
  # Use "utf8" instead of "utfmb4" for MySQL prior to 5.7.7
  encoding: utf8mb4

database.yml 파일 수정 시 다음 구문을 찾아야 합니다. database, username, password는 데이터베이스 및 사용자 생성에서 입력한 대로 변경합니다.

# Ruby Package(dependencies) 설치

$ sudo su
$ su - redmine

# bundler 설치
$ gem install bundler

# bundler 구성 옵션 설정
$ bundle config set --local path 'vendor/bundle'
$ bundle config set --local without 'development test'

# dependencies 설치 
$ bundle install

Ruby의 경우에는 여러 Package(dependencies)를 설치하는 것이 필수입니다. Redmine 사용자 계정으로 현재 로그인이 되어 있지 않다면 Redmine 사용자 계정으로 전환하여 진행해야 합니다. 우선적으로 gem Package(dependencies)를 관리하기 위한 bundler를 설치합니다. 완료 후에는 필수 gem Package(dependencies)를 설치하는 것이 가능합니다.

# 세션 토큰과 스키마 객체 생성

 $ bundle exec rake generate_secret_token

세션 데이터를 저장할 때에는 쿠키의 조정을 방지하는 것이 필요합니다. 이를 위해선 Rails가 쿠키를 인코딩하는 데 사용하는 임의의 비밀 키를 생성해야 합니다.

# 데이터베이스 구조를 생성
$ RAILS_ENV=production bundle exec rake db:migrate

# 기본 구성 데이터 투입
$ RAILS_ENV=production REDMINE_LANG=en bundle exec rake redmine:load_default_data

스키마 객체 생성 시 Rails 데이터베이스 구조를 생성하기 위해 데이터베이스 마이그레이션을 진행해야 합니다. 완료 후 기본 구성 데이터를 데이터베이스에 투입합니다.

# 파일 시스템 권한 구성

$ for i in tmp tmp/pdf public/plugin_assets; do [ -d $i ] || mkdir -p $i; done

# 소유자와 그룹 변경
$ chown -R redmine:redmine files log tmp public/plugin_assets

# user 외 755 권한부여
$ chmod -R 755 /opt/redmine/

Redmine 디렉터리 /opt/redmine에서 tmp, tmp/pdf, public and public/plugin_assets, log 디렉터리가 생성되어 있는지 확인하는 것이 필요합니다. 존재하지 않는 파일이 있는 경우에는 생성한 뒤, 소유자와 그룹, 권한 확인하여 Redmine을 실행하는 데 사용된 사용자로 모두 변경합니다.

# Redmine 설치 테스트

$ sudo su
$ su - redmine

# Gemfile에 webric 추가
$ echo 'gem "webrick"' >> Gemfile
$ bundle install

# Redmine 서버 설치 테스트
$ bundle exec rails server -u webrick -e production

Redmine 설정이 완료된 뒤에는 WEBrick을 사용하여 Redmine을 테스트하는 것이 가능합니다. 우선 Redmine 사용자로 변경한 후, Gemfile에 webrick을 추가합니다. Webrick gem을 설치하고 설치 테스트를 실시합니다. 샘플 출력 후에는 http://Server-IP:3000/ 해당 주소를 사용하여 Redmine에 액세스 하는 것이 가능합니다.

# 샘플 출력
=> Booting WEBrick
=> Rails 6.1.7.6 application starting in production http://0.0.0.0:3000
=> Run `bin/rails server --help` for more startup options
[2023-11-13 08:03:05] INFO  WEBrick 1.8.1
[2023-11-13 08:03:05] INFO  ruby 3.2.2 (2023-03-30) [x86_64-linux]
[2023-11-13 08:03:05] INFO  WEBrick::HTTPServer#start: pid=4022 port=3000

WEBrick을 통해 웹서버 Instance를 실행하기 위해서는 샘플 출력 내용을 확인하는 것이 중요합니다.

# Apache Passenger module 설치와 Redmine Apache 구성파일 생성 및 수정

$ sudo su
$ su - redmine
$ gem install passenger --no-document

# passenger-install-apache2-module 경우, 설치 가이드를 따라 Phusion Passenger를 설치
$ passenger-install-apache2-module

Passenger module 설치는 redmine 사용자 계정으로 진행해야 합니다. 설치 후에는 그에 따라 버전을 교체하는 것이 필요합니다. 설치 가이드에 따라 진행해야 하며, 언어의 경우에는 Ruby를 선택합니다.
passenger-install-apache2-module 완료 후에는 모듈 구성방법이 제공되므로 해당 내용대로 redmine.conf 파일을 수정해야 합니다.

$ sudo su
$ vi /etc/httpd/conf.d/redmine.conf

apache 설정파일을 수정합니다.

# redmine.conf 파일구성 
<IfModule mod_passenger.c>
  PassengerRoot /opt/redmine/.local/share/gem/ruby/gems/passenger-6.0.18
  PassengerDefaultRuby /usr/bin/ruby
</IfModule>
<VirtualHost *:3000>
    ServerName {server-IP-or-Hostname}
    DocumentRoot "/opt/redmine/public" 

    CustomLog logs/redmine_access.log combined
    ErrorLog logs/redmine_error_log
    LogLevel warn

    <Directory "/opt/redmine/public">
        Options Indexes ExecCGI FollowSymLinks
        Require all granted
        AllowOverride all
    </Directory>
</VirtualHost>

<IfModule mod_passenger.c>.. </IfModule> 부분은 passenger-install-apache2-module 완료 후 표시되는 내용대로 작성해 주는 것이 중요합니다.

# 구성구문 재확인 
$ passenger-install-apache2-module --snippet

# Syntax 확인
$ httpd -t

$ systemctl restart httpd.service

구성 구문이 재확인하려면 passenger-install-apache2-module --snippet를 사용합니다. redmine.conf 파일을 수정하고 저장한 뒤에는 httpd -t로 에러가 없는지 확인합니다. redmine.conf를 수정하였으므로 Apache를 재기동해야 합니다.

# Apache Passenger module 설치 후 포트 확인 및 브라우저 액세스

$ sudo su
$ su - redmine

# 포트확인
$ ss -altnp

Redmine 서버에 액세스 하기에 앞서 redmine 사용자 계정으로 전환합니다. command를 통해 포트 3000에 수신 대기 중인 항목이 있는지 확인해야 합니다. 브라우저를 통해 Redmine 액세스 시에는 http://server-IP-or-Hostname:3000 주소를 입력하여 Redmine이 표시되는지 확인합니다.

RDS (Aurora for Mysql) 운영 방법

iolle — Sat, 16 Jul 2022 19:42:23 +0900

AWS에서 RDS를 운영하다 보면 Master RDS 와 Read Replica RDS 로 2대구성으로 운영을 하게 됩니다.

어플리케이션에서 select sql 은 Read Replica RDS로 Insert, Update sql 은 Master RDS로 실행하면 가장 좋지만

SQL Split하는 방법을 애플리케이션쪽에서 하지 않고 인프라쪽에서 하는 방법이 있습니다.

SQL Split이란 Select Sql은 Read Relica로 Insert, Update Sql은 Master에서 실행하도록 Sql를 나누어 주는 것입니다.

heimdal database proxy 를 이용하는 방법

자세한 내용은 아래 AWS 블로그에 자세하게 설명되어 있습니다.

https://aws.amazon.com/ko/blogs/apn/using-the-heimdall-proxy-to-split-reads-and-writes-for-amazon-aurora-and-amazon-rds/

Using the Heimdall Proxy to Split Reads and Writes for Amazon Aurora and Amazon RDS | Amazon Web Services

Horizontally scaling a SQL database involves separating the write-master from read-only servers. This allows the write server to perform dedicated write operations rather than processing redundant read queries. However, writing to one node and reading from

aws.amazon.com

SSM Change Calendar + Eventbridge Rule를 이용한 RDS Auto ScaleUp / ScaleDown

굳이 SQL Split를 이용하지 않고 RDS 를 Scale Up하는 방법도 있습니다.

제가 운영하는 쪽에서는 아침 6시30분에 Read Replica 를 Scale Up해서 Failover하여 Read Replica -> Master로 승격하여 운영하다가 저녁 9시에 Failover하여 Read Replica (원래 Master) -> Master로 승격시키고 원래 Read Replica 를 Scale Down 하여 운영하고 있었습니다.

Eventbridge Rule 의 Failover ( Reader를 Master로 승격 ) Cron설정 (월 ~ 금 아침 6시 30분 실행)

cron(30 21 ? * SUN-THU *)

Eventbridge Rule 의 Failback ( Master를 Reader로 강등 ) Cron설정 (월 ~ 금 저녁 9시 00분 실행)

cron(0 12 ? * MON-FRI *)

Eventbridge Rule 시간은 전부 UTC로 설정합니다.

Eventbridge Rule를 사용하면 Cron 설정으로 월~금만 Scale Up하게끔 할 수 있지만 공휴일인 경우에는 Scale Up하지 않도록 매번 수동으로 Eventbridge Rule를 Diable해야 했습니다.

그래서 자동으로 공휴일에도 Scale Up되지 않도록 Cron 설정만으로는 안되고 캘린더랑 연동할 수 있는 방법이 있지 않을까 해서 찾은게

SSM Change Calendar 라는 서비스가 있었습니다.

자세한 내용은 https://cloudpark-iolle.tistory.com/8 를 참조해 주세요.

최종적으로 SSM Change Calendar(holiday-calendar) -> Lambda(calendar-event rule) -> Eventbridge Rule(failoverrule-diable lambda) -> EventBridge Rule (rds-failover rule) -> Lambda(rds-auto-failover) -> RDS 로 이어지는 구성이 됩니다.

최종 Diagram

RDS Auto Failover by Calendar

여기서 RDS의 Size가 크면 클수록 ScaleUp / ScaleDown 실행시 Lambda 실행시간(15분)을 초과하는 경우가 있을 수 있습니다.

그래서 EventBridge Rule(rds-event rule)를 설정하여 Lambda는 ScaleUp만 실행시키고 종료하고 EventBridge Rule(rds-event rule)로 RDS Event를 캐치하여 Failover / Failback를 실행하도록 Lambda를 기동시키도록 하였습니다.

RDS Event로는 RDS-EVENT-0014 (InstanceClassModifyEndEventID) 와 RDS-EVENT-0071 (FailOverEndEventID)만 감시하도록 했습니다.

Event Flow

RDS Event Flow

AWS Systems Manager Change Calendar를 사용하여 완전 자동화를 실현

iolle — Fri, 27 May 2022 22:06:49 +0900

TL; DR

Change Calendar는 AWS에서 사용하는 캘린더
iCalendar형식
EventBridge와 연동 가능
캘린더 스케줄로 AWS 리소스 실행예약이 가능
cron 설정으로는 불가능한 스케줄 실행이 가능

SSM Change Calendar

AWS 에서 만들 수 있는 캘린더이면서
Systems Manager에서 Automation 과 RunCommand 를 실행할 때에 실행하는 날과 실행하지 않는 날을 캘린더로 지정할 수 있습니다. 예를 들어 개발환경의 EC2 인스턴스를 자동으로 업무시간외 공휴일에도 자동으로 정지시킬 수 있습니다.
기존 EventBridge Rule에서는 cron설정으로 지정된 시간, 지정된 요일, 지정된 날짜 만 설정된다는 단점을 Change Calendar를 사용하면 cron설정에 더하여 공휴일을 지정할 수 있습니다.

공휴일을 일일히 지정하지 않고도 google calendar를 Change Calendar를 만들 때에 import할 수 있습니다.

google calendar의 한국의 공휴일 ical 다운로드는 아래 링크로 다운로드할 수 있습니다.

https://calendar.google.com/calendar/ical/ko.south_korea%23holiday%40group.v.calendar.google.com/public/basic.ics

Change Calendar 다음 두 가지 유형이 있습니다.

DEFAULT_OPEN 또는 Open by default
Open(허가)된 상태가 표준이 되며 Close(거부)할 수 있는 기간을 지정합니다. 예를 들어 EventBridge Rule를 캘린더에서 지정된 기간동안 Disable상태로 만들 수 있습니다.

Default Open

DEFAULT_CLOSED 또는 Closed by default
Close(거부)된 상태가 표준이 되며 Open(허가)할 수 있는 기간을 지정합니다. 예를 들어 EventBridge Rule를 캘린더에서 지정된 기간동안 Enable상태로 만들 수 있습니다.

Default Close

인용 : https://aws.amazon.com/jp/blogs/mt/using-aws-systems-manager-change-calendar-to-prevent-changes-during-critical-events/

Using AWS Systems Manager Change Calendar to prevent changes during critical events | Amazon Web Services

When applications and their development teams grow or evolve around service-specific independent teams, coordination and visibility among projects, deployments and operational events become a critical issue. AWS customers use multiple AWS accounts for many

aws.amazon.com

다음에는 Change Calendar를 사용하여 RDS (Aurora for Mysql) 를 운영하는 방법을 소개하겠습니다.

2020년 9월 30일이후 생성된 S3 Bucket에 대하여 path style의 S3 API Request가 중지됩니다

iolle — Thu, 20 Aug 2020 19:45:23 +0900

공식 블로그

https://aws.amazon.com/ko/blogs/korea/amazon-s3-path-deprecation-plan-the-rest-of-the-story/

Amazon S3 경로 기반 API 사용 중지 계획 안내 | Amazon Web Services

지난 주 저희는 Amazon S3 버킷에 있는 객체의 주소를 지정하는 데 사용되는 경로 기반 액세스 모델을 중지할 것임을 발표했습니다. 이 블로그 게시물을 작성하기 위해 저는 현 상황에 대해 S3 팀과

aws.amazon.com

S3 Endpoint 지정방법

패스 형식(path-style)

V1이라고 불림

패스부분에 버킷명이 들어감

http://s3.amazonaws.com/<bucket-name>(버지니아 리전만 가능)
http://s3-ap-northeast-2.amazonaws.com/<bucket-name>

가상호스트 형식(virtual hosted-style)

V2이라고 불림

호스트명에 버킷명이 들어감

http://<bucket-name>.s3.amazonaws.com
http://<bucket-name>.s3-ap-northeast-2.amazonaws.com

2020년9월30일이후에 생성된 버킷에 대하여 가상호스트형식만 허용됩니다.

따라서 2020년 9월 30일 이전에 생성된 버킷에 대해서는 가상호스트형식 뿐만 아니라 패스형식으로도 억세스가 가능합니다.

앞으로는 가상호스트 형식만 가능하므로 sdk를 이용하거나 버킷을 생성할때에 주의할 점이 있습니다.

aws-sdk-php 이용시 주의할 점

최신 SDK를 이용하면 되지만 프로그램 상에 use_path_style_endpoint가 false로 되어있는지를 확인해 볼 필요가 있습니다.

https://docs.aws.amazon.com/aws-sdk-php/v3/api/class-Aws.S3.S3Client.html

Class Aws\S3\S3Client | AWS SDK for PHP 3.x

Aws\AwsClient implements Aws\AwsClientInterface uses Aws\AwsClientTrait Aws\S3\S3Client implements Aws\S3\S3ClientInterface uses Aws\S3\S3ClientTrait Namespace: Aws\S3 Located at S3/S3Client.php Client used to interact with Amazon Simple Storage Service (A

docs.aws.amazon.com

버킷 생성시 주의할 점

under score ( _ ) 사용금지

버킷 생성시에 under score가 입력되지 않습니다만, 이전에 생성해둔 버킷명에 포함되어 있는지 확인해볼 필요가 있습니다. under score는 호스트명에 사용할 수 없으므로 호스트형식으로 변경되면 접근할 수 없습니다.

대문자 사용금지

under score와 마찬가지로 버킷 생성시에 대문자가 입력되지 않습니다만, 이전에 생성해둔 버킷명에 포함되어 있는지 확인해볼 필요가 있습니다. 대문자는 호스트명에서 소문자로 바뀌게 되므로 주의할 필요가 있습니다.

period 사용금지

under score와 대문자와 마찬가지로 period(마침표)를 버킷명에 사용할 수 없습니다. 버킷에 억세스할때 https로 억세스하기 때문에 *.s3.amazonaws.com 도메인의 SSL증명서를 사용할 수 없게 됩니다.

버킷명에 대한 공식 문서

https://docs.aws.amazon.com/ko_kr/AmazonS3/latest/dev/BucketRestrictions.html

fluentd를 이용하여 S3로 로그전송시 불필요한 Get Request를 없애는 방법

iolle — Thu, 23 Jul 2020 17:27:07 +0900

Fluentd를 이용하여 S3로 로그를 전송할 때에 다음과 같은 설정을 사용하면 불필요한 Get Request가 발생하게 됩니다.

check_object true (default true)
s3_object_key_format 에서 %{index}를 사용

상기 설정으로 S3에 저장되는 로그파일은 로그파일명_0.txt, 로그파일명_1.txt 형식으로 번호가 자동적으로 부여되면서 저장되게 됩니다.

제 경우에는 60초마다 로그를 전송하는데 1시간에 60개의 로그파일이 저장되고 24시간이면 1440개의 로그파일이 저장됩니다. 마찬가지로 로그파일명_0.txt 부터 로그파일명_1439.txt 까지 생기게 되죠.

잠시 fluentd가 로그파일을 중복되지 않고 전송하는 흐름을 살펴보면

S3에 로그파일명_0.txt 이 있다고 가정하에

서버상에서 로그파일명.log 를 S3로 Put
로그파일명_0.txt 로 Get Request 전송
에러가 발생하지 않으므로 S3에 존재한다고 판단하여 로그파일명_1.txt로 Get Request 전송
에러 ( "errorCode": "NoSuchKey"）가 발생하므로 S3에 없다고 판단하여 로그파일명_1.txt로 Put Request

입니다.

그러므로 제 경우에는 로그파일 하나당 24시간동안 보내는 Get Request가 1+2+3+~~~+1439 = 1,036,080 가 됩니다.

이걸 비용으로 계산하면

0.00035 USD ( 1000 Request당 ) X 1,091.08 (1,036,080을1000로 나눈값 ) = 0.381878 USD

로그파일 1개당 1일 0.381878 USD

월로 따지면 11.45634 USD ( 30일 기준 )

전송해야 하는 로그파일이 10개만 되어도 115 USD

S3 Get Request비용(서울리전)

저는 날짜별로 폴더를 나누어서 저장했어도 월 500 USD 정도 Get Request비용을 지불했습니다.

S3에 저장되는 로그파일을 index번호로 하지 않고 타임스탬프로 하면 중복될 이유가 없으므로 다음과 같이 변경했습니다.

check_object false
s3_object_key_format 에서 %{hms_slice}를 사용

여기서 %{hms_slice}를 사용하면 오후 2시10분46초인 경우에 031046으로 생성되게 됩니다.

time_slice_format은 utc를 true로 지정하지 않는 이상 Local timezone을 사용하게끔 되어 있습니다만,

%{hms_slice}는 03:10:46T09:00형식으로 됩니다.

그래서 저장된 시간과 파일명이 다르므로 약간 보기 어려워서 다음과 같이 설정하면 Local timezone형식으로 파일명에 사용할 수 있습니다.

s3_object_key_format 에서 %H%M%S 를 사용

이거 찾느라고 엄청 구글링해보았는데 아무도 사용하지 않아서 try & run 했습니다.

fluentd을 이용하여 s3로 로그전송시 전송지연 발생

iolle — Thu, 14 May 2020 20:18:53 +0900

fluentd가 flush하는 구조를 보면 다음 그림과 같이 buffer file에 tag값과 time 키값으로 chunk가 쌓이게 되고 flush_interval 에 설정된 시간이 지나거나 buffer_chunk_limit가 초과하게 되면 enqueue가 발생하게 됩니다.

fluentd output flush 구조

buffer chunk가 flush되는 조건은 다음과 같습니다.

buffer chunk가 flush되는 조건

flush_interval 설정값에 의하여 조건이 바뀌게 됩니다.

flush_interval를 설정하였을 때의 조건

buffer chunk 사이즈가 chunk_limit_size * chunk_full_threshold 에 도달했을 경우
buffer chunk가 생성되고 나서 flush_interval에 지정된 시간이 경과하였을 경우 (chunk_limit_size * chunk_full_threshold 에 도달하지 않은 경우에도 이 시간이 경과하면 강제적으로 flush됩니다)

flush_interval를 설정하지 않았을 때의 조건

buffer chunk사이즈가 chunk_limit_size * chunk_full_threshold에 도달한 경우
timekey로 지정된 시간폭 + timekey_wait 로 지정된 시간을 경과한 경우
- 다음과 같은 값이 설정되었다고 한다면 매시 9분 59초 ( 매시 59분 9초 + 10분 )에 flush 됩니다.
  - timekey: 1h
  - timekey_wait: 10m

fluentd(V 1.10.0)을 이용하여 애플리케이션 로그를 S3에 전송하도록 하였습니다.

td-agent.conf에서 flush간격을 flush_interval 을 60초로 설정하였습니다.

설정내용은 다음과 같이 했습니다.

<buffer tag,time>
    @type file
    path /var/log/td-agent/buffer/app
    flush_mode interval
    flush_interval 60s
    flush_at_shutdown true
</buffer>

운영을 하다보니 다음과 같은 warning 메세지(flush하는데에 시간이 초과되었습니다)가 기록되면서 s3에 전송되는 로그파일이 최대 12시간 정도후에 전송되는 일이 발생했습니다.

2020-05-07 21:31:22 +0900 [warn]: #0 buffer flush took longer time than slow_flush_log_threshold: elapsed_time=21.624852824024856 slow_flush_log_threshold=20.0 plugin_id="object:3fde83f49f4c"

그리고 buffer의 output type를 file로 설정하여서 /var/log/td-agent/buffer/app/ 밑에 buffer file이 생성되는데

buffer.b******************* 파일만 생성이 되고 60초가 지나도 buffer.q******************* 파일이 제대로 생성되지 않은 것을 알게 되었습니다. buffer.b******************* 파일이 2만개 정도 쌓이게 되었고 queue파일이 드문드문 생성되어 S3에 전송된다는 사실을 알게 되었습니다.

queue파일이 제대로 생성되지 않는 다는 원인에 기인하여 flush가 제대로 되고 있지 않는 것이었습니다. 그래서 공식document https://docs.fluentd.org/configuration/buffer-section를 찾아보게 되고 flush_thread_count가 default 한 개인 것을 알게 되어 flush thread를 좀 많게 하면 어떨까 하고 검증하게 되었습니다.

flush_thread_count 설정값과 연동하여 queued_chunks_limit_size값이 셋팅되기 때문에 다른 값을 설정하려면 queued_chunks_limit_size도 설정해야 될 필요가 있습니다.

・queued_chunks_limit_size [integer] (since v1.1.3)
    Default: 1 (equals to the same value as the flush_thread_count parameter)

그래서 td-agent.conf 다음과 같이 flush_thread_count를 4로 설정하여 테스트해 보았습니다.

<buffer tag,time>
    @type file
    path /var/log/td-agent/buffer/app
    flush_mode interval
    flush_interval 60s
    flush_at_shutdown true
    flush_thread_count 4
</buffer>

td-agent restart할 때엔 다음과 같이 하면 됩니다.

sudo service td-agent reload

reload함과 동시에 buffer.b******************* 파일이 buffer.q******************* 파일로 바뀌게 되고 2만개 정도의 buffer.q******************* 파일이 서서히 s3로 output되는 것을 볼 수가 있었습니다.

파일 변경 모니터링을 할 때에 watch command를 사용하면 모니터링을 할 수 있습니다.

watch -n 5 -d ls -l

aws spot instance 서버로그 관리(feat. fluentd)

iolle — Mon, 27 Apr 2020 22:13:27 +0900

Spot인스턴스를 사용하면 인스턴스 요금을 최대한 줄일 수 있습니다만 spot인스턴스 사용할 수 있는 용량이 적어지거나 설정한 요금보다 비싸지게 되면 spot인스턴스가 Stop되거나 terminate되는 경우가 있습니다.

terminate될 경우에 spot인스턴스내에 있던 로그를 영영 복구할 수 없게 되죠.

그래서 로그를 어떻게 하면 실시간으로 한곳에 모으거나 spot인스턴스가 terminate되는 신호를 trigger하여 로그를 Flush할 수 없을까하는 방법을 찾던 중에 fluentd를 찾게 되었습니다.

fluentd란?

그럼 fluentd는 무엇일까

간단히 얘기하자면 fluentd는 로그를 수집하는 도구입니다. 그리고 Opensource입니다.

https://www.fluentd.org/

Fluentd | Open Source Data Collector

"Logs are streams, not files. I love that Fluentd puts this concept front-and-center, with a developer-friendly approach for distributed systems logging." Adam Wiggins, Heroku co-founder

www.fluentd.org

fluentd(td-agent)를 사용하면 로그를 한곳으로 수집할 수 있고 또는 S3 bucket에 실시간으로 로그를 전송할 수 있습니다.

현재 SRE팀으로 시스템 운영을 하는 회사에서는 기존 시스템 로그, 애플리케이션 로그를 S3 bucket으로 S3 Sync를 이용하여 전송하고 있는데 cron설정으로 1시간마다 S3 sync하고 있어서 Spot인스턴스가 terminate하여 로그가 복구가 안되는 경우가 항상 있었습니다. 또한 S3 sync의 단점으로 뽑자면 로그파일의 용량이 어마무지하게 커지면 S3 Sync로 전송하는 경우에 리소스를 엄청 잡아 먹게 되어 서버에 부하를 주게 됩니다. 로그를 수집하려고 웹서비스에 영향을 주는 것은 잘못된 설계라고 할 수 있죠.

S3 Sync CLI

aws s3 sync ${APPLOGPATH} s3://${BUCKET_NAME/${APP_NAME}/${APP_ENV}/${year}/${month}/${day}/ --exclude "*" --include "${ymd}_*.log"

fluentd구성

그래서 fluentd로 할 수 있는 방법으로 재설계하게 되었습니다.

다음과 같이 간단하게 설계했습니다.

fluentd on Autosaling group

autoscaling group을 ondemand와 spot으로 구성하여 Scale Out 또는 Scale In 시에는 Spot인스턴스만 늘어나고 줄어 들게끔 구성하였습니다.

1. 통상적으로 운영시에는 로그파일의 용량이 커짐에 따라 수집할 데이터가 많아지므로 fluentd의 설정을 60초마다 tail방식으로 로그를 S3에 전송하도록 했습니다.

2. Scale In하게 되어 인스턴스가 줄어들게 되거나 spot인스턴스의 가용 용량이 적어지게 되거나 설정한 요금보다 높아지게 되면 spot인스턴스가 자동적으로 terminate하게 될 경우에는 Buffer상에 쌓아둔 로그를 자동적으로 flush하도록 스크립트를 작성하였습니다. Spot인스턴스는 중단되기 2분전에 중단 이벤트가 발생하므로 중단 이벤트를 트리거로 스크립트가 실행되게끔 설정하였습니다.

spot 인스턴스 중단 이벤트는 termination-time 메타데이터를 활용하는 것이 좋습니다.

TOKEN=`curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600"`
if curl -H "X-aws-ec2-metadata-token: $TOKEN" -s http://169.254.169.254/latest/meta-data/spot/termination-time | grep -q .*T.*Z; then echo terminated; fi

참고 : https://docs.aws.amazon.com/ko_kr/AWSEC2/latest/UserGuide/spot-interruptions.html

스팟 인스턴스 중단 - Amazon Elastic Compute Cloud

스팟 인스턴스 중단 스팟 인스턴스에 대한 수요는 매 순간 상당히 다를 수 있으며 스팟 인스턴스의 가용성도 사용 가능한 미사용 EC2 인스턴스의 양에 따라 상당히 달라질 수 있습니다. 스팟 인스턴스가 중단될 가능성은 항상 있습니다. 따라서 스팟 인스턴스 중단에 대비하여 애플리케이션을 준비해야 합니다. EC2 집합 또는 스팟 집합에 지정된 온디맨드 인스턴스는 중단할 수 없습니다. 중단 이유 Amazon EC2에서 스팟 인스턴스를 중단시킬 수 있는 이유는 다음

docs.aws.amazon.com

중단 이벤트뿐만 아니라 Spot인스턴스가 정지될 경우를 대비하여 buffer flush 스크립트를 daemon으로 설정할 필요가 있습니다. 자세한 내용을 제일 아래에 쓰도록 하겠습니다.

Fluentd인스톨

AmazonLinux (CentOS6)

$ curl -L https://toolbelt.treasuredata.com/sh/install-redhat-td-agent3.sh | sh

AmazonLinux2 (CentOS7)

# Amazon Linux 2
$ curl -L https://toolbelt.treasuredata.com/sh/install-amazon2-td-agent3.sh | sh

※fluentd공식document : https://docs.fluentd.org/installation/install-by-rpm

Install by RPM Package (Redhat Linux)

docs.fluentd.org

td-agent.conf 설정

<source>
  @type tail
  format /^(?<body>.*)$/
  path /var/log/httpd/*access_log,/var/log/httpd/*error_log
  pos_file /var/tmp/fluentd.tail_httpd.pos
  tag tail.httpd.*
  refresh_interval 60
  read_from_head true
</source>

<source>
  @type tail
  format /^(?<body>.*)$/
  path /var/log/messages,/var/log/secure
  pos_file /var/tmp/fluentd.tail_sys.pos
  tag tail.sys.*
  refresh_interval 60
  read_from_head true
</source>

<source>
  @type tail
  format /^(?<body>.*)$/
  path /usr/app/logs/%Y%m%d_*debug.log,/usr/app/logs/%Y%m%d_*error.log
  pos_file /var/tmp/fluentd.tail_app.pos
  tag tail.app.*
  refresh_interval 60
  read_from_head true
</source>

## httpd logs
<match tail.httpd.**>
  @type s3
  s3_region ap-northeast-2
  s3_bucket system-logs
  path httpd/${tag[5]}/
  time_slice_format %Y/%m/%d
  store_as text
  s3_object_key_format "%{path}%{time_slice}/${tag[5]}.#{Socket.gethostname}.%{index}.%{file_extension}"
  <buffer tag,time>
    @type file
    path /var/log/td-agent/buffer/httpd
    timekey 60
    timekey_wait 0
    flush_mode interval
    flush_interval 60s
    flush_at_shutdown true
  </buffer>
</match>

## sys logs
<match tail.sys.**>
  @type s3
  s3_region ap-northeast-2
  s3_bucket system-logs
  path syslog/${tag[4]}/
  time_slice_format %Y/%m/%d
  store_as text
  s3_object_key_format "%{path}%{time_slice}/${tag[4]}.#{Socket.gethostname}.%{index}.%{file_extension}"
  <buffer tag,time>
    @type file
    path /var/log/td-agent/buffer/syslog
    timekey 60
    timekey_wait 0
    flush_mode interval
    flush_interval 60s
    flush_at_shutdown true
  </buffer>
</match>

## application logs
<match tail.app.usr.app.**>
  @type s3
  s3_region ap-northeast-2
  s3_bucket app-logs
  path app/${tag[4]}/
  time_slice_format %Y/%m/%d
  store_as text
  s3_object_key_format "%{path}%{time_slice}/${tag[10]}.#{Socket.gethostname}.%{index}.%{file_extension}"
  <buffer tag,time>
    @type file
    path /var/log/td-agent/buffer/application
    timekey 60
    timekey_wait 0
    flush_mode interval
    flush_interval 60s
    flush_at_shutdown true
  </buffer>
</match>

※td-agent.conf관련 설정 공식 document

https://docs.fluentd.org/configuration

Configuration

docs.fluentd.org

td-agent start

AmazonLinux (CentOS6)

# td-agent daemon start
$ sudo /etc/init.d/td-agent start

# td-agent daemon 확인
$ sudo /etc/init.d/td-agent status

# td-agent stop
$ sudo /etc/init.d/td-agent stop

AmazonLinux2 (CentOS7)

# td-agent daemon start
$ sudo systemctl start td-agent.service

# td-agent daemon 확인
$ sudo systemctl status td-agent.service

# td-agent daemon stop
$ sudo systemctl stop td-agent.service

buffer flush 스크립트 daemon설정

daemon name : fluentd_bufferflush_daemon

#!/bin/bash
#
# Version: 0.1
#
# chkconfig: 2345 99 01
# description: fluentd_bufferflush_daemon shell
# processname: fluentd_bufferflush_daemon

SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin

# Source function library.
. /etc/init.d/functions

lock_file="/var/lock/subsys/fluentd_bufferflush_daemon"

start() {
        touch $lock_file
        #spot instance buffer flush scripts execute
        /bin/sh /home/ec2-user/fluentd_tool/spot_fluentd_buffer_flush.sh >> /var/log/td-agent/buffer_flush.log &
}

stop() {
        rm -f $lock_file
        /bin/sh /home/ec2-user/fluentd_tool/fluentd_buffer_flush.sh >> /var/log/td-agent/buffer_flush.log
}

restart() {
        stop
        start
}


case "$1" in
        start)
                start
                ;;
        stop)
                stop
                ;;
        restart)
                restart
                ;;
        *)
                echo "Usage: $0 {start|stop|restart}"
                exit 1
esac
exit 0

service daemon에 등록

Amazon linux (centos6)

# service daemon 등록
cd ~/{daemon directory}/
sudo cp -r fluentd_bufferflush_daemon /etc/init.d/
cd /etc/init.d/
sudo chmod 755 fluentd_bufferflush_daemon

# service daemon 실행/정지
service fluentd_bufferflush_daemon start
service fluentd_bufferflush_daemon stop

# 실행 정지에 문제가 없으면 인스턴스 기동시에는 가장 늦게(99) 실행되도록 인스턴스 정지시에는 가장 먼저(01) 실행되도록 등록
# chkconfig: 2345 99 01
chkconfig --add fluentd_bufferflush_daemon

Amazon linux2 (centos7)

# service daemon 등록
cd ~/{daemon directory}/
sudo cp -r fluentd_bufferflush_daemon /usr/lib/systemd/system/
cd /usr/lib/systemd/system/
sudo chmod 755 fluentd_bufferflush_daemon

# service daemon 실행/정지
sudo systemctl start fluentd_bufferflush_daemon
sudo systemctl stop fluentd_bufferflush_daemon

# 실행 정지에 문제가 없으면 인스턴스 기동시에는 가장 늦게(99) 실행되도록 인스턴스 정지시에는 가장 먼저(01) 실행되도록 등록
# chkconfig: 2345 99 01
systemctl enable fluentd_bufferflush_daemon

Buffer flush실행 스크립트

fluentd_buffer_flush.sh

#!/bin/bash

now=$(date +"%Y-%m-%d %T")
echo "[INFO] START fluentd buffer flush : $now"

# run/pid의 프로세스No로 동작하는지를 확인
TD_PID_FILE=/var/run/td-agent/td-agent.pid
TD_PID=$(cat ${TD_PID_FILE})
echo "[INFO] td-agent pid : $TD_PID"

# fluentd (or td-agent) 프로세스가 SIGUSR1 를 수신하게 되면
# 강제적으로 buffer에 담아두었던 메세지(chunk)가 flush되도록 되어 있음
sudo kill -SIGUSR1 $TD_PID

now=$(date +"%Y-%m-%d %T")
echo "[INFO] END fluentd buffer flush : $now"
exit 0

spot_fluentd_buffer_flush.sh

#!/bin/bash
now=$(date +"%Y-%m-%d %T")
echo "[INFO] START Spot fluentd buffer flush : $now"
instanceId=$(curl -s http://169.254.169.254/latest/meta-data/instance-id)

echo "[INFO] instanceId: $instanceId"
echo "[INFO] termination_time: $(curl -s http://169.254.169.254/latest/meta-data/spot/termination-time)"
while :
do
  if curl -s http://169.254.169.254/latest/meta-data/spot/termination-time | grep -q .*T.*Z; then
   /bin/sh /home/ec2-user/fluentd_tool/fluentd_buffer_flush.sh
   now=$(date +"%Y-%m-%d %T")
   echo "[INFO] STOP Spot fluentd buffer flush : $now"
   break
  fi
  sleep 5
done
exit 0

인스톨 확인

Amazonlinux (centos6)

sudo service td-agent status
grep "TD_AGENT_USER=" /etc/init.d/td-agent
grep "TD_AGENT_GROUP=" /etc/init.d/td-agent
ps -ef | grep td-agent #root로 되어 있는지 확인
grep "following tail of" /var/log/td-agent/td-agent.log

Amazonlinux (centos7)

sudo systemctl status td-agent.service
grep "TD_AGENT_USER=" /etc/init.d/td-agent
grep "TD_AGENT_GROUP=" /etc/init.d/td-agent
ps -ef | grep td-agent #root로 되어 있는지 확인
grep "following tail of" /var/log/td-agent/td-agent.log

Datadog APM인스톨 (ruby on rails)

iolle — Fri, 24 Apr 2020 17:23:06 +0900

ruby dd-trace 인스톨

datadog agent 인스톨
datadog.yaml파일 수정
datadog-agent restart
ddtrace gem file 인스톨
intializers file 만들기
unicorn restart

※amazonlinux1에서 인스톨했습니다.

※현재 대응하고 있는 ruby와 unicorn 버전은 다음에서 확인할 수 있습니다.

https://docs.datadoghq.com/ja/tracing/setup/ruby/#compatibility

Tracing Ruby Applications

Datadogが大規模なクラウドのモニタリングサービスをリードします。

docs.datadoghq.com

datadog agent 인스톨

# root 유저 
$ sudo su 

# datadog agent install
$ DD_API_KEY={datadog api key} bash -c "$(curl -L https://raw.githubusercontent.com/DataDog/datadog-agent/master/cmd/agent/install_script.sh)" 

#인스톨 확인
$ ps aux | grep agent | grep datadog

datadog.yaml파일 수정

다음 내용 추가

$ sudo view /etc/datadog-agent/datadog.yaml 
#############################
api_key: XXXXXXXXXXXXXXXXXXXXXXX # datadog agent api key
collect_ec2_tags: true           # ec2 tag 수집
process_config:                  # 호스트의 CPU, 메모리, I/O, thread수 등 프로세스의 metric 수집
 enabled: true 
apm_config:                      # apm관련 설정
 enabled: true                   # apm 수집 on
#############################

다른 플랫폼으로부터 trace data를 수신하는 경우에는

apm_non_local_traffic: true

을 추가합니다.

datadog-agent restart

datadog agent를 restart시킵니다.

$ sudo stop datadog-agent
$ sudo start datadog-agent 
$ ps -ef | grep datadog-agent

ddtrace gem file 인스톨

Gemfile에 ddtrace 추가

view {repository deploy path}/Gemfile 
################################################## 
gem 'ddtrace' 
##################################################

bundle install
※Gemfile.lock가 변경되지 않아 다음과 같이 option( --no-deployment)으로 실행

bundle install --no-deployment

initializer file作成

{repository deploy path}/config/initalizers/에 datadog-tracer.rb 파일 작성

vi {repository deploy path}/config/initializers/datadog-tracer.rb 
################################################### 
require 'ddtrace' 
Datadog.configure do |c| 
 c.use :rails, service_name: 'my app service name' 
end 
###################################################

tag env나 tag role로 설정해둔 환경변수로 service_name를 변경할 경우에는 다음과 같이 함

만약 capistrano로 deploy할 경우에는 환경변수는 /etc/enviroment에 환경변수로 설정해야지 deploy할 때에 변수를 넘길 수 있음.

export DD_SERVICE_NAME={Tag env}-{Tag role}

환경변수 값을 datadog-tracer.rb 파일에서 사용할려고 할때에는 다음과 같이 바꾸어 준다.

vi {repository deploy path}/config/initializers/datadog-tracer.rb 
################################################### 
require 'ddtrace' 
Datadog.configure do |c| 
 c.use :rails, service_name: "#{ENV['DD_SERVICE_NAME']}" 
end 
###################################################

unicorn restart

Datadog APM 인스톨(php)

iolle — Tue, 24 Mar 2020 22:17:08 +0900

php dd-trace 인스톨

datadog agent 인스톨
datadog.yaml파일 수정
datadog-agent restart
Install the PHP extension
php restart

※amazonlinux1에서 인스톨했습니다.

※현재 대응하고 있는 php 버전은 다음에서 확인할 수 있습니다.

https://docs.datadoghq.com/ja/tracing/setup/php/#compatibility

Tracing PHP Applications

Datadogが大規模なクラウドのモニタリングサービスをリードします。

docs.datadoghq.com

datadog agent 인스톨

# root 유저 
$ sudo su 

# datadog agent install
$ DD_API_KEY={datadog api key} bash -c "$(curl -L https://raw.githubusercontent.com/DataDog/datadog-agent/master/cmd/agent/install_script.sh)" 

#인스톨 확인
$ ps aux | grep agent | grep datadog

datadog.yaml파일 수정

다음 내용 추가

$ sudo view /etc/datadog-agent/datadog.yaml 
#############################
api_key: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX # datadog agent api key
collect_ec2_tags: true                    # ec2 tag 수집
process_config:                           # 호스트의 CPU, 메모리, I/O, thread수 등 프로세스의 metric 수집
 enabled: true 
apm_config:                               # apm관련 설정
 enabled: true                            # apm 수집 on
#############################

다른 플랫폼으로부터 trace data를 수신하는 경우에는

apm_non_local_traffic: true

을 추가합니다.

datadog-agent restart

datadog agent를 restart시킵니다.

$ sudo stop datadog-agent
$ sudo start datadog-agent 
$ ps -ef | grep datadog-agent

Install the PHP extension

datadog의 git repository에서 datadog-php-tracer-0.41.1-1.x86_64.rpm를 다운받아 설치합니다.

$ cd /usr/local/src 
$ sudo curl -OL https://github.com/DataDog/dd-trace-php/releases/download/0.41.1/datadog-php-tracer-0.41.1-1.x86_64.rpm 
$ sudo rpm -ivh datadog-php-tracer-0.41.1-1.x86_64.rpm

service name설정

apache를 사용하고 있다면 httpd.conf의 virtual host에서 SetEnv DD_SERVICE_NAME 을 이용하여 설정할 수 있습니다..

SetEnv DD_SERVICE_NAME 서비스명

php restart

$ sudo service httpd restart