#devspace

사내 게이트웨이에 접속할 때마다 명령어 전체를 입력해야 되는 것을

alias 설정을 통해 간단하게 할 수 있도록 변경해보자!

ASIS

아래의 명령어를 전체 입력해야 했다.

ssh [ID]@hcon.nhnent.com

TOBE

단어 하나 입력으로 접속할 수 있도록 한다.

hcon

1. /Users/nhn 위치로 이동

cd /Users/nhn

2. zshrc, cshrc 파일이 있는지 확인

ls -a

3. zshrc, cshrc 파일 열기

vi ~/.zshrc
vi ~/.cshrc

4. 두 파일 모두 alias 설정

alias hcon="ssh [ID]@hcon.nhnent.com"

5. 두 파일 모두 변경 사항 적용

source ~/.zshrc
source ~/.cshrc

끝! 접속 시 hcon 만 입력하면 된다!

nohup

리눅스에서 프로세스를 실행한 터미널의 세션 연결이 끊어지더라도 지속적으로 동작 할 수 있게 해주는 명령어

nohup 명령을 백그라운드(&)로 실행

&를 사용하면 프로세스가 백그라운드로 실행이 됨

백그라운드로 실행 중인지 확인하기

ps -ef | grep python

nohup과 &의 차이

• nohup
  • 프로그램을 데몬 형태로 실행시키는 것이므로 세션 연결이 끊기더라도 프로세스가 계속 동작됨
  • 실행 시키면 대기 상태가 발생하고, 세션 연결이 끊기면 프로세스는 바로 종료됨
• 백그라운드(&)
  • 실행 시키면 대기 상태가 없지만, 세션 연결이 끊기면 프로세스도 함께 종료됨
• 따라서, nohup 명령을 백그라운드(&)로 같이 실행시키게 되면, 대기 상태도 없고 세션 연결이 끊기더라도 프로세스의 종료 없이 백그라운드로 실행되게 된다.

문제 상황

nohup node ./node_modules/@vue/cli-service/bin/vue-cli-service serve --port [PORT] &
nohup python manage.py runserver [IP]:[PORT] --settings=main.config.settings.debug

위의 명령으로 사이트를 서버에 백그라운드로 실행하고 있다고 생각했는데..
때때로 웹이 내려가는 이슈가 발생했다.

원인

잘못된 명령어로 인해서 사실 백그라운드로 실행이 안 되고 있는게 아닐까? 라는 생각이 들어서

왜 그러는지 실행할 때 명령을 다시 살펴봤더니

띄울 때 장고 실행에 & 를 붙이지 않고 실행해서 터미널 세션을 닫으면 프로세스도 같이 종료되었던 것이었다..

nohup python manage.py runserver [IP]:[PORT] --settings=main.config.settings.debug

해결방법

1. 띄울 때 & 를 잊지 말자!

nohup python manage.py runserver [IP]:[PORT] --settings=main.config.settings.debug &

2. 프로세스 모니터 크론잡 등록

서버가 아예 재부팅 되거나 그럴 수도 있으니까
크론잡으로 5분마다 프로세스가 내려가 있는지 체크하고 내려가 있으면 자동으로 올려주도록 스크립트를 등록한다.

#!/usr/bin/env bash

# 로그 파일 위치
LOG_DIRECTORY="/home1/irteamsu/cronjob/logs"
LOG_FILE="$LOG_DIRECTORY/logfile_$(date "+%Y%m%d_%H").log"

# 확인할 프로세스
PYTHON_PROCESS="/home1/irteamsu/.pyenv/versions/py39/bin/python manage.py runserver [IP]:[PORT] --settings=main.config.settings.debug"
NODE_PROCESS="node ./node_modules/@vue/cli-service/bin/vue-cli-service serve --port [PORT]"

# 실행할 디렉토리
PROCESS_DIRECTORY="/home1/irteamsu/variable-comparison"

# 로그에 남길 현재시각
log_current_time() {
    current_time=$(date "+%Y-%m-%d %H:%M:%S")
    echo "[$current_time] $1" >> "$LOG_FILE"
}

# 현재 시간을 시간 단위로 구하기
current_hour=$(date "+%H")

# 이전 시간대의 로그 파일 유지, 나머지 로그 파일 삭제
for ((hour=0; hour<current_hour; hour++)); do
    if [ "$hour" -lt 10 ]; then
        rm "$LOG_DIRECTORY/logfile_$(date "+%Y%m%d_0$hour").log" 2>/dev/null
    else
        rm "$LOG_DIRECTORY/logfile_$(date "+%Y%m%d_$hour").log" 2>/dev/null
    fi
done

# python 프로세스 실행 중인지 확인
if pgrep -f "$PYTHON_PROCESS" >/dev/null; then
    log_current_time "Python process is already running."
else
    log_current_time "Python process is not running. Starting the process..."
    source ~/.bash_profile
    cd "$PROCESS_DIRECTORY"
    pyenv activate py39
    nohup /home1/irteamsu/.pyenv/versions/py39/bin/python manage.py runserver [IP]:[PORT] --settings=main.config.settings.debug > /dev/null 2>&1 &
    if pgrep -f "$PYTHON_PROCESS" >/dev/null; then
        log_current_time "Python process started."
    else
    log_current_time "Failed to start Python process."
    fi
fi

# node 프로세스 실행 중인지 확인
if pgrep -f "$NODE_PROCESS" >/dev/null; then
    log_current_time "Node.js process is already running."
else
    log_current_time "Node.js process is not running. Starting the process..."
    cd "$PROCESS_DIRECTORY"
    nohup node ./node_modules/@vue/cli-service/bin/vue-cli-service serve --port [PORT] > /dev/null 2>&1 &
    if pgrep -f "$NODE_PROCESS" >/dev/null; then
        log_current_time "Node.js process started."
    else
        log_current_time "Failed to start Node.js process."
    fi
fi

*/5 * * * * ~/cronjob/background_process_monitor.sh

결과

• 로그 파일 생성 후 1시간 동안만 보관
  • 크게 유의미한 로그가 아니기 때문에 오래 보관할 필요가 없다.

• 프로세스가 종료된 경우 자동으로 웹이 다시 올라오게 된다!

1. 문제 상황

잘 접속되던 서버였는데 갑자기 에러가 뜨면서 접속이 안 되었다.

위의 상황이 발생하는 이유를 예를 들어보자면,

A host가 있고, B server가 있다.

A는 항상 B server에 ssh 접속을 하고 있었는데, B server에 ssh나 os를 새로 설치하는 작업을 했다.

그랬는데 A가 똑같이 B에 접속을 시도하고,

B의 IP는 똑같다면 위와 같은 메시지가 뜬다.

SSH 최초 접속 시에 A와 B가 서로 인증을 하는데

B는 새로 설치되었는데 A는 예전 B에 IP로 인증이 되어있는 상태에서 B로 로그인을 하면

B는 인증정보가 없기 때문에 위와 같은 메시지가 뜨는 것이다.

2. 해결 방법

vi /Users/nhn/.ssh/known_hosts

# 보통은
# /root/.ssh/known_hosts
# /home/username/.ssh/known_hosts

접속해서 해당 IP 접속을 지우고 다시 접속을 한다.

접속해보니 장비(시스템)명이 바뀐거 같았다!

참고 사이트

• https://visu4l.tistory.com/entry/ssh-%EC%9B%90%EA%B2%A9-%EC%A0%91%EC%86%8D-%EC%97%90%EB%9F%ACWARNING-REMOTE-HOST-IDENTIFICATION-HAS-CHANGED

1. 문제 상황 

운영서버인 우분투 20.04 인스턴스에서 도커를 설치하려고 하는데 의존성 문제가 발생했다. 

(개발서버에서는 발생하지 않음.. 차이가 뭘까?)

대략 이런 식으로..

몇몇 패키지를 설치할 수 없습니다. 요청한 상황이 불가능할 수도 있고,
...
다음 패키지의 의존성이 맞지 않습니다:
 containerd.io : 의존: libseccomp2 (>= 2.4.0) 하지만 2.3.1-2.1ubuntu2~20.04.1 패키지를 설치할 것입니다

아래 방법으로 직접 설치를 진행해도 원하는 버전이 설치가 되지 않았다 :(

sudo apt-get install libseccomp2

2. 해결 방법

답은 공식 다운로드!

https://pkgs.org/download/libseccomp2

리눅스용 Libseccomp2 다운로드 사이트에 가서 환경에 맞는 패키지를 설치한다.

curl -O https://ubuntu.pkgs.org/20.04/ubuntu-updates-main-amd64/libseccomp2_2.5.1-1ubuntu1~20.04.2_amd64.deb.html

역시 공식이 최고다..

해결 완료 !