AWS CLI 설정하기

AWS CLI 설치 및 기본적인 세팅, 명령어에 대한 기록..
AWS CLI 설치 및 기본적인 세팅, 명령어에 대한 기록..
인스턴스 접속을 끊고 나면 mysql 서버가 자동으로 종료되어 실행이 되지 않는 문제가 있었다. 프로젝트 내에서 TypeORM을 통해 mysql과 연결을 해야 하는데 서버가 꺼져있으니 연결이 되지 않아 프로젝트가 실행되지 않는 문제였다.
이 문제는 인스턴스에 연결 시 자동으로 mysql server가 자동으로 실행 되도록 설정을 해주는 방법으로 해결을 했다.
1 |
systemctl |
해당 명령어를 통해 서버 부팅 시 실행되는 프로그램들의 목록을 확인 할 수 있다. 이 목록에 mysqld를 추가해 주면 된다.
1 |
sudo systemctl enable mysqld |
다시 목록을 확인해보면 프로그램이 등록된것을 확인 할 수 있다.
프리티어로 사용중인 EC2 t2.micro에 mysql을 설치하여 구동하니 mysql이 메모리를 상당히 잡아 먹는 다는 것을 알게되었다… 자동으로 swap 영역을 지정해주지 않는 다는 것… 또한 메모리가 1GB인데 모두 사용하지 않는다는 것 이문제를 해결해보고자 swqp구성을 직접 해주었다.
1 |
dd if=/dev/zero of=/swapfile bs=1M count=1024 |
위의 명령어들은 swqp영역을 직접 할당해주는 명령어들이다. free -m 명령어를 실행해보면 swap 영역 할당 전에는 swqp영역의 메모리가 0인데 할당 시 지정 한 만큼 늘어난 것을 확인할 수 있다.
배포 단계시 무한 Pendding 상태가 지속되는 경우가 발생했다.. 그래서 또 무한 구글링…
찾아낸 해결법은 그냥 인스턴스에서 codedeploy-agent를 재실행 하라고 한다. 물론 이방법으로 해결이 안되면 다른 방법을 찾아야 겠지만 이방법으로 해결을 했다.
먼저 codedeploy-agent를 중지해준다.
1 |
sudo systemctl stop codedeploy-agent |
이후 다시 시작해주면 된다. 이렇게 간단?
1 |
sudo systemctl start codedeploy-agent |
그리고나서 다시 실행 상태를 확인해주면 끝!
이전의 과정들을 거친이후 실제로 배포가 되는지 테스트를 진행해보도록하자.
테스트 과정은 비교적 간단하다. 로컬 환경에서 작업한 코드를 깃 레파지토리에 올리기만 하면 배포가 실행될 것이다.
작업코드를 깃 레파지토리에 올리기전 실행이 되는지 테스트를 진행해준다. 코드의 내용은 간단히 인사말을 출력해주는 구성으로 진행했다.
실행결과 정삭적으로 화면에 글이 보여진다. 실행이 되는것을 확인했으니 메인 브랜치로 push를 해주면 우리가 작성한 workflow가 실행될것이다.
push를 해주고 레파지토리로 들어가 action탭으로 가면 커밋메시지의 이름으로 실행중인 워크플로우를 확인 할 수 있다.
workflow를 통해 S3에 프로젝트를 업로드하고 Codedeploy가 배포를 정상적으로 실행하는지 확인을 해보자.
새로운 배포 목록이 보이고 진행중이라는 상태를 확인할 수 있다. 해당 내용을 클릭하여 과정을 상세하게 볼 수 있으니 확인해보면 좋다. 또한 배포 실패시 에러또한 상세정보에서 확인이 가능하니 참고하면 좋을 것 같다.
상세정보 화면이다. 모든 과정이 성공적으로 완료 되었고 이제 Ec2에 내용이 있는지 실행중인지 확인 후 접속을 하면 마무리 된다.ㅠㅠ
프로젝트 디렉토리가 생겼고 내부 파일도 정상적으로 생성이 되었다. pm2 list명령어는 pm2로 실행중인 프로젝트의 목록을 확인 할 수 있는 명령어이다. 정상적으로 실행중이라는 상태가 확인이 돠었으니 접속을 하면 된다.
IPv4 퍼블릭 IP를 통해 접속을 하면 된다. 프로젝트에서 설정한 포트를추가하여 접속을 한면 정상적으로 배포가 된것을 확인 할 수 있다.
일단 처음 배포를 하고 실행해보니 정상적인 상태인 것을 확인 했다. 이제 코드 내용을 수정하여 다시 배포를 진행해서 수정사항이 반영이 되는지 테스트를 진행해보자.
과정은 위에서 진행한 내용과 똑같으니 수정 내용과 결과를 통해 확인하면 될 것 같다.
코드를 수정하고 다시 메인 브랜치로 push를 해준다. 이후 잠시 기다렸다가 다시 접속을 하여 수정사항이 반영되었는지 확인을 해보자.
수정사항까지 정상적으로 반영이 되었고 자동배포를 할 수 있게 되었다. 모든 과정을 마치고 테스트를 진행하며 겪은 수많은 실패들에 대해 해결했던 방안을 따로 정리하도록 하겠다.
모든 것이 처음부터 잘될 수는 없으니 차근차근 진행해보는 것이 정답인듯 하다. 👍
AWS의 설정을 모두 마치고 git에서 git action을 통해 자동배포를 진행해보도록 한다.
자동 배포를 진행하기위해 진행해야 하는 과정은 다음과 같다.
3가지의 과정을 하나씩 진행해보자.
지난 포스팅에서 Ec2 인스턴스에서 기본적인 환경 설정을 완료 하였고 이번에는 자동 배포를 위한 AWS 설정을 진행한다.
설정을 진행해야하는 과정은 다음과 같다.
진행해보도록 하자.
git action을 통해 ec2인스턴스에 자동으로 나의 코드를 배포하는 과정을 진행할 것이다.
우리의 서비스가 ec2에 배포를 진행하고 나면 우리의 서비스가 수정되고 새로운 기능이 생길 때마다 ec2에 접속해서 새로 빌드를 해야하는데 이러한 과정을 git action과 aws에서 대신 진행주는 서비스가 있다.
해당 과정은 개발중이거나 개발된 깃 레파지토리, Ec2인스턴스, Codedeploy, IAM Role, IAM User, S3버킷을 통해 이뤄지며 해당 과정을 순서대로 정리한 글이다.
먼저 개발중인 레파지토리를 이용할 것이며 각자의 프로젝트를 이용하거나 테스트 앱을 클론하여 진행해도 무방하다.
배포할 앱은 Node.js 기반의 서비스이고 mysql 데이터베이스를 사용할 예정이다.
aws ec2에 접속하기 위해서는 인스턴스 생성시 생성한 키페어를 통해 접속을 할 수 있다. 먼저 인스턴스를 열기 위해 터미널을 열고 생성된 키페어가 있는 디렉토리로 이동한다.
이과정에서 윈도우 cmd나 powershell이 실행이 안되는 문제가 조금 있어서 git설치시 설치된 git bash 를 통해 인스턴스로 접속했다.
접속할 인스턴스를 선택 후 연결 버튼 클릭
연결 할 때 사용할 스크립트 복사.
shell을 통해 복사한 키를 붙여넣고 접속 시 다음과 같은 화면이 나오면 성공적으로 인스턴스에 접속이 된것이다.
AWS는 아마존 닷컴의 클라우딩 컴퓨터 서비스이고 컴퓨터의 기능을 AWS를 이용해 서버 또는 컴퓨터를 구매하지 않고 이용할 수 있는 서비스이다.