DevOps & Server
HealthCheck, L4, GSLB
HealthCheck, L4, GSLB
2022.07.30L4 switch HealthCheck 보통 L7 H/C(HTTP)를 사용하고, WAS에 `` /monitor/l7check`` 같은 Controller를 둔다. 방법 1) WAS 내리는 방법 WAS가 graceful shutdown 지원해야 함. (일단 받은 요청은 모두 처리하고 나서 종료해야 하니까) WAS가 내려가는 시간 동안 delay 있음. 비추천하는 방법. 방법 2) WAS controller에서 file exists 체크해서 응답하는 방법 문제 시 파일만 삭제하면 exists가 false이므로 빠른 L4 절체가 가능하다. (서버를 내리는 것 보다 파일만 삭제하는게 더 빠르다.) WAS 자체는 정상이므로 일단 받은 요청은 모두 처리 가능하다. WAS가 graceful shutdown 지원하지 ..
Oracle Cloud Instance 초기 설정
Oracle Cloud Instance 초기 설정
2021.12.10이 글은 보호되어 있기 때문에 이것을 보려면 암호가 필요합니다.
ELK 구축 부터 log 파싱, 적재 까지 (with SpringBoot)
ELK 구축 부터 log 파싱, 적재 까지 (with SpringBoot)
2021.09.11구축 https://github.com/deviantony/docker-elk docker-compose.yml 파일 수정 후 `` docker-compose up -d`` 메모리 세팅 기본 설정에는 JVM Heap이 256m으로 작게 설정되어 있어서 이를 늘려주어야 함. docker-compose.yml 의 `` ES_JAVA_OPTS, LS_JAVA_OPTS`` 설정 (또는 docker 컨테이너 실행 환경 전체에서 제한) 너무 작게 세팅되어 있는 상태로 운영하면 ES나 Logstash 인스턴스가 java.lang.OutOfMemoryError: Java heap space 뜨면서 죽어버릴 수 있음. 그렇다고 너무 넉넉하게 줘서 시스템 전체가 메모리 부족에 시달리면 불필요한 GC, thrashing이 ..
SonarQube
SonarQube
2020.12.08Pull Request decoration 기능? PR 시 changes만 가져와서 sonarqube 돌리고 이를 PR 댓글로 리포팅해주는 기능. SonarQube v7.2부터는 유료(Developer Edition)로 바뀜. 7.1 까진 무료 버전에서도 플러그인 형태로 제공. https://docs.sonarqube.org/display/PLUG/GitHub+Plugin https://github.com/SonarSource/sonar-github 7.1 무료버전에서 플러그인으로 설정하는 경우, PR에 대한 리포트는 SonarQube 서버에 저장되지 않는다. SonarQube 서버 report 저장 기능? 유료(Developer Edition)이 아니면, 어떤 브랜치에 대고 돌린 분석이든 모두 mast..
NGINX
NGINX
2020.12.04Reverse Proxy 실 운영 환경에서는 80, 443 빼고는 inbound를 막아두는 경우가 많아서 iptables 써서 80 -> xxxx로 포워딩하거나, nginx써서 80 -> xxxx로 포워딩한다. 후자를 더 많이 사용하는데 그 이유는 nginx를 쓰면 설정이 좀 귀찮기는 하지만, 한 장비에 여러 인스턴스를 띄우고 이들을 domain(혹은 location)으로 구분하므로 모두 80으로 받을 수 있다. jenkins나 sonarqube 등 설정 파일에서 home location (e.g., /jenkins)을 설정할 수 있도록 지원하는 것이 이 것 때문. 어차피 server IP가 변경될 상황을 대비해서 도메인을 쓰긴 써야하니 그럴 바에 nginx로 리버스 프록시하는게 낫다. IP로 hook ..
[CI/CD] 젠킨스 Jenkins
[CI/CD] 젠킨스 Jenkins
2019.05.09젠킨스 설치 공식 홈페이지에서 권장하는 방법은 `` .war`` 파일 하나 받아서 java 커맨드로 띄우는 방식. 이게 제일 간단 yum 등을 이용해 아예 패키지로 설치해도 되긴 함 ```bash #!/bin/sh nohup java -DJENKINS_HOME=/home1/user/jenkins/jenkins_home -jar /home1/user/apps/jenkins/jenkins.war --httpPort=8080 > /home1/user/logs/kenins/nohub.out & ``` JENKINS_HOME은 옵션으로 줄 수도 있고, 환경변수로 줄 수도 있음. 기본 경로는 `` ~/.jenkins`` jenkins-x.x.x 폴더에 symlink 걸어서 jenkins로 참조하도록 하는게 관리 편..
vagrant
vagrant
2018.11.02VM 이미지를 통째로 배포하는 것 대비 vagrant를 사용해 배포하면 다음과 같은 이점이 있음. 1. 환경에 따라 달라지는 설정이 있는 경우, 예를 들어 배포한 가상머신들이 특정 서버 IP를 바라보도록 설정해야 하는 경우 vagrant를 사용하면 도움이 될 수 있음. 2. port forwarding 같은 가상머신 외부에서 설정해주어야 하는 부분까지 미리 설정해서 배포할 수 있음. VM 이미지만 배포하게 되면 유저가 받아서 설치할 때 직접 포트포워딩 설정하고 방화벽 열어주어야 함. 실력 없는 엔지니어라면 이런거 하다가 짜증낼 수 있기 때문에, vagrant를 이용하면 이런 상황을 예방할 수 있음. 3. VM 설치 이후 앤서블같은 provisioning shell script가 실행되도록 구성할 수 있어..
ansible 앤서블 설명
ansible 앤서블 설명
2018.10.30https://blog.naver.com/alice_k106/221333208746 경험에 비추어 생각해보면, 서버 여러대 일괄작업 및 관리, 이런거 다 쉘스크립트로 하면 되는거 아닌가? 싶은 생각이 들지만쉘스크립트 짜서 돌릴 수 있는, 또 그렇게 하려고 하는 사람이 그렇게 많지 않다는 점과쉘스크립트 자체가 그런 목적으로 있는게 아니라는 점, 그리고 여러 다른 서버에 대한 호환 등을 고려해야 한다는 점 등 실제로 적용하다보면 단점들을 마주치기는 한다. 그래서 앤서블을 사용하는 것. windows에 앤서블을 설치하기 위해서는 cygwin을 설치해야 함.
docker
docker
2018.10.27docker docker container란? Simply put, a container is simply another process on your machine that has been isolated from all other processes on the host machine. That isolation leverages kernel namespaces and cgroups, features that have been in Linux for a long time. Docker has worked to make these capabilities approachable and easy to use. docker 장점? 1. Host와 독립된 환경에 설치되므로 Host가 지저분해지지 않고 충돌도 방지..
웹서버 / WAS 정리
웹서버 / WAS 정리
2017.06.17웹서버와 WAS의 차이? Web Server 정적 컨텐츠를 반환하는 기능 서버 사이드 프로세싱이 필요 없는 단순 html, css, js같은 것. 예) Apache, IIS, nginx Web Container 서버 사이드 프로세싱이 필요한 동적 페이지를 resolve하는 기능 예를 들면 JSP같은 것. 이렇게 만든 페이지를 반환해주지는 못함. WAS WAS = Web Server + Web Container 즉, 동적 컨텐츠 resolve & 반환하는 기능 예) Tomcat WAS에 웹서버가 내장되어 있는데, 별도로 웹서버를 따로 두는 이유? 아래와 같은 이유로 보통 앞단에 apache나 nginx같은 Web Server를 별도로 두고 reverse proxy를 통해 Tomcat으로 forwarding..
AWS, Google Cloud, Oracle Cloud 비교
AWS, Google Cloud, Oracle Cloud 비교
2017.04.22On-demand? Spot Instance? 항시사용? On-demand 서버를 필요한 작업 돌릴 때만 쓸거라면 On-demand 인스턴스가 유리함. 인스턴스 꺼지면 과금이 안되기 때문에, screen으로 작업걸어 놓고 쉘에서 빠져나올 수 있음. 이 때 ;를 이용해 작업이 끝나면 종료되도록 하면 된다. 근데 이런 일회성 작업이면 그냥 람다가 나은 경우가 많은데... 람다로 커버가 안되는 경우가 있긴 함. Spot Instances 저렴한 가격으로 사용할 수 있으나, Instance가 작업 도중 사라질 수 있다. 그러나 Instance가 사라져도 Storage는 남겨두어 이를 Snapshot -> AMI로 만들고 그 AMI를 이용해 다시 Spot Instance를 만드는 방식으로 작업 결과를 저장해 가며..