많은 개발자들이 github에 기존 서버의 변경사항을 저장할 것입니다. 만약 배포 자동화가 없다면 서버에 원격접속하여 github를 다시 내려받고 서버를 중단한 뒤 다시 빌드하여 서버를 구동해야 하는 번거로움이 있습니다. 하지만 배포 자동화를 이용하면 일일이 개발자가 부가적인 행위를 할 필요 없이 기존의 웹 애플리케이션을 업데이트 후 깃에 push만 한다면 해당 github와 연결되어 있는 서버는 자동으로 업데이트를 수행합니다.
배포에서 파이프라인이란 여러 단계를 순차적으로, 또 단계별로 독립적으로 수행하는 구조를 의미합니다. 여러 단계들이 있으며 축소하거나 구체화하여 분리시킬 수 있습니다.
AWS는 효율적인 서버 관리를 위해 여러 개발자 도구들을 제공하고 해당 개발자 도구를 활용하면 편리하게 서버를 관리할 수 있습니다.
CodeCommit
: GitHub와 유사한 서비스를 제공합니다. 원격 레포지토리로써의 역할을 수행하지만, 보안과 관련된 기능이 더욱 우수하고 요금이 좀 더 부과될 수 있습니다. 보안여부에 따라 고려할 만한 선택지 입니다.CodeBuild
: 유닛테스트, 컴파일, 빌드와 같은 필수적인 명령들을 실행합니다.CodeDeploy
: 서버에 존재하는 애플리케이션에 실시간으로 변경 사항을 전달할 수 있습니다.CodePipeLine
: 각 단계를 연결하는 파이프라인을 구축할때 이용합니다.EC2인스턴스에 자동 배포화를 적용하기 위해선 2가지 설치 작업이 필요합니다.
curl "https://awscli.amazoneaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
sudo apt install unzip
unzip awscliv2.zip
sudo ./aws/install
AWS CLI
를 설치합니다.
aws --version
AWS CLI 설치 여부를 확인합니다. aws-cli/2.1.39 Python/3.8.8 Darwin/20.4.0 exe/x86_64 prompt/o
식으로 출력된다면 성공적으로 설치가 완료되었습니다.
sudo apt update
sudo apt install ruby-full
sudo apt install wget
cd /home/ubuntu
sudo wget https://aws-codedeploy-ap-northeast-2.s3.ap-northeast-2.amazonaws.com/latest/instal
sudo chmod +x ./install
sudo ./install auto > /tmp/logfile
EC2인스턴스에 CodeDeploy Agent
를 설치합니다.
sudo service codedeploy-agent status
active(running)
이 출력되면 정상 설치 되어 실행중입니다.
version: 0.0
os: linux
files:
- source: /
destination: /home/ubuntu/build
hooks:
BeforeInstall:
- location: server_clear.sh
timeout: 3000
runas: root
AfterInstall:
- location: initialize.sh
timeout: 3000
runas: root
ApplicationStart:
- location: server_start.sh
timeout: 3000
runas: root
ApplicationStop:
- location: server_stop.sh
timeout: 3000
runas: root
version
: appspec.yml
의 버전을 나타냅니다.os
: EC2 인스턴스의 OS를 지정합니다.files
: source
는 파일의 위치를 나타내고 destination
은 목적지를 지정합니다.hooks
: 라이프 사이클별 실행할 목록입니다.BeforeInstall
: 설치 전 실행할 파일을 지정합니다.AfterInstall
: 설치 후 실행할 파일을 지정합니다.ApplicationStart
: 앱 실행 시 실행할 파일을 지정합니다.ApplicationStop
: 앱 종료 시 실행할 파일을 지정합니다.location
: 파일을 가리킵니다.timeout
: 제한시간을 지정합니다.runas
: 읽기 및 실행 권한을 부여합니다. 값이 root라면 root에 해당하는 읽기 및 실행 권한을 가집니다.version: 0.2
phases:
install:
runtime-versions:
java: corretto11
build:
commands:
- echo Build Starting on `date`
- cd DeployServer
- chmod +x ./gradlew
- ./gradlew build
post_build:
commands:
- echo $(basename ./DeployServer/build/libs/*.jar)
artifacts:
files:
- DeployServer/build/libs/*.jar
- DeployServer/scripts/**
- DeployServer/appspec.yml
discard-paths: yes
공식문서 https://docs.aws.amazon.com/ko_kr/codebuild/latest/userguide/build-spec-ref.html#build-spec.run-as
#!/usr/bin/env bash
chmod +x /home/ubuntu/build/**
#!/usr/bin/env bash
rm -rf /home/ubuntu/build
#!/usr/bin/env bash
cd /home/ubuntu/build
sudo nohup java -jar DeployServer-0.0.1-SNAPSHOT.jar > /dev/null 2> /dev/null < /dev/null &
#!/usr/bin/env bash
sudo pkill -f 'java -jar'
아마존 기관에서 여러명에서 사용중인
AMI
계정 특성상, 내용이 노출 되도록 직접 블로깅 할수 없는 점 알려드립니다.
cd /opt/codedeploy-agent/deployment-root/deployment-logs
sudo cat codedeploy-agent-deployments.log
실행 시 배포 자동화의 로그를 확인할 수 있습니다.
환경변수는 보안과 관련하여 매우 중요합니다. 리소스(ex db)에 접근하기 위해서는 리소스에서 인증을 수행할 일정한 값들이 필요합니다. 프로젝트에 환경변수가 그대로 저장되어 있다면 제 3자가 해당 값들을 악용할 가능성이 매우 큽니다. 따라서 보안과 관련해 중요한 환경변수는 다른 곳에 저장해 단순히 읽어와야 합니다.
dependencies{
implementation 'org.springframework.cloud:spring-cloud-starter-aws-parameter-store-config'
...
}
dependencyManagement{
imports{
mavenBom "org.springframework.cloud:spring-cloud-starter-parent:Hoxton.SR12"
}
}
aws:
paramstore:
enabled: true
prefix: 접두어
name: 파라미터묶음_명
profileSeperator: _
AWS에서 Parameter Store 서비스를 이용합니다. 파라미터 생성시 이름은 접두어/파라미터묶음_명/파라미터
로 파라미터 이름을 지정합니다. 값에는 파라미터 값을 입력하면 간편하게 프로젝트가 아닌 AWS에서 환경변수를 관리 할 수 있어 훨씬 보안에 유리하게 됩니다.
AWS클라우드에 서버 배포 후 유지관리를 위한 배포 자동화와 서버 환경 변수 설정을 익혔습니다. 추가적인 작업을 줄이고 보안은 강화할 수 있는 좋은 방법입니다.
없음!