AWS EC2를 사용하다가 보면 알 수 없는 이유로 서버에 접속이 불가능 해지는 경우가 종종 있다. 나의 경우는 지금까지 두가지 케이스를 경험했는데, 1. public key 가 변조되어 접속할 수 없음. 2. port 22가 닫혀있음. 잘 사용해왔고, 정상접근이 어제까지만 해도 가능했던 서버였는데 갑자기 이런 경우가 발생할 수 있다. 접근권한을 잃게 된 서버에 대해서는 AWS에서 해결방법이 딱히 없다. 아마 free-tier나 고객지원 서비스를 사용하지 않는 경우에는 그런 것 같다. 나의 경우에는 현재 free-tier를 사용하고 있기 때문에, 내가 가이드를 읽고 문제 해결을 하였다. 1번의 경우는 해킹으로 의심되는 사항으로 나의 ssh key가 변조되어 서버 접근권한을 잃은 경우였다. 그때도 2번의 ..

그렇다. 맹세코 아-무것도 수정하지 않았는데 어느날 부터 배포신호에 빨간불이 들어오기 시작했다. 이유를 찾을 수가 없었다. .travis.yml 파일은 배포설정 초기에 만진것 이외에는 사실 고칠일이 전혀 없는 파일이기 때문이다. 문제 해결 시도 -> travis-ci 문의 예전에도 비슷한 장애?경험을 한 지라 망설이지 않고 바로 travis-ci customer support에 문의를 보냈다. 그들은 언제나 그랬듯 친절하게 대답해줬다. v2를 사용하기 위해서는 edge:true 프로퍼티를 추가해서 다시 빌드를 돌려봐 달라는 대답이 왔다. 여기서 말하는 v2란, 현재 글을 쓰는 시점에는 major release로 나가지 않은 버전이다. (참고: https://docs.travis-ci.com/user/de..

[ec2-user@### apps]$ rm filebeat-7.3.0-x86_64.rpm -bash: rm: command not found [ec2-user@### apps]$ echo $PATH /usr/local/bin:/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/sbin:/opt/aws/bin:/home/ec2-user/.local/bin:/home/ec2-user/bin 무슨 이유에서 인지 aws ec2서버에서 rm command가 없다는 것을 알게 되었다. 띄워진 instance의 OS는 CentOS. 아래의 command를 실행하면 coreutils에서 빠진 것을 리스트 해준다. [ec2-user@### travis]$ rpm -V coreutils missing..

소나큐브란? CI = continuous inspection 툴. 정적분석. 어떤 지표들이 있는가? Bug 잘못된 코드 또는 개발자의 의도대로 동작하지 않을 코드를 표시. Code Smells (=구린 코드) 정상동작은 하나 유지보수 하기 힘든 코드를 표시. ex) 중복코드, 너무 복잡한 코드, unit test에 포함되지 않은 코드 Security Vulnerability 보안에 취약한 코드를 표시. ex) SQL Injection, hard-coded 비밀번호, 제대로 핸들링 되지 않은 에러 Test coverage 품질 정책 품질 프로파일 코드 분석 규칙의 집합 각 언어마다 다른 품질 프로파일이 존재 품질 게이트 프로젝트 지표들로 설정된 임계값을 조합한 것. 품질 게이트를 통과하기 위해서는 모든 임..

Logrotate를 사용해서 로깅이 좀 더 효율적으로 서버공간을 차지하도록 만들자 개발하고 있는 서비스의 로그 삭제 기준이 정해지지 않아 서버 disk 용량을 많이 차지했다. 최대한 가볍게 사용하려면 로그관리를 주기적으로 해줘야 함. 하지만 매번 수작업으로 한땀한땀 지울 수도 없으니까! Logroate를 사용하자! 어떤 프로그램들이 로그를 찍는가 개발하고 있는 서비스에서 로그를 찍는 프로그램: Redis Nginx Web Application logback tomcat 로그 Logrotate Web Application 은 logback 자체 설정과 톰캣의 log rotate 설정으로 인해 서버에서 특별하게 설정해 주어야 할 것은 없다. 반면에 Redis, Nginx에서는 해당 기능이 없기 때문에 자체적..

nginx 에서 간단하게 503 에러코드를 사용하여 점검페이지를 띄워보자! 서비스 점검 공지 서비스 점검 공지 페이지가 사용되는 경우가 종종 있습니다. 장애 무중단이 불가능한 빅 업데이트 주로 위와 같은 사유로 점검페이지를 사용합니다. Nginx 를 L4 뒤, application 앞에 두는 구조이기 때문에 점검 페이지를 nginx 쪽에서 관리하고 있습니다. 실제 점검 페이지는 html 파일로, 마크업/디자인 팀에서 전달받은 파일을 nginx 서버에 업로드 하여 사용합니다. nginx 설정 nginx에서 점검 페이지를 관리하려면 conf 파일에 수정을 해야합니다. http status code 503 을 사용하여 에러 페이지로 redirect 하도록 다음과 같이 설정. server { ... locati..