일단 구글 애널리틱스 붙히고 경과를 살펴 보았다
이렇게 페이지별 조회수가 나오는걸 확인 할 수 있는데 활성사용자나 조회수등을 확인 할 수 있었다.
이거 말고도 api로도 불러오기를 해야하고 유입경로를 파악할 수 있어야 하는데
이전 자료들이랑 너무 달라서 보니까 아래 라이브러리에서 직접 메뉴를 만들어야 되는 것 같다..
그리고 database 서버를 위한 ec2를 만들었다. rds쓰기엔 너무 비싸기도 하고 그렇게 데이터베이스가 많이 필요할 것 같지도 않다. 구조를 위한 거는 파이어베이스를 쓸거고 내용을 위한 거는 notion을 쓸거다 ec2에 저장하는건 cache용으로 중요하지 않은것들을 저장할 생각이다. 아무래도 꺼질 수도 있고 하니까...
일단은 여러가지로 시도를 해봤는데,
1. database서버와 api서버가 다른 보안 규칙을 가져야 된다는 점,, (보안문제)
2. api 서버가 내부아이피로 database서버와 연결되면 좋겠다는 점,, (속도문제)
3. database서버가 api서버 이외의 ip에서 요청을 받으면 안된다는 점,, (보안문제)
이 세가지가 아직 해결이 안됐다. 보안 규칙바꾸는게 왜케 힘든지 사실 뭐 보안규칙은 다열어놓고 방화벽만 해놓으면 될거같긴한데 내일 my.conf 파일 고쳐서 특정아이피만 요청을 받게 해야겠다.
일단 한번 jdbc로 연결이 되면 이후 방화벽이 쳐져도 상관없는거 같으니까 sh파일과 actions 파일을 수정해서 연결한 뒤에 방화벽을 쳐주는 방식으로 진행해도 괜찮을 거 같다. heidi로 다른 아이피에서 연결이 되는지 아닌지 확인해보니까 그렇다.
그리고 보니까 github actions가 작동하는 가상피시에서 빌드가 이루어져서 그래서 방화벽으로 내 ec2를 허용해줘도 빌드가 안되서 오류가 생기는거 같다. 이거 할 수 있는 방법은 빌드 하기전에는 방화벽을 잠깐 열어서 빌드를 시키고 빌드 시킨 후에는 방화벽을 닫는 방법이 최선인거 같다. 그렇게 하면 모든 문제가 해결될 거 같다.
일단 명령어는 이렇다
sudo iptables -D INPUT 1
sudo iptables -I INPUT 1 -p tcp --dport 3306 -j ACCEPT
sudo iptables -L --line-numbers이걸 github actions 파일에서 강제로 ec2에서 실행시켜가지고 썻다지웠다를 하면 될거같다. 왜냐하면 일단 연결 되면 방화벽이 그 이후 생겨도 상관없는 거같기 때문
일단 api서버에 대한 방화벽을 허물고, 배포를 시작할 떄 전체 ip에대한 데이터베이스서버의 방화벽을 풀고 빌드를 한다음 빌드가 완료되면 다시 방화벽을 만들었다. 이렇게 하니까 된다. 그리고 빌드가 실패하더라도 풀어둔 방화벽을 다시 만드는 작업을 해뒀다.