IT 잡동사니

1. 증상

aws에서 ec2 인스턴스에 속한 iam을 변경하는 경우 위와 같은 문구를 만날때가 있다.
근데 찾아보면 'IAM 역할 없음' 선택 후 저장하면 된다고 하는데 그래도 위 에러가 계속 발생하는 경우가 있다.
찾아보니까 이런 경우는 aws cli로 커맨드를 직접 날려서 해결해야한다고 하더라.

2. 해결방법

1. AWS CLI 설치

아래 링크에서 설치하고 오십쇼

2. AWS CLI 로그인

aws configure 명령어를 쳐서 IAM User의 accesap-northeast-2s key와 secrert key를 입력한다.
참고로 서울의 지역은 ap-northeast-2 이다.

잘 모르겠으면 아래 링크에서 IAM User 생성과 로그인까지 나와있으니 참고.

3. AWS IAM에 EC2 권한 부여

로그인 한 IAM에 "AmazonEC2FullAccess" 권한을 부여한다.
그리고 바로 권한 갱신이 안되는 것 같으니 콘솔창 다시한번 껏다켜준다.

권한이 정상적으로 부여됐는지 확인하기 위해 현재 ec2 인스턴스들의 IAM 부여 정보를 확인하는 명령어를 쳐본다.

aws ec2 describe-iam-instance-profile-associations

대충 이런식으로 나오면 정상이다.

4. 원인 해결

아까 쳐본 정보에 본인이 문제가 생긴 인스턴스가 보일것이다.

그러면 해당 인스턴스에 물려있는 "AssociationId"를 복사한 뒤 => iip-assoc-081dffd6a9d210e5f

이를 제거하는 명령어를 쳐서 이슈를 해결해준다.

aws ec2 disassociate-iam-instance-profile --association-id iip-assoc-0813dbd78d316425b

시간이 좀 걸리면 해당 iam이 사라진다.

이후 다시 ec2 console가서 하려던거 하면 됨.

1. 개요

2. nginx 설정 파일 찾기

3. 설정법

4. 설정한 대로 에러 페이지가 안 나올 때

1. 개요

ngnix를 사용하면 위와 같이 기본 에러 발생 시 출력되는 페이지를 설정해야 한다.

주로 점검 중이라는 이미지를 올려놓는다는지...

인터넷에 올라와있긴 한데 내가 추가로 삽질한 것도 있어서 한번 쭉 정리할 겸 올려놓는다.

2. nginx 설정 파일 찾기

일단 현재 서버에서 nginx가 사용 중인 conf파일을 찾아야 한다.

기본적으로 /etc/nginx/nginx.conf 파일인데 정확한 위치를 모르겠으면 아래 참고하자

1. nginx -t 명령어를 사용한다.

2. sudo find / -name 'nginx.conf'

3. 설정법

해당 파일을 열어보면 이미 실패한 요청에 대한 처리가 정의되어 있는 경우도 있다.

error_page 404 /404.html;
	location = /404.html {
	root /usr/share/nginx/html/;
}

error_page 500 502 503 504 /50x.html;
	location = /50x.html {
	root /usr/share/nginx/html/;
}

root 부분은 따로 설정해주지 않으면 현재 서버에서 설정해놓은 root 경로에서부터 시작한다.

위 설정에서 502 에러가 발생하면 /usr/share/nginx/html/50x.html을 표출하게 된다.

4. 설정한 대로 에러 페이지가 안 나올 때

근데 나 같은 경우는 내가 만든 html로 넘어가지지 않고 계속해서 502 Bad Gateway만 나왔다.

서버 설정이 잘못됐기 때문에 발생했다.

1번의 경우는 conf 파일 내에 여러 서버에 대한 정의가 되어 있었는데 내가 작업해야 하는 서버가 아니라 다른 서버에 에러 페이지 설정을 해놔서 안 되는 것이었다.

회사 동료들도 모르고 있길래 적어둔다.

파일 디렉토리를 cop/bbs/test/test2의 구조로 폴더를 생성해야한다고 쳤을때

cop 디렉토리 만들고 들어가서 bbs 디렉토리 만들고 ...

아래 방법대로 디렉토리를 생성하면 이렇게 번거롭게 할 필요가 없다. 

만들고자 하는 디렉토리의 이름만 적지말고 하위 디렉토리 경로까지 적어주면 하위 디렉토리까지 전부다 생성해준다.

일단 aws에서 mysql로 접속해야하는데 aws에서 아래 명령어를 친다.

pager less -SFX로 쿼리결과 잘나오도록 수정 이후 유저정보 조회

select * from mysql.user;

유저 생성

create user 'ID'@'%' identified by 'PASS'

grant SELECT,INSERT,UPDATE,DELETE,DROP,CREATE on  *.* to 'ID'@'%';

grant *.*로 모든 권한을 주는 명령어도 많이 나와있는데 그러면 access denied뜬다. 그냥 위처럼 쳐주자.

ID에 계정 이름을 넣어주면 된다.

아직은 DB로 다이렉트로 접근 못하기에 ssh 터널로 접속하기위해서 ssh 터널 계정을 파도록 하자.

sudo adduser 계정이름

sudo passwd 계정이름

비밀번호 입력

su 계정이름

비밀번호

로 해당 계정으로 전환후 확인

이후 DB툴에 ssh 터널을 이용하여 로그인 확인해보기

가끔가다 무책임한 전임자때문에 아무것도 모르는 서버의 인증서 교체를 해야하는 경우가 있다.

find 명렁어를 쳐서 서버의 모든 cer파일이나 crt파일을 찾으면 그 위치를 보고 확인하면 편하다.

가끔 find 명령어를 치면 access denied때문에 결과값을 못볼때가 있으므로 아래와 같이 명령어로 검색을 한다.

find / -type f -name "*.cer" 2>&1 | grep -v "허가 거부" -> cer파일 찾기

find / -type f -name "*.crt" 2>&1 | grep -v "허가 거부" -> crt파일 찾기

이 방법으로 빠른 교체가 가능했다.

https://coderwall.com/p/j5nk9w/access-ec2-linux-box-over-ssh-without-pem-file

나같은 경우는 위 주소에서 말한

sudo /etc/init.d/ssh restart 명령어가 안먹어서

sudo service sshd restart 하니까 로그인할때 유저아이디와 비밀번호로 로그인 잘됐음

일단 aws의 rds를 접속하기 위해서는 aws의 ec2가 필요하다.

aws ec2 설정은 찾아보면 많이 나오니까 그곳에서 참고하고 pc에서 ec2 연결을 할 수있다는 가정하에 진행하겠다.

대충찾아서는 외부에서 DB에 접근하는 방식에 대해서 나오지 않는다.

즉 ec2와 db간의 연결에 대한 내용은 많이 나와있지만 내 컴퓨터에서 db를 접속하는 것은 안나와있다. (내가 안찾아봤지만 aws rds ssh tunnel connection 이라 치면 나올듯)

여튼 회사에서도 ssh 터널을 통해서 db로 접근해본적이 많아서 지금 ssh 터널을 사용하면 될 것 같다는 느낌을 받아서 몇시간 삽질을 하다가 ssh 터널을 해보았더니 잘됐다.

RDS(mysql) 생성부터 나비캣과 연결하는 과정을 설명하겠다.

aws rds mysql을 고른다.

마스터 사용자 이름과 암호는 잘 기억해두자(마스터 사용자 바꾸는 부분을 찾으면 나오긴 하겠지만 못찾았다)

VPC는 기존에 사용하던 ec2가 있다면 해당 ec2와 동일안 VPC를 골라준다(어차피 설정하긴해야함)

DB이름을 적어주고 포트는 저기서 지정해준걸로 해주자

로그 있으면 좋으니까 체크해놨다

이후 rds 인스턴스를 생성, 실행한다 약 3~4분이 걸린다.

그동안 aws의 보안그룹으로 간다.

하단의 편집을 누른다.

mysql을 선택한뒤에 소스부분도(접근할 수 있는 IP 설정) 적당히 설정해준다

그런다음 xshell에서 ec2로의 연결정보를 준비한다.

navicat에서 connection을 생성한뒤 ssh탭을 들어간다.

1~5번은 평소 ec2에 접속하는 부분과 똑같이 기입한다.

나는 pem private key로 로그인을 해서 pem키도 등록했다.

이후 general탭으로 가서

1 connection name은 나비캣에서 보여지는 접속 이름이다.

2 Host는 rds의 endpoint 주소값을 적는다.

3 port는 rds에서 포트값도 적는다

4와 5도 지정한대로 기입한다.

그다음 좌하단의 test connection을 누르면 성공적으로 접속이 되는 것을 알 수 있다.

분명 잘만되다가 갑자기 어느날부터 node 서버 키고 끄는게 급격히느려짐 키는데 4~5초걸림

근데 로컬에서는 오히려 1초안돼서 켜지고 이상하다싶어서 이것저것 뒤져보다가

아무생각없이 sudo node app.js 해보니까 개빨리됨.

결론은 node 서버 킬때 기본 ec2-user로하지말고 sudo 써서 작동시키면 매우 빠르게 시작함

(아마 처리속도 전반적으로 전부다 빨라지는것같음)

하나의 인스턴스에서 여러개의 앱을 작동시킬때는 스크린을 쓰는것이 편한것같아서 스크린을 쓰고 있다.(생각해보니까 핀란드에서 어떤 개발자는 아예 그냥 여러개의 스크린이 한화면에서 나오는 것을 쓰고있던데 찾아봐야겠다.)

스크린은 크롬의 탭같은 개념이라고 생각하면 된다.

나는 앱 3개를 돌리고 있고 추가로 db돌리는 앱, local로 mongo 접속해서 관리하는 용도로 총 5개가 있다.

지금도 매우 후회하는게 3개로 분할한 앱을 하나로 합쳐야한다.

초창기에는 오 ㄹㅇ 개잘나눈듯 이렇게 생각했지만 작업을 진행할수록 서로 겹치는 영역이 넓어지고 있어서 매우 비효율적이다. 에효... 역시 머가리가 나쁘면 사서 고생을 해요  결국 DB도 바꾸고 합쳤다. 토나왔다

아래는 자주 쓰는 screen 관련 명령어이다.

screen -S 이름 => 해당 이름으로 스크린이 생성된다.

screen -ls => 현재 생성되어있는 스크린을 확인 할 수있다.

screen -r 이름 => detached 되어있는 스크린에 attach(접속)할 수 있다.

screen -X -S 이름 kill => 스크린 삭제

screen -r -d => 스크린 강제로 detach

스크린 attach 이후 스크린 detach하는 단축키 Ctrl + a + d

위의 명령어만으로도 충분히 관리할 수 있지만

스크린을 자주 쓰다보면 두가지 문제사항이 발생한다.

알 수 없는 이유로 스크린이 attach 되어있어서 스크린에 attach 하지 못할때(이 상황은 정상적인 방법으로 스크린을 detach하지 않았을때 발생하는 것 같다 예를들자면 인터넷이 끊긴다거나 스크린에 접속한 상항에서 서버접속이 꺼진다거나)

이럴때는 screen -r -d 이름 으로 스크린을 강제로 detach 상태로 만든다. 이후 다시 -r로 attach하면 된다.

스크린을 삭제하고 싶을때 명렁어가 헷갈려서 ㄹㅇ 쓸때마다 찾아봐서 벌써 20번은 찾아본것같다 오늘 이 글을 쓴 기념으로 외워야겠다.

screen -X -S 이름 kill

사건 발단은 이렇다.

여느때처럼 노드서버 업데이트를 하기위해서 xshell로 ec2를 접속하려는데 

Connecting to ...

Connection established.

To escape to local shell, press 'Ctrl+Alt+]'.

만뜨고 접속이 안되는 것이 아닌가

회사에서 서버 렉걸리거나 할때 자주겪어본 일이라서 그냥 컨테이너 재부팅하면 되겠네 싶어서

컨테이너 인스턴스 중지, 재시작을 했다.

그리고 다시 접속하려는데 또 안되는것 아닌가

와 보니까 여태까지 IP가 유동IP라서 인스턴스 껐다키니까 IP가 바뀌어버린거임 PPAP인거임

여태까지 개발한 소스에 적혀있는 IP, db에 들어가있는 이미지 및 파일 경로(내 잘못이긴한데 거기에 http부터 .jpg까지 모든 주소가 다 들어가있음)가 전부다 무의미해져버린것이다.

어떻게든 기존에 쓰던 아이피로 돌아가려했지만 그런건 없는 것 같다.

그래서 개발자분들께 서버 IP가 바뀌었다고 말씀드리고 소스를 고쳤다.

아마존 ec2 콘솔 - 탄력적IP(elastic IP) - 새 주소 할당 - 고정 IP에 인스턴스 넣기

위 작업을 꼭 해주자

도메인이 있어서 끌어다 쓰면 상관없긴 한데, api 전용 서버라 ip가 바뀌면 나처럼 곤란한사람들은 꼭 확인하자

DB 데이터에 들어가있는 IP값들도 다 바꿨다.

다행스럽게도 서버에서는 최소한의 막장은 피하고자 connection이라는 모델파일에서 ip값을 지정하고 끌어다 쓰기 때문에 수정하는데 그렇게 오래걸리지는 않았다.

몽고 db에서는 ip 들어가는걸 다 바꾸려면 아래의 쿼리를 실행하면 된다.