진행했던 팀 프로젝트의 AWS EC2 사용기간이 만료되어 직접 프리티어로 설정을 하고 데모 버젼을 띄우기 위해 작성했습니다
AWS free tier는 첫 가입일 기준 12개월 무료로 사용 가능(제한적 용량이지만 누군가에게는 충분한 사용량!)

1. 계정 생성하기

AWS 홈페이지

회원가입시 - 카드 정보, 전화번호 인증 필요

AWS 홈페이지에서 우상단의 회원가입 버튼을 누르고 안내에 따라 입력하면 회원가입 가능

(모바일 인증 등의 과정이 여기서 필요)

2. 인스턴스 생성

인스턴스는 가상 서버를 의미한다

2-1. 지역 선택

아마존 웹 서비스의 서버의 위치 결정(서버의 위치와 서비스 대상의 위치가 가까울수록 속도가 빠르다)

단, 지역별로 가격이 다르기 떄문에 살펴볼 필요가 있음

2-2. AMI 선택

Amazon Machine Image는 인스턴스를 시작하는데 필요한 SW 구성 템플릿
즉, 컴퓨터 운영체제를 설치하는 것과 비슷하다고 이해하면 될 것 같다

해당 부분에서 프리티어 등급이 사용 가능한 AMI인지 확인하고 필요한 AMI를 설치하기

2-3. 인스턴스 유형 선택

2-4. 인스턴스 세부정보 구성

필요한 부분에 대해 수정을 통해 변경하기

가장 기본인 default 설정 그대로 진행

2-5. 스토리지 추가

2-6. 태그 추가

인스턴스 관리를 위한 태그를 지정가능

키-값으로 구성

구분을 위해 기본 태그(Name 등)는 구성해주면 편리

참고 - 태그 사용 가이드

2-7. 보안 그룹 구성

일반 사용자 접근 HTTP(S)는 IP 위치 무관으로 설정하고 보안을 위해 22번 포트는 내 IP로 설정

프론트엔드 포트 번호도 열어주게 설정

• 시큐어 셸(Secure SHell, SSH)은 네트워크 상의 다른 컴퓨터에 로그인하거나 원격 시스템에서 명령을 실행하고 다른 시스템으로 파일을 복사할 수 있도록 해 주는 응용 프로그램 또는 그 프로토콜을 가리킨다. 기존의 rsh, rlogin, 텔넷 등을 대체하기 위해 설계되었으며, 강력한 인증 방법 및 안전하지 못한 네트워크에서 안전하게 통신을 할 수 있는 기능을 제공한다. 기본적으로는 22번 포트를 사용한다.

  출처: 나무위키

2-8. 인스턴스 시작 검토

기존에 설정한 항목들을 확인한 다음 시작하기 버튼 클릭

2-9. 키페어 생성

키페어를 생성을 통해 만들어진 .pem파일 보관

해당 .pem 파일은 재다운로드가 어렵기 때문에 잘 보관하기

2-10. 인스턴스 생성 완료

인스턴스 보기를 통해 인스턴스가 작동중인 모습을 확인할 수 있음

3. 탄력적 IP 주소 사용

기본적으로 EC2 인스턴스를 생성해서 서버를 구동시키면 고정 IP가 아니다

탄력적 IP를 통해 고정 IP를 할당 받아서 사용할 필요가 있다

그렇지 않으면 인스턴스를 중지하고 다시 실행시키면 IP가 변경된다!

탄력적 IP는 만들어 놓고 사용하지 않으면 과금이 되기 때문에 필요한만큼 생성하여 바로 사용

인스턴스에 연결되어 있더라도 인스턴스가 멈춰있으면 요금 청구

실행 중인 인스턴스에 연결된 IP주소 한 개는 무료로 사용

위의 그림에서 작업 부분 드롭 다운을 누르면 탄력적 IP 주소 릴리즈 버튼을 누르면 해당 EIP를 삭제할 수 있다!

4. ssh 사용 연결

인스턴스 연결을 클릭하고 22번 포트 개방 여부 확인 후 주어진 스텝으로 진행

(추가 사항) 사용량 결제 알림 받기

EC2를 사용하다 보면 커뮤니티에서 심심찮게 볼 수 있는 내용이 예상치 않은 과금으로 인해 고통 받는 사람들이었다. 걱정이 많은 나였기에 사용량 제한하는 방법을 찾아보고 제한은 없으나 알람을 받을 수 있는 방법까지 공유하려고 한다

1. 내 결제 대시보드 이동

우상단의 내 계정 정보 드롭다운을 클릭하면 나오는 내 결제 대시보드 클릭

2. 결제 기본 정보 설정

1. 프리티어 사용량 알림 활성화를 통해 이메일로 사용량 확인 가능
2. 결제 알림을 통해 특정 기준에 따라 결제 알림을 받게 설정 가능

(추가 설정) 요금 알람 받기

해당 부분은 프리티어 이상의 요금을 사용할 때(example. 20$ 기준으로 설정하고 싶다!) 외에도 트래픽, API 사용량 등 점검하고 싶은 내용을 모두 체크할 수 있는 부분이지만 기본적인 요금 설정 방법을 작성하겠습니다. EC2의 경우 기본적인 프리 티어 한도 내에서 실행가능

참고자료: AWS CloudWatch를 통한 예상 요금 모니터링

위의 참고 자료를 보고 스텝을 따라가면 된다!

CloudWatch 요금 설명

1. CloudWatch console 실행

   

   결제 지표는 버지니아 북부에서 선택 가능(전 세계 요금 반영)

2. 경보 > 경보 생성 선택

   

3. 지표 선택 > 결제 > 예상 요금 합계 선택

   해당 부분에서 결제 또는 예상 요금 지표가 활성화되지 않으면

   1. 결제 경보 활성화 여부 확인
   2. 지역 확인(버지니아 북부)

4. 예상 요금 지표 활성화 > 지표 선택

   

5. 조건 설정(임계값)

   원하는 조건에 맞게 시간, 조건 등 설정

   

   화면 예시는 20$ 이상일 때 알람 전송

6. 알림을 추가하여 알림 전송 대상 선택

   

7. 이름 및 설명을 추가하고 알림 확인

   

8. 구독 여부 확인해줘야 정상적으로 메시지 수신 가능(이메일로 확인)

   

참고 자료

• 호토론 블로그
• 참고자료: AWS CloudWatch를 통한 예상 요금 모니터링

git 대용량 파일 올리기

원인

1. 하나의 파일 용량이 100mb 이상일 때는 push가 되지 않는다
2. 커밋 이력 중에 100mb 이상인 파일이 올라간 이력이 있으면 올라가지 않는다

자율 프로젝트의 경우 frontend/android/java_pid22576.hprof 이 파일 업로드 로그가 문제인 것으로 보임

용량 400mb 넘었던 그 파일 - 이게 sdk 버전이 안 맞아서 생기는 메모리 누수 경고? 그런 문제였던 거 같은데 해당 부분은 더 찾아봐야할 듯

process

1. error 확인

   1	$ git push origin master

   1 2 3 4 5 6 7 8 9 10 11 12 13 14

   Enumerating objects: 3218, done. Counting objects: 100% (3218/3218), done. Delta compression using up to 12 threads Compressing objects: 100% (1199/1199), done. Writing objects: 100% (3218/3218), 159.51 MiB | 1.90 MiB/s, done. Total 3218 (delta 1705), reused 3215 (delta 1703), pack-reused 0 remote: Resolving deltas: 100% (1705/1705), done. remote: error: GH001: Large files detected. You may want to try Git Large File Storage - https://git-lfs.github.com. remote: error: Trace: 09bb81948ab6fa06b710474f8fca70c1224fb799c7f56f1878e10774c88307d6 remote: error: See http://git.io/iEPt8g for more information. remote: error: File frontend/android/java_pid22576.hprof is 434.09 MB; this exceeds GitHub's file size limit of 100.00 MB To https://github.com/qsoo/test.git ! [remote rejected] master -> master (pre-receive hook declined) error: failed to push some refs to 'https://github.com/qsoo/test.git'

2. bfg-repo 들어가서 우측의 jar 파일 다운로드

   • 해당 다운로드한 파일을 git push할 지점으로 이동시킨다

     1 2 3 4 5 6 7

     example) .git/ backend/ client/ frontend/ bfg-1.14.0.jar README.md

3. 대용량 파일 삭제 및 로그 기록 삭제

   1 2 3 4 5 6

   $ java -jar bfg.jar --strip-blobs-bigger-than 100M # bfg.jar 자리에 해당 다운로드 받은 버전에 맞는 파일명 써넣기 # example $ java -jar bfg-1.14.0.jar --strip-blobs-bigger-than 100M

4. 삭제된 로그 및 파일들의 이력을 바탕으로 가지치기 실시

   1 2	# 3번 명령어가 끝나면 친절하게 run 뒤에 명령어 안내해줍니다 $ git reflog expire --expire=now --all && git gc --prune=now --aggressive

5. 대용량 파일 없는지 확인

   1 2	# 100mb 이상 파일 확인 $ find . -type f -size +100M

6. 정상적으로 작동했으면 push commit 새로 해서 실시(mirror도 동일)

window 개발환경을 기준으로 ssh config 설정을 통해 간편하게 접속하기

1. windows ssh

1. 윈도우 앱 및 기능 클릭

2. 선택적 기능 관리 클릭

3. 기능 추가 OpenSSH Client추가

4. 재부팅

5. bash or cmd에서

   1

   $ ssh

   입력했을 경우 help option이 뜨면 사용 가능 상태

참고자료

2. ssh config

1. cmd or bash 창에서 바로 접속 가능

   1 2 3

   $ ssh -i [keyfile] [User]@[HostName] # -i option: identity_file(인증에 필요한 키 파일을 참조케)

2. 불편하니 configuration을 등록해서 alias처럼 사용하자(keyfile까지 등록해서)

   1. .ssh directory로 이동

      1 2 3 4 5 6 7 8 9

      # 일반적으로 root 위치의 바로 아래 있음(User 내의 현재 window 접속 위치) $ cd ~/.ssh # 없다면 디렉토리 만들어주기 $ cd ~ $ mkdir .ssh # 해당 위치에서 config 파일 만들기 $ vim config

   2. config 파일 작성하기

      1 2 3 4

      Host [사용할 서버 이름] HostName [위의 호스트 이름이 매핑되는 실제 호스트 명] User [사용자명] IdentityFile [Keyfile]

   3. 작성 후 저장한 다음 실행하기

      1 2 3 4

      # 적용 가능 $ ssh my_server # ssh 처음 접속 시 나오는 known_hosts yes 입력 >> 접속했던 host 목록 .ssh 안에 만들어짐

참고자료

Hexo로 글쓰기

Hexo 세팅은 Hexo로 github page 구축하기(1)을 살펴보고 오시면 좋습니다.

이번에는 이어서 Hexo로 포스팅하는 방법을 기록하려고 합니다.

기본적인 글쓰기

1
2

# layout default는 post
$ hexo new {layout} {글제목}

layout

• post
• draft
• page

1. post

2. draft

초안으로 작성된 글은 로컬서버에서만 확인 가능

1
2
3
4
5

# draft 글 확인
$ hexo server --draft

# publish
$ hexo publish {글제목}

마지막으로

1
2
3
4
5

# 배포
$ hexo deploy

# 포스트 적용이 되지 않을 때
$ hexo clean

참고 자료

Mishka’s BLOG

들어가기에 앞서

처음에는 hexo라는 프레임워크를 알지 못했기 때문에 jekyll을 이용해서 블로그를 구축하려고 하였습니다. 그래서 흐름상 왜 바꾸게 되었는지 등을 알기 쉽게(저와 같은 문제를 겪는 분들에게 도움이 되고자)
jekyll을 설치하면서 만났던 문제와 hexo 설치까지로 구성하였음을 밝힙니다.

• github를 사용하기 위한 아이디
• ruby
• jekyll

위와 같은 설치가 필요합니다

1. 맘에 드는 테마를 가져와서 내 repository에 fork 해오기

1

참고: [TheoryDB]: ([https://github.com/theorydb/theorydb.github.io](https://github.com/theorydb/theorydb.github.io))

2. fork해 온 테마를 이용하기 위해 <username>.github.io 로 이름을 변경해준 뒤 로컬 환경에 pull 해주기

3. vs code로 해당 디렉토리에서 열기!

4. jekyll 설치를 위한 명령어를 입력해준다(터미널)

1
2
3
4
5
6
7
8
9
10

# gem 관리를 위한 bundler 설치하기
$ gem install jekyll bundler   

# gemfile에 저장된 gem들 설치
$ bundle install

# jekyll과 종속된 필요한 라이브러리 설치
$ gem install bundler jekyll minima jekyll-feed tzinfo-data rdiscount

# 위의 명령어는 왜 해주는지 확인 필요하다 why를 모르겠다

참고

gem: 라이브러리의 개념과 같다고 생각하면 된다

gemfile: requirements.txt처럼 필요한 gem(라이브러리)들을 등록하는 파일(txt)

bundler: gemfile에 정의된 gem들의 의존성을 파악해서 올바른 gem을 사용할 수 있게끔 해주는 명령어

문제 발생 1

fork해 온 repository의 bundle과 gem들의 버젼이 달라서 충돌 발생 (jekyll을 비롯한 종속된 라이브러리들의 버젼이 다르기 때문에 서버도 안 켜지고 초기화도 안되는 문제발생

jekyll new PATH : 지정된 경로에 기본 젬-기반 테마로 새 jekyll 사이트를 생성(필요한 경우 디렉토리 생성)

해당 명령어를 입력했을 때 i18n 의 버젼이 충돌하는 문제 발생

gemfile.lock에 있는 버젼들을 지워주고 현재 내 로컬 환경내에 있는 gem들로 버젼을 변경하여 실행해봤지만 계속해서 에러가 발생

결국 초기화 설정을 통해 새로운 페이지를 만들 수 있게 파일구조를 바꿨고 기존의 파일들을 지우고 대체하는 방식으로 하니 적용이 되었다.

찾다보니 jekyll뿐만 아니라 다양한 static framework(hugo, hexo 등)을 통해 github page를 호스팅할 수 있다는 것을 발견했다.

결론적으로 말하면 javascripts 공부를 이어서 해나가기 때문에 node.js 기반인 hexo를 통해 github 블로그를 구현하는게 나에게 더 도움이 될 거라 생각했다.

1217부터 hexo 설치

1. 개발환경 구성

1
2
3
4
5
6
7
8
9
10
11

# 전역에 hexo를 설치
$ npm install hexo-cli -g

# 해당 디렉토리(로컬) 이동한 다음 hexo 초기 설정
$ hexo init

# node modules 설치
$ npm install

# 서버 구동
$ hexo server

2. 테마 적용 - icarus 테마 사용

1. icarus 저장소에서 코드를 다운 받아서 theme 디렉토리 안으로 이동

ppoffice/hexo-theme-icarus

2. _config.yml 에서 사용하는 테마 변경 ⇒ theme 디렉토리 안에 있는 디렉토리명으로 사용

3. 서버 구동시 에러 발생 ⇒ 필요 패키지가 부족하기 때문

• ERROR 코드에서 필요한 패키지를 bash창에 입력해서 설치

Issue 발생

⇒ 서버를 구동하면 순환 종속성이 발생하여 warning message 발생

1
2
3
4
5
6
7

(node:20880) Warning: Accessing non-existent property 'lineno' of module exports inside circular dependency
(Use `node --trace-warnings ...` to show where the warning was created)
(node:20880) Warning: Accessing non-existent property 'column' of module exports inside circular dependency
(node:20880) Warning: Accessing non-existent property 'filename' of module exports inside circular dependency
(node:20880) Warning: Accessing non-existent property 'lineno' of module exports inside circular dependency
(node:20880) Warning: Accessing non-existent property 'column' of module exports inside circular dependency
(node:20880) Warning: Accessing non-existent property 'filename' of module exports inside circular dependency

구글링 결과 stylus가 노드 v14와 호환이 안되서 생기는 오류로 추정

⇒ 최신 버젼에서는 문제가 해결되었다는데 버젼을 설치해도 해결이 되지 않음

solution 1

pakage.json 모듈들을 최신 버젼으로 업데이트한 다음 설치하는 방법으로 진행

npm-check-updates 를 이용해서 최신버젼으로 변경키로

1

$ npm install -g npm-ckeck-updates

⇒ 계속 에러 발생

solution 2

구글링 결과 전체적으로 순환 의존성 문제가 발생하는 지점을 확인하니 stylus 패키지에서 발생하는 부분으로 확인

⇒ 최신 버젼의 stylus 패키지의 경우 이를 해결하였고 이는 최신 버젼 HEXO에서는 마찬가지로 문제 해결 되었음 (V4.1 이상의 경우)

하지만 계속해서 문제가 발생해서 포기할 쯔음(annoying but work 부분이기 때문에) 구글링으로 문제 해결 방법 찾음!

1
2

# target에서 발생하는 에러에 대해 자세한 추적 가능
$ node --trace-warnings <target>

이를 통해 node_modules에 있는 stylus/lib/nodes/index.js

1
2
3
4
5
6
7
8
9
10

// node_modules/stylus/lib/nodes/index.js

exports.lineno = null;
exports.column = null;
exports.filename = null;

/*
해당 코드가 있는지 확인! 
있다면 stylus는 내부 순환 참조 문제를 일으키지 않는다
*/

1
2
3
4
5
6
7
8

# 문제 발생 지점 확인
$ node --trace-warnings node_modules/nib

=> Warning: Accessing non-existent property 'lineno' of module exports inside circular dependency

# 여기서 내부 순환 참조 문제 발생하는 것 확인 

# 즉, nib에서 참조하는 stylus 패키지는 구버젼이 적용되어서 발생하는 문제

(trouble shooting)

1

# node_modules/nib/node_modules/stylus/lib/nodes/index.js

위의 파일을 확인해보면 위와 같은 순환 참조문제 해결하는 코드가 없는 것을 확인할 수 있다(v0.54.5 인 것을 확인 가능)

이를 추가해주면 문제해결!

1
2
3
4
5
6
7
8
9
10

// node_modules/nib/node_modules/stylus/lib/nodes/index.js

exports.lineno = null;
exports.column = null;
exports.filename = null;

/*
해당 코드가 있는지 확인! 
있다면 stylus는 내부 순환 참조 문제를 일으키지 않는다
*/

잘 작동한다!

[참고링크]

NodeJS 14 warnings · Issue #2534 · stylus/stylus

3. github page에 배포하기

• github repo를 만들어서 사용자계정.github.io 로 이름을 만들어 줍니다.
• 이를 연결하기 위해 저장소 주소와 연결

1
2
3
4
5

#_config.yml
deploy:
  type: git
  repo: https://github.com/qsoo/qsoo.github.io
  branch: master

• 배포 플러그인 설치

1
2
3
4
5
6
7
8

# git에 배포하기 위해 필요한 플러그인
$ npm install hexo-deployer-git

# 정적 리소스 배포
$ hexo deploy

# 정적 리소스 삭제
$ hexo clean

(소스를 저장해서 github 커밋을 관리하고 싶다면 따로 소스코드 저장소를 만들어줘야 한다)

⇒ hexo deploy 를 통해 업데이트시 커밋 이력이 찍히지 않아서 나중에 관리하기 어려울수도 있고 중간 작성으로 저장하고 싶다면 따로 저장소를 만들어서 저장하기!

github를 이용한 공동 작업을 어떤 식으로 진행하면 되는지 간단히 정리한 부분

기본적으로 같은 파일을 수정하지 않으면 충돌이 발생하는 일이 없기 때문에 수월하게 작동합니다. 이 외에 상황에 대한 서술입니다.

1. 상대가 작업한 내용을 merge해서 master에 변경이 있을 때

1. 내가 작업 중이지 않는 상황

1
2
3
4
5
6
7
8
9
10
11
12

# 여기서 주의해야할 점은 브런치(frontend)가 이미 만들어진 다음 pull을 하게되면 master와
# frontend가 파일 구조가 달라집니다!

# 먼저 서버에서 변경된 자료를 받아옵니다.
$ git pull origin master

# 그 다음 브런치를 만들어 줍니다.
# (master에서 파일을 다 받은 다음 만들어 주면 브런내에서도 파일 구조가 동일합니다.)
$ git branch frontend

# 해당 브런치로 이동 후 작업합니다!
$ git switch frontend

2. 내가 작업 중인 상황

1
2
3
4

굳이 중간에 pull을 받을 필요가 없습니다.
만약 중요한 변경으로 인해 필요할 때는 서로 커뮤니케이션을 통해 상황을 해결합니다.
작업을 완료한 후 내 브런치로 push를 하고 파일 변경사항 이력을 확인해서 merge request 실시
만약 문제 발생시 커뮤니케이션합니다.

2. 내가 작업한 다음 push할 때

전체적인 진행 코드입니다.

1
2
3
4
5
6
7
8
9
10
11
12

# 현재 bash창(terminal)을 확인했을 때 frontend인 시점에서 서술

# 필요한 파일 stage에 올리기
$ git add .
# 특정 파일을 올린 뒤 commit을 해서 commit 메세지를 세분화할 수 있습니다! -변경 많을 때
$ git add <특정파일 이름>

# commit 메세지 작성(자세히)
$ git commit -m "Modify base.html nav-bar"

# 해당 브런치 이름으로 push
$ git push origin frontend

여기부터는 서버에서 진행할 부분입니다.

1
2
3
4
5
6

1. repo에서 내 브런치로 들어간 다음 코드가 잘 올라갔는지 확인한다.
2. 이상이 없다면 pull request 탭에 들어가서 요청을 보낸다
3. merge하기에도 이상이 없다면 merge까지 해준다
	*여기서 이상이 있거나 헷갈리는 부분이 있다면 상대방에게 조언을 구합니다!
4. 머지가 완료되었다면 브런치를 볼 수 있는 드롭다운에서 view all branchs를 click
5. merge가 완료되었다는 표시가 나왔다면 해당 브런치를 삭제해줍니다.

다시 로컬환경으로 돌아옵니다

이하의 부분은 다시 프로젝트 작업을 하기 위해서 현재 가지고 있는 브런치를 삭제해주고 변경된 마스터 데이터를 로컬로 가져오는 부분입니다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

# 1.기존의 branch 제거
$ git switch master

# (optional) branch 목록 확인
$ git branch

# 마스터로 이동됨을 확인했다면 이전의 브런치 삭제
$ git branch -D fronted

# --------- 해당부분까지 브런치 삭제 부분 -------

# 2. 새로운 코드 받아오기

# 코드 가져오기 - 현재 위치는 마스터입니다.
$ git pull origin master

# 변경된 부분 가져와졌는지 확인

# 새로 작업할 브런치를 만들고 이동
$ git branch frontend

$ git switch frontend

# (optional) 정상작동하였다면 현재 변경된 파일이 브런치내에도 마스터와 동일!
$ git pull origin master
# [output] already-up-to-date

# 작업 다시 시작!

추가로 알아두면 좋은 부분

아직 사용이 서툴기 때문에 파일 백업을 다른데에 하는 것을 까먹지 않도록 합니다!

git status로 현재 상태를 확인하는 것을 습관화합니다.

git log --oneline를 통해 변경 이력(commit)을 확인할 수 있습니다.