Ubuntu에서 Node.js 및 npm 설치 방식은 2가지가 나뉘며, 그 방식들에 대해 설명하고 설치 방법 및 삭제 방법을 공유하려고 한다.

 

<방법>

1. Ubuntu 운영체제에 기본으로 설정된 APT 레포지토리에서 가져와서 설치하는 방식

2. NodeSource 저장소에서 설치하는 방식

 

[ 여기서 각각의 설치 방식에 따른 차이점을 정리해서 한줄로 요약한다. ]

 

- 1번 방식은 Node.js 12 버전 이후로 레포지토리에 등록된 버전이 없기에 최신 버전 (18 버전 등)을 다운받고 싶다면 2번 방식으로 Node.js 및 npm 설치를 권장한다.

 

- [ 1번 방식 설치 ]


    #1. APT 레포지토리 업데이트
    $ sudo apt update

    #2. nodejs && npm 설치
    $ sudo apt install -y nodejs npm

    #3 버전 확인

    $ npm -v  # npm 버전 확인
    $ node -v  # node 버전 확인

APT로 설치하는 경우 아래와 같은 버전이 나오게 된다.

- [ 2번 방식 설치 ]

2번 방식의 경우 설치 방법이 조금 다르게 진행된다.
nvm이라는 관리 도구를 통해 nodejs와 npm을 설치하게 되는데 즉 2번 과정에서는 nvm 설치를 베이스로 진행된다고 보면 된다.


    #1. nvm 설치 (특정 버전이 아닌 최신 버전으로 설치)
    $ curl https://raw.githubusercontent.com/creationix/nvm/master/install.sh | bash

    #2. nvm version 확인
    $ nvm --version

    #3. nvm 명령어를 찾지 못하는 경우 해당 유저의 개인 환경 설정 갱신 작업이 필요합니다.
    $ source ~/.profile

    #4. nvm version 재확인
    $ nvm --version

    #5. nodejs 및 npm 설치
    $ nvm install --lts

    #6 nodejs 및 npm 버전 확인
    $ node -v
    $ npm -v

- 기존 nodejs 및 npm이 설치되어있는 경우 nvm 설치 전 삭제를 진행하고 2번 방식을 진행하시면 됩니다.

- nodejs 및 npm 삭제


    $ sudo apt -y remove --purge nodejs
    $ sudo apt -y remove --purge npm

    # 해당 과정까지 설치하고 다시 nodejs 등을 설치하는 경우 다른 저장 공간에 남은 관련 파일들로 인해 충돌이 발생하거나 문제가 생길 수 있습니다.
    # 아래 과정을 통해 잔여 데이터까지 모두 삭제해주세요.

    $ sudo rm -rf /usr/local/bin/npm /usr/local/share/man/man1/node* /usr/local/lib/dtrace/node.d ~/.npm ~/.node-gyp /opt/local/bin/node /opt/local/include/node /opt/local/lib/node_modules

    $ sudo rm -rf /usr/local/lib/node*

    $ sudo rm -rf /usr/local/include/node*

    $ sudo rm -rf /usr/local/bin/node*

    # 이 과정까지 진행하고 버전을 검색하는 경우 버전이 뜨지 않고 깔끔하게 삭제 되었음을 알 수 있습니다.

- git을 간편하게 사용하기 위해서 보통 GUI가 지원된다는 전제하에 github desktop, source tree를 사용하곤 한다.

 

- 하지만 GUI 방식이 아닌 개발 서버에서 CLI 방식만 지원하는 경우 github desktop, source tree 등을 사용할 수 없으므로 커맨드 명령어로 clone처리를 해야하면서 생기는 문제를 기록한다.

 

main 브런치

 

branch-2 브런치

main 이라는 이름을 가진 브런치에는 README.md 파일만 존재하고, branch-2 라는 이름을 가진 브런치에는 README.md와 test.py라는 파일이 존재한다.

 

"git clone {url}" 명령어를 수행하면 아래와 같이 main 브런치에 있는 데이터만 가져오게 되는 부분을 확인할 수 있다.

하지만 main 브런치가 아닌 branch-2에 있는 내용을 가져오고 싶다고 한다면 아래와 같은 명령어를 수행하면 된다.

main 브런치 clone 결과

 

## 브런치 이름 입력을 통한 특정 브런치의 데이터만 가져오기

$ git clone -b {branch-name} --single-branch {url}

## ex) git clone -b branch-2 --single-branch https://github.com/~~~~~

branch-2 브런치 clone 결과

 

- 이상 git 명령어로 특정 branch만 가져오는 방법이었습니다.

설치환경

- Ubuntu 20.04 LTS Server

[ 16 CPU / 16G RAM / 200G Disk ]

-----------------------------

- docker 설치


## 현재 자신이 사용하는 OS가 무엇인지 모르겠다면 아래 명령어 수행
$ cat /etc/os-release

 

OS 정보 확인 결과

## 1. docker을 설치하기 위해 의존성에 관련된 패키지 먼저 설치

 

$ sudo apt install -y apt-transport-https ca-certificates curl software-properties-common

의존성 관련 패키지 설치

 

## 2. docker 관련 패키지를 가지고 있는 apt repository 추가 처리

 

$ curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -
$ sudo add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu bionic stable"

docker GPG Key 추가
apt repository 추가

## 3. apt repository 업데이트 및 docker 설치

 

$ sudo apt update -y && sudo apt install -y docker-ce

 

docker 설치 완료

- 정상적으로 설치가 된다면 심볼릭 링크까지 문제 없이 자동으로 생성이 됨

 

## 4. docker version check

 

$ sudo docker --version

 

docker 버전 확인

## 5. docker 관련 설정

 

## 시스템 재부팅 시 docker 데몬을 자동으로 시작하도록 구성
​
$ sudo systemctl enable docker
​
​
​
## 도커 데몬 상태 확인
​
$ sudo systemctl status docker
​
​
​
## 루트 유저가 아닌 일반 유저로 docker 명령어 수행하기 위한 권한 할당
​
$ sudo usermod -aG docker $USER

 

## 6. 재부팅 및 권한 확인

 

## 재부팅 수행
​
$ sudo systemctl reboot
​
​
​
## 재부팅 이후 권한이 할당된 일반 계정에서 superuser 명령어 없이 docker가 잘 작동하는 것을 확인할 수 있음
$ docker ps -a

통신사 모뎀에서 바로 유선으로 랜 케이블을 연결하여 외부 IP를 할당 받은 Ubuntu 20.04가 설치된 데스크톱을 배경으로 한다. ( 공유기를 거치지 않는다. )

기존 Ubuntu 18.04 버전에서는 확인되지 않았던 문제로 20.04 Server 버전으로 서버 구성 시 일정 시간이 지나면 네트워크 인터페이스까지 대기모드로 들어가는 현상이 발생한다.

 

#### 일정 시간이 지나고나서 해당 IP에 ping을 보내더라도 응답이 돌아오지 않는다.

 

- 해당 문제를 해결하려면  hibernate라 불리는 대기모드에 관련된 서비스를 mask 처리를 해야한다.

## 슬립 모드에 관련된 서비스 확인 명령어

$ sudo systemctl status sleep.target suspend.target hibernate.target hybrid-sleep.target
 
- 슬립 모드 결과 확인
## 슬립 모드에 관련된 서비스를 체크하면 아래와 같이 결과를 반환한다.


sleep.target - Sleep
     Loaded: loaded (/lib/systemd/system/sleep.target; static; vendor preset: enabled)
     Active: inactive (dead) since Thu 2021-12-23 08:21:42 UTC; 1min 41s ago
       Docs: man:systemd.special(7)

Dec 23 07:30:04 jakr systemd[1]: Reached target Sleep.
Dec 23 08:21:42 jakr systemd[1]: Stopped target Sleep.

 suspend.target - Suspend
     Loaded: loaded (/lib/systemd/system/suspend.target; static; vendor preset: enabled)
     Active: inactive (dead)
       Docs: man:systemd.special(7)

Dec 23 06:39:33 jakr systemd[1]: Reached target Suspend.
Dec 23 06:39:33 jakr systemd[1]: Stopped target Suspend.
Dec 23 07:09:35 jakr systemd[1]: Reached target Suspend.
Dec 23 07:09:35 jakr systemd[1]: Stopped target Suspend.
Dec 23 08:21:42 jakr systemd[1]: Reached target Suspend.
Dec 23 08:21:42 jakr systemd[1]: Stopped target Suspend.

 hibernate.target - Hibernate
     Loaded: loaded (/lib/systemd/system/hibernate.target; static; vendor preset: enabled)
     Active: inactive (dead)
       Docs: man:systemd.special(7)

 hybrid-sleep.target - Hybrid Suspend+Hibernate
     Loaded: loaded (/lib/systemd/system/hybrid-sleep.target; static; vendor preset: enabled)
     Active: inactive (dead)
       Docs: man:systemd.special(7)

 

- 대기모드에 관련된 서비스 유닛들을 mask 처리하지 않고 disable 처리를 하게 되면 다른 유닛과 의존관계를 가지는 경우에는 해당하는 유닛들이 동작하지 않게되는 경우가 발생하게 된다.

- 그래서 이러한 경우를 방지하기 위해 mask 옵션을 이용해서 서비스 유닛의 심볼릭 링크를 /dev/null로 수정시켜서 문제를 해결한다.

 

## mask 처리를 통해 해당 서비스 유닛들의 심볼릭 링크를 /dev/null로 변경처리한다.

$ sudo systemctl mask sleep.target suspend.target hibernate.target hybrid-sleep.target


Created symlink /etc/systemd/system/sleep.target  -> /dev/null.
Created symlink /etc/systemd/system/suspend.target  -> /dev/null.
Created symlink /etc/systemd/system/hibernate.target  -> /dev/null.
Created symlink /etc/systemd/system/hybrid-sleep.target  -> /dev/null.

  

- mask 처리 후 시스템을 **재부팅** 한다.

 

## 슬립 모드 서비스 mask 처리 확인
$ sudo systemctl status sleep.target susspend.target hibernate.target hybrid-sleep.target
 

Unit susspend.target could not be found.
sleep.target
     Loaded: masked (Reason: Unit sleep.target is masked.)
     Active: inactive (dead)

hibernate.target
     Loaded: masked (Reason: Unit hibernate.target is masked.)
     Active: inactive (dead)

hybrid-sleep.target
     Loaded: masked (Reason: Unit hybrid-sleep.target is masked.)
     Active: inactive (dead)
 

- 이후 일정 시간이 지나더라도 Ping 응답이 문제 없이 오는 것을 확인할 수 있다.

+ Recent posts