시작하며

이번주 공부한 리눅스 내용은 쉘과 쉘스크립트다 :)

Bash

Bash는 쉘의 종류로, Bourne Again Shell의 축약어다. 리눅스에서 가장 널리 사용되는 쉘이다. /bin 데릭터리 안에 존재한다.

설정파일

bash는 다섯 개의 공통된 설정 파일들을 가지고 있다. 모든 리눅스 배포본에서 이들을 찾아볼 수 있지는 않지만, 이 파일들을 만드는 것은 어렵지 않다. bash는 5개의 설정 파일을 갖는다.

일반적으로 전역적인 파일은 /etc 디렉토리에 위치한다. 지역적인 파일은 사용자 개개인을 위한 설정 내용을 담고 있어서 그 파일을 사용하는 특정 사용자에게만 영향을 끼치는 파일들을 뜻한다. 이들은 대개 사용자의 홈 디렉토리에서 찾아 볼 수 있는 숨김 파일이다. 숨김 파일은 ~/.bashrc와 같이 '.' 으로 시작한다.

• 전역적인 설정인 /etc/profile과 /etc/bashrc
• 개별 사용자마다 다른 설정을 담는, 지역적 설정인 ~/.bashrc, ~/.bash_profile, ~/.bash_logout

처음에 한 번 수행되는 게 전역파일들, 그 다음엔 매번 지역적인 파일들이 참조된다. bashrc는 bash에서 작업할 때마다 수행되는 파일로서, 우리가 그냥 python이라고 입력만 해도 python3.x버전으로 연결되어 작업할 수 있게 해준다. 즉 환경변수 개념이라고 생각하면 편하다. 만약 모든 사용자에게 적용되게 하려면 /etc/profile에 설정해주면 된다. 개별 사용자에게 적용되게 하려면 .bash에 설정한다.

Shell Script

Basic

인터프리트(interpret) 방식으로 동작하는 컴파일되지 않은 프로그램이다. 텍스트 형식으로 저장되는 프로그램으로서 한줄씩 순차적으로 읽어 커맨드처럼 실행되도록 작성된 프로그램으로, 하나의 업무에 필요한 명령어가 여러 개일 때, 주기적으로 해야 할 때, 재사용성을 늘리기 위해 사용하는 각본이라고 생각하면 된다. 이 각본을 컴퓨터가 작동하게 하여 자동화된 업무를 할 수 있도록 한다. 자바스크립트, 쉘스크립트, 펄스크립트 등 스크립트 단어 앞에 붙는 수식어들은 스크립트를 읽어 실행해주는 인터프리트 엔진을 의미한다. 쉘스크립트는 운영체제의 쉘 즉 bash, ksh, csh 등이 읽어 실행해주는 스크립트 언어이고, 펄 스크립트는 perl 이라고하는 인터프리트 엔진이 읽어 실행해주는 스크립트 언어이다.

다운로드 : 유닉스는 내장되어 있음

설정

1. 파일생성

$ touch shell_script_practice.sh # 파일 생성
$ vim shell_script_practice.sh # 쉘 스크립트 파일 편집기로 열기

2. 실행 권한 부여 (파일의 상태 변경)

$ chmod +x shell_script_practice.sh # 실행 권한 부여

3. 상단에 추가

#!/bin/bash

..하단에 스크립트 작성..

스크립트 헤드에 있는 !#의 의미 (she-bang)

스크립트 헤드의 she-bang은 이 파일이 표시된 명령 인터프리터에 제공되는 명령 집합임을 시스템에 알려줌

1. #!/bin/sh : / bin / sh 경로와 함께 Bourne 쉘 또는 호환 가능한 쉘을 사용하여 스크립트를 실행한다.
2. **#!/bin/bash : Bash 셸을 사용하여 스크립트를 실행한다.**
3. #!/bin/csh -f : C쉘 또는 호환 가능한 쉘을 사용하여 스크립트를 실행한다.
4. #!/usr/bin/perl -T : taint 검사 옵션과 함께 perl을 사용하여 스크립트를 실행한다.
5. #!/usr/bin/env python : 환경 변수에서 자동으로 파이썬 인터프리터의 경로를 조회하여 파이썬을 사용하여 스크립트를 실행한다.

4. 실행

./파일명.sh

시작하며

이번주부터 일주일에 한 번씩 공부한 내용을 업로드할 예정이다. 이번주에 공부한 리눅스 내용은 test, sleep, cat, tee, awk 명령어다 :)

sleep 명령어

• 지정한 시간동안 작업을 멈춤

• 시간

  1초 쉬기 : sleep 1, sleep 1s

  1분 쉬기 : sleep 1m

  1시간 쉬기 : sleep 1h

  1시간 1분 1초 쉬기 : sleep 1h 1m 1s

  하루 쉬기 : sleep 1d

  0.1초 쉬기 : sleep .1, sleep 0.1

sleep 시간(초단위)

test 명령어

• test : 실행이 되는지 확인 (쉘 스크립트의 조건문과 짝꿍! if의 []로 치환되기도 함)

  옵션

  1) -f : 파일 여부 확인

  2) -d : 디렉터리 여부 확인

  3) -x : 파일 존재 여부 및 실행 가능 여부 함께 확인

cat 명령어

• cat : 파일들을 인자로 받아서 해당 파일들의 내용을 쉘 화면에 출력

    #!/bin/bash
  
    cat read.sh
  
    --결과값 : read.sh 파일 그대로 읽어옴 (실행x)
    read i
    echo "What's your name?"
    echo "My name is "${i}""
  
    echo "---------"
    echo "What's ur fav food?"
    echo ""${food}""
    read food

  여러줄 입력하는 법

  1) << : 리디렉션 연산자 (Here Document)

  2) cat << 표시자

  3) 처음에 사용한 단어를 끝에도 동일하게 입력해야 함

    #!/bin/bash
  
    cat << EOF
    Hello world
    This is TEST
    EOF
  
    --결과값
    Hello world
    This is TEST

tee 명령어

• 명령어의 출력 결과를 파일과 화면에 동시에 출력할 수 있도록 해주는 명령어

• 옵션

  [ -a ]: 덮어쓰기 말고 해당 파일에 추가해서 입력합니다.

  [ -i ]: interrupt를 무시하는 옵션

  [ File ... ]: 파일들 이름입니다.

awk 명령어

데이터를 조작하고 리포트를 생성하기 위해 사용하는 언어

다른 명령어들과는 다르게 이름만으로 대략적인 기능을 예측하기 힘들다. 해당 약어는 이 기능을 만든 사람들의 이니셜이기 때문

데이터를 조작할 수 있기 때문에 쉴 스크립트에서 필수로 사용되는 툴이며, 작은 데이터베이스를 관리하기에 용이

오늘은 네트워크 기초 개념에 대해 포스팅하고자 한다.

본론

1.1 호스트(host)와 ip, 도메인(domain)

host는 guest를 맞이하는 주인이다. 이 의미가 그대로 적용되어 IT에서의 호스트는 무언가를 받아주는 객체다. 굉장히 추상적인데 이건 웹의 흐름을 보면 이해할 수 있다.

웹에 대한 여러가지 프로그램들이 있지만 결국 웹은 요청과 응답 이 두가지로 이루어져 있다. 응답에는 동기와 비동기가 있다. 여기서 요청을 하는 쪽이 클라이언트고 응답을 하는 곳이 호스트다.

내가 태블릿pc로 검색엔진에 'luaaw'를 검색한다면, 검색을 요청하는 내 테블릿pc가 클라이언트가 될 것이고, 검색 결과를 보여주는 검색엔진이 호스트가 될 것이다.

네트워크는 정보를 전달하기 위해 만들어졌는데, 이 정보를 어디에서(누가) 어디로(누구에게) 보낼 지 정해야 한다.

우리가 택배를 보낼 때 보내는이, 받는 이 주소를 모두 입력하듯이 클라이언트가 요청을 보내기 위해서는 요청 주소와 응답 주소가 있어야 하는데 그게 ip주소다. ip주소는 컴퓨터가 인식할 수 있도록 3개의 마침표로 나뉘어진 숫자로 이루어져 있다(000.000.000.000).

즉, ip는 네트워크에 접속하기 위한 공간의 주소이다. 여기서 공간은 서버pc의 하드디스크 주소다. 해당 위치는 ip로밖에 지정이 안 되기 때문에 네트워크에 접속하기 위해서는 반드시 ip주소를 할당받아야 한다.

컴퓨터가 처리할 수 있는 숫자로 된 인터넷 주소가 IP주소고 IP주소를 사람이 기억하기 쉽게 문자로 바꾼 인터넷 주소가 도메인이다.

결국 호스트는 네트워크에 연결되어 있고 IP를 가지고 있는 시스템을 의미한다. 네트워크에 연결되어 있다는 것은 쌍방향 통신이 가능하다는 의미이며, 시스템이기 때문에 운영체제와 상관없이 기본적으로 모두 가지고 있다.

클라이언트에게 호스트는 반드시 리퀘스트를 주기 때문에 호스트는 리퀘스트를 줄 수 있는 곳이 된다.

참고로 도메인은 영어 소문자, 숫자, 하이픈의 조합으로만 표현되어야 한다. 대문자/소문자 구별은 없지만 소문자로 쓰는 것이 약속이며 하이픈으로 시작하거나 끝날 수 없다. 당연하지만 고유한 값이어야 한다.

1.2 호스팅

서버를 만든 후 네트워크에 띄워서 서비스하는 일련의 과정으로 ip와 서버를 연결하는 작업이다.

요즘엔 호스팅 업체가 많다. 서비스를 하려면 서버가 24시간 돌아야 하는데 로컬에서 하기엔 금액이나 물리적으로 한계가 있기 때문에 이를 대신해주는 업체들이 등장한 것이다. 그 예로 가비아, 후이즈, 카페24 등이 있다.

1.3 도메인 체계(종류)

도메인은 루트를 제외한 3단계로 구성되어 있다.

표시 순서가 마지막(.com) → 첫번째(www)로 가기 때문에 자식 → 부모 관계로 가서 역트리구조를 띈다.

참고로 1단계 도메인의 분류값이 2단계 도메인이기 때문에 1단계 도메인과 2단계 도메인은 함께 쓰이지 않으며, 1단계 도메인은 반드시 분류값을 가지지 않는다.

1. 루트 도메인(root, ".")

2. 1단계 도메인(Top Level Domain, TLD) = 최상위 도메인 마지막에 쓰이는 도메인으로 www.google.com의 .com 쪽이다. 최상위 도메인은 인터넷에서 도메인명의 가장 마지막 부분을 말한다. 종류는 크게 3가지로 나뉜다. 1) 국가코드 최상위 도메인 (Country Code Top Level Domain, ccTLD) 국가/지역을 나타내는 도메인으로 기본적으로 해당 국가지역에 거주하는 단체 및 개인만이 취득할 수 있다. 현재 250여개의 도메인이 존재하며 한국에서 많이 사용하는 도메인은 다음과 같다. kr - 한국 / jp - 일본 / cn - 중국 / in - 인도 / us - 미국 ca - 캐나다 / uk - 영국 / fr - 프랑스 / de - 독일 / it - 이탈리아 2) 일반 최상위 도메인 (Generic Top Level Domain, gTLD) 인터넷 초창기부터 사용된 도메인들이다. 전 세계 누구나 사용가능하다. .com은 예전에 한 번 열풍이 있었어서 거의 포화상태일 정도로 많은 곳에서 사용 중이다. edu - 미국 교육기관 / gov - 미국 정부기관 / mil - 미국 국방기관 / biz - 비즈니스 com - 영리기관 / org - 비영리 공공기관 / int - 국제기구 / net - 네트워크 관련기관 3) 신규 일반 최상위 도메인 (New Generic Top Level Domain, New gTLD) 일반 최상위 도메인의 수량적 한계로 만들어졌다. 현재 가장 활발하게 늘어나고 있다. 특징은 일반 최상위 도메인과 동일하다.

3. 2단계 도메인(Second Level Domain, SLD) = 차상위 도메인 1단계 도메인에서 분류값이 필요할 때 사용한다. 예를 들어, 정부 사이트를 접속한다면, 1단계 도메인은 국가/지역을 구분하는 .kr이 될 것이고 2단계 도메인은 kr의 국가 내에서 존재하는 정부의 도메인 .go가 될 것이다.

4. 3단계 도메인 (Domain Name, 도메인명) 도메인 가운데에 표시되는 이름이다. 해당 단계는 자율적으로 지정할 수 있다.

1.4 FQDN (Fully Qualified Domain Name)

FQDN은 전체 도메인명을 의미한다. 사람들이 많이 알고 있는 FQDN은 www.google.com, www.daum.net 등이 있는데, 명확하게 말하자면 www는 호스트명이며 google.com, daum.net은 도메인명이다.

1.5 DNS (Domain Name Service)

(도메인)네임서버라고도 불리며, 인터넷망 통신규약인 TCP/IP 네트워크 상에서 도메인을 IP로 바꿔주는 시스템 혹은 이런 역할을 하는 서버 컴퓨터를 의미한다.

옛날엔 내가 하는 컴퓨터 게임을 친구에게 주려면 디스켓에 게임을 넣어서 디스켓을 직접 전달해줬어야 했었다.

그러다 미국에서 컴퓨터망의 연동망이 생기면서 '네트워크'라는 개념이 생겼다. 서로의 주소를 알아야 데이터를 전달할 수 있으므로 개인pc는 서로의 식별값인 ip를 할당받게 되었으며, 이제는 컴퓨터 게임을 디스켓에 전달하지 않아도 인터넷으로 전달할 수 있게 된 것이다.

다만 초기에는 모든 사람들이 동일한 네트워크를 사용하지 못했다. 내부 네트워크에서 할당받은 ip끼리만 사용할 수 있었는데 이게 인트라넷이다.

인터넷은 인트라넷에서 역사가 시작되었으며, 폐쇄망이 커지면서 모두가 사용할 수 있게 된 것이다. 인터넷이라는 거대 개념이 생긴 후 인터넷과 다른 개념으로 불리기 위해 '인트라넷'이라는 인터넷과 비슷한 용어로 분류된 것이며 현재 인트라넷은 군대, 청와대, 북한 등 폐쇄적인 곳에서 사용 중이다.

인트라넷을 사용할 때에는 사용자pc에 할당받은 ip들을 다 저장했는데, ip를 할당받는 사용자가 몇백, 몇천으로 늘어나면서 저 정보를 pc에 다 저장하기 힘들어졌다.

그래서 나온 개념이 DNS다. DNS는 이전에 사용자 pc에서 저장하던 ip정보들을 저장하여 사용자에게 제공한다. 덕분에 사용자는 ip주소들을 저장하지 않고 도메인만으로도 다른 주소에 접속을 할 수 있게 되었다.

우리가 많은 사람들의 전화번호를 스마트폰 전화번호부에 이름으로 저장하는 것과 비슷하다. '통화' 버튼을 누르면 전화번호부는 이름에 매칭된 번호를 가져와서 상대방 전화번호로 연결해준다. 여기서 ip주소는 나와 상대방의 전화번호, 도메인은 서로의 전화번호에 저장된 단어, dns는 스마트폰의 전화번호부가 되겠다.

공용 DNS는 매일 수십억 개 이상의 요청을 처리한다. 누군가가 브라우저에 웹 주소를 입력할 때마다 세계 어느 곳에서든 해당 도메인 네임 서버가 요청(쿼리)를 받고, 해당하는 ip주소를 연결함으로써 요청한 웹사이트가 올바르게 연결되도록 해준다. DNS가 없으면 인터넷을 제대로 사용할 수 없으므로 매우 중요한 존재라 할 수 있다.

DNS 또한 루트 DNS를 가지고 있으며, 모르는 정보가 있다면 다른 DNS와 연계하여 정보를 공유한다.

1.6 TCP/IP

인터넷에서 서로가 정보를 주고받을 때 원활한 통신이 가능하도록 만들어진 통신규약(Protocol)이다.

TCP와 IP라는 두 가지의 통신규약으로 이루어져 있다.

1. TCP (Transmission Control Protocol), 패킷교환방식 클라이언트와 서버가 신뢰성 있는 데이터를 전달할 수 있도록 만들어진 제어 프로토콜이다. 데이터는 네트워크 선로를 통해서 전달되는데 선로는 광케이블, 구리선, 인공위성 등 여러 가지가 될 수 있다. 어떤 선로냐에 따라 데이터 전달 속도가 달라지거나 손실이 발생할 수도 있고, 순서가 뒤바뀔 수 있다. TCP는 데이터의 손상과 순서를 확인하여 데이터를 재조합할 수 있다.

   TCP는 패킷교환방식으로 데이터를 전송하는데 패킷에 일련번호를 부여하여 데이터를 인식한다. 패킷은 데이터의 전송 단위이며, 패킷교환은 데이터를 작은 블록의 패킷으로 보내주는 방법이다. 경로가 정해져 있지 않으며 데이터는 송신할 때 일정한 크기의 패킷으로 분해하여 전송된다. 그리고 수신할 때 원래대로 조립된다. 패킷은 교환될 때 여러 경로 중에 최적의 경로를 찾아서 송신되기 때문에 속도가 빠르며 현재 가장 많이 사용되고 있다.

   IT 개발 동기는 거의 군사 목적으로부터 시작된다. 위급한 상황 속에서도 데이터를 주고 받아야 하고, 해당 데이터는 기밀사항이기 때문이다. 패킷교환방식도 마찬가지다.

   원래는 군사 목적으로 만들어졌다. 패킷교환방식이 개발되기 전에는 회선교환방식으로 데이터를 주고 받았는데, 전쟁 시 회선이 끊기면 데이터를 받을 수 없었기 때문에 회선이 하나만 남아있어도 통신이 끊기지 않는 네트워크가 필요했다. 그렇게 패킷교환방식은 개발되었다.

2. IP (Internet Protocol) 기기 간 데이터를 전송하기 위해 필요한 각 기기의 인터넷 주소다. TCP와 달리 데이터의 재조합이나 손실여부 확인이 불가하며, 데이터를 전달하는 역할만 한다. IP주소는 임시적으로 통신사에게 받는 주소라 변경될 수 있다. 하드웨어 고유 식별번호와 다르다(mac주소 등).

1.7 LB (Load Balancer, 로드밸런서)

동시 접속을 대비하기 위해 사용하는 장비로, 여러 서버를 사용하는 경우 동시 접속이 진행되었을 때 로드밸런서가 사용자를 부하가 없는 서버로 유치하여 분산 처리를 해준다. 로드밸런서는 ip와 도메인 사이에 위치한다.

마치며

기초 개념은 아무리 공부해도 끝이 없는 것 같다. 배운 것을 잊지 않는 개발자가 되어야지 ㅠㅠ 문의, 지적 언제나 환영해요 :)

오랜만의 포스팅이다. 3달동안 프로젝트 하느라 매일을 야근하고 서비스 오픈 직전엔 밤도 샜다ㅠㅠ 육체적으론 많이 힘들었지만, 그만큼 많은 걸 배운 느낌이다.

오늘은 nginx를 설치하여 웹서버를 띄워볼 것이다. 얼마 전에 nginx로 서버를 띄워야 하는 일이 생겼는데, 이리저리 경험해보니 내가 직접 설치해서 설정해볼 수 있겠다 싶었음

스펙은 다음과 같다.

• 운영체제 : macOS
• 사용 프로그램 : Homebrew
• nginx 버전 : 1.19.8

Apache와 Nginx

본론으로 넘어가기 전에 nginx에 대한 역사를 알아보자. apache와 nginx는 전 세계적으로 가장 큰 오픈소스 웹서버들이다. 두 프로그램의 동작 원리는 다르지만 apache의 단점을 보완하고자 만들어진 게 nginx이다보니 nginx 출시 후 둘은 늘 비교 대상이 되어왔다.

1.1 Apache

Apache는 1995년도에 처음 출시된 후에 대표적인 웹서버로 자리매김하였으며, 요청 당 쓰레드 또는 프로세스가 처리하는 구조이다. nginx보다 모듈이 다양하며 안정성, 호환성 등에 우세하다.

1.2 Nginx

Apache보다 기능은 적은 대신 성능 면에서 우세하다. 더 적은 자원으로 더 빠른 서비스를 제공할 수 있는 '경량화'된 웹서버로 핵심은 '빠름'이다. 프로그램의 흐름이 이벤트에 의해 결정(event-based)이 되며 여러 개의 커넥션을 이벤트 핸들러를 통해 비동기 방식으로 처리한다. Apache에 비하여 스레드를 많이 사용하지 않기 때문에 CPU 소모도가 상대적으로 낮다. 적은 수의 스레드로 효율적인 일처리가 가능하기에 많은 접속자들이 와도 대응을 할 수 있다.

예전엔 nginx를 차세대 웹서버라고 불렀는데, 이제는 사용자가 가장 많이 사용하는 웹서버가 되었다. 출시 이후 늘 사용자 사용 1위를 차지했던 아파치는 2019년, nginx에게 1위 자리를 넘겨주게 되었다.

1.3 무엇이 더 좋은가?

이건 상황에 따라 달라지기 때문에 어떤 것이 더 좋다고 결론을 내릴 순 없다. 서버의 부담을 줄이고 싶다면 nginx를 추천한다.

Nginx 프로세스

nginx는 하나의 master 프로세스와 여러 개의 worker 프로세스를 가진다. master 프로세스는 nginx의 성능을 측정하고 worker 프로세스를 관리한다. worker 프로세스는 요청을 처리하며, worker 프로세스 사이에 요청을 효율적으로 분배하기 위해 운영체제에 의존한다. worker 프로세스의 개수는 설정 파일에서 알 수 있는데 정의된 프로세스 개수와 사용 가능한 cpu 코어 숫자에 맞게 자동으로 조정된다.

본론

이제 nginx로 웹서버를 띄워보자.

2.1 다운로드

nginx를 사용하기 위해선 먼저 다운로드 해야 한다.

brew install nginx

다운로드가 잘 되었는지 확인하려면 버전을 검색해본다. 버전이 뜬다면 다운로드에 성공한 것이다.

nginx -v
// nginx version: nginx/1.19.8

homebrew를 이용한 nginx는 다음과 같은 경로에 설치된다. (설치방법 혹은 운영체제에 따라 /usr/local/nginx/conf, /etc/nginx 등에 설치되기도 함)

usr/local/etc/nginx

nginx를 설치하면 기본적으로 포트가 8080으로 잡혀있다. homebrew로 설치하면 현재 로그인된 사용자(mac의 user)의 권한으로 진행되는데, nginx는 root가 아닌 사용자가 nginx를 설치할 경우 1024 포트보다 작은 포트를 사용할 수 없도록 되어있다.

80 포트를 사용하고 싶다면 설정 파일의 포트를 변경한 후에 설정 적용 시 'sudo'를 붙여야 한다.

설정파일 경로는 다음과 같다.

sudo vi /usr/local/etc/nginx/nginx.conf

포트를 8080에서 80으로 변경하면 된다.

server {
 listen       80;
 server_name  localhost;

포트가 80이 아닐 때 일부 서비스에서 인코딩 혹은 서버와의 통신 오류가 발생할 수 있으므로 80번 포트로 지정해 놓는 게 좋다.

2.2 사이트 설정

nginx를 사용하는 방법은 여러가지가 있는데, 나는 하나의 서버에서 여러 개의 사이트를 띄우는 방법으로 사용했다. 이걸 가상 호스트(Virtual Hosts) 기능이라고 하는데, nginx를 포함한 거의 모든 웹서버에서 해당 기능을 가지고 있다.

1) 띄우려는 사이트들을 설정하고 2) 그 사이트들을 nginx 서버와 연결하면 된다.

sites-available, sites-enable 폴더에서 설정 및 연결할 수 있다. sites-available 폴더에는 연결하려는 서비스에 대한 사이트 정보를 정의하면 되고, sites-enabled 폴더에는 available의 파일의 심볼링크를 걸면 된다. 만약 폴더가 없다면 만들어주자.

mkdir sites-available
mkdir sites-enabled

sites-avaliable 폴더에서 정보를 입력하자.

server {
 listen 80;
 server_name 도메인명;
 server_name ip주소;
 root 루트경로;
 index index.html;

 access_log /var/log/nginx/파일명.access.log;
 error_log /var/log/nginx/파일명.error.log;
 location / {
     try_files $uri /index.html =404;
  }
}

sites-enabled 폴더에서 심볼링크를 건다. ln = link다.

sudo ln -s ../sites-available/파일명 .

설정을 적용하기 전에 작성한 파일에 이상이 없는지 확인해보자. -t는 nginx에 설정된 파일들을 테스트로 실행시켜본다.

sudo nginx -t

successful 이라는 답을 얻으면 성공이다. 에러가 있다면 nginx는 failed 답과 함께 원인을 알려준다.

2.3 설정 적용

설정을 해준 후에는 적용을 해줘야 한다. nginx를 restart하거나 reload 해주면 된다.

sudo brew service reload nginx
sudo systemctl reload nginx

reload와 restart의 차이점은 '서버 중단 여부'이다.

reload는 서버를 중단시키지 않고 명령어를 입력한 시점부터 설정 파일에서 변경된 사항만 적용한다. restart는 이름 그대로 서버를 껐다가 켠다. 설정 파일 적용 시 restart를 해도 되지만 무중단 서버를 위해선 reload를 추천한다.

그 외 명령어들은 다음과 같다. (Homebrew로 설치했을 때의 명령어와 일반 nginx 명령어)

시작 명령어

sudo brew services start nginx
sudo systemctl start nginx

중지 명령어

sudo brew services stop nginx
sudo systemctl stop nginx

재시작 명령어

sudo brew services restart nginx
sudo systemctl restart nginx

상태확인 명령어

sudo brew services status nginx
sudo systemctl status nginx

2.4 디렉토리 설정

만든 디렉토리의 소유권을 nginx 기본 사용자인 www-data에게 넘기자. chown은 change own의 약자로, 파일의 소유자나 그룹을 변경할 때 사용한다.

sudo chown -R $USER:www-data /디렉토리경로

디렉토리 권한이 755가 아니라면 변경하자.

chmod는 change mode로 파일의 사용권한을 변경할 때 사용한다.

755로 설정하면 사용자와 그룹은 파일 읽기, 쓰기, 실행 모두 가능하고 그 외는 읽기와 실행만 가능하다.

sudo chmod -R 755 /디렉토리경로

2.5 확인

서버가 잘 띄워졌는지 확인해보자.

netstat -anv | grep LISTEN

마지막으로 nginx 웹서버를 접속해보자.

설정된 페이지나 위 페이지가 뜨면 성공! 😎

마치며

macOS에서 nginx를 설치해보았다. 이 외에도 proxy 서버를 띄워서 보안을 강화하거나 로드 밸런스와 붙여서 트래픽 부하를 줄일 수 있다.

문의, 지적 언제나 환영합니다.

개요

내가 기억 안 날 때마다 와서 찾아보기 위해 쓰는 포스팅ㅋㅋ 개발 업무를 하다 보면 Git과 Github를 필수로 쓰게 되는데, 두 개의 툴을 쓰면서 가지각색의 상황을 마주하게 된다. 그리고 그 상황들은 거의 간단한 명령여 몇 줄로 해결할 수 있다(진짜다!). 오늘은 '그 명령어 몇 줄'에 대해서 알아보자.

Git 명령어

Git에서의 인덱스(index)는 원격을 의미한다.

0. reset과 revert 명령어

일단 행동 명령어를 알기 전에 함께 알아두면 좋은 명령어가 있다. 특정 commit으로 돌아갈 때 reset 명령어는 되돌린 버전 이후의 커밋 버전들이 삭제되어 히스토리에 남지 않게 된다. revert 명령어는 되돌린 버전 이후의 커밋 버전들이 그대로 남아 히스토리에도 남는다.

두 명령어는 3가지 옵션을 가지고 있다.

• soft : 이후의 커밋 내용이 stage 상태로 남아 있다(git add 이후의 상태)
• mixed : (Default) 이후의 커밋 내용이 unstage 상태로 남아 있다(git add 전의 상태). 인덱스에서는 리셋된 상태인 것이다.
• hard : 모든 작업 상태 내 변경 사항을 버린다.

각자의 상황에 맞게 명령어와 옵션을 선택하면 되는데, 보통 협업을 할 때에는 이력을 남기는 게 중요해서 revert를 많이 사용한다.

1. staging 취소하기

**git add를 취소한다는 뜻**이다. 파일 하나만 언스테이징 한다면 reset 다음에 파일명을 입력하면 된다.

$ git reset(revert) (파일명)

2. 마지막 commit 취소하기

reset / revert 명령어로 HEAD를 마지막 commit 이전으로 되돌린다.

$ git reset(revert) --option HEAD^

3. 마지막 commit 메세지 수정하기

메세지 수정은 -—amend 옵션으로 처리할 수 있다.

$ git commit --amend -m "수정 커밋 내용"

4. 특정 시점으로 commit 되돌리기

1. commit 이력을 확인한다.

$ git reflog

2. reset / revert 명령어로 특정 commit 시점으로 되돌린다.

$ git reset(revert) --option 커밋해시

3. 원격 저장소에 강제로 push 한다.

$ git push -f origin master

5. 특정 시점의 commit 메세지 수정하기

수정하고자 하는 커밋 시점으로 리베이스를 해야 한다. 리베이스에 대한 설명은 다음 글에서 확인할 수 있을 것이다.

🌟리베이스를 한다는 것은 커밋 이력이 변경되는 것을 뜻하기 때문에, 협업을 한다면 반드시 협업자와 사전에 이야기가 되어야 한다.🌟

사전 협의가 되었다는 가정 하에 아래 단계를 진행하면 된다. 리베이스에서 커밋 내역을 확인하려면 i옵션(interactive)을 사용해야 한다. -i 옵션을 입력하면 커밋 메세지에 대한 텍스트 에디터가 열린다.

interactive : 사용자가 데이터나 명령을 입력할 수 있도록 함

1. 해당 커밋으로 리베이스 한다.

$ git rebase -i

2. 이렇게 나올 것이다.

pick 커밋해시 커밋내용
pick 커밋해시 커밋내용    //수정하고자 하는 코드일 때
.
.

3. 수정하고자 하는 커밋 해시 앞의 단어를 edit 또는 e로 바꾼 후에 저장한다.

pick 커밋해시 커밋내용
**edit** 커밋해시 커밋내용    //수정하고자 하는 코드일 때
**e** 커밋해시 커밋내용    //수정하고자 하는 코드일 때
.
.

4. 커밋 메세지를 새로 작성하여 커밋한다.

$ git commit --amend -m "수정 커밋 내용"

5. 리베이스를 진행하고 -f 옵션(force)으로 푸시하여 원격 저장소에 반영한다.

$ git rebase --continue
$ git push -f origin master

참고로 중간에 리베이스를 하면 안 된다는 이야기를 들었거나, 리베이스를 하고 싶지 않다면 --abort 옵션으로 중단하면 된다. 이 번거로운 과정을 여러 가지 패키지들로 대신할 수도 있다.

주변에서 추천받았던 유틸은 git-amend 였는데 아무리 다운받으려고 해도 안 돼서 나는 포기했다.

오류 지적, 문의 사항 언제나 환영해요 :)

Error creating bean with name 'Repository' defined in 패키지.Repository defined in @EnableJpaRepositories declared on JpaRepositoriesRegistrar.EnableJpaRepositoriesConfiguration:
Cannot resolve reference to bean 'jpaMappingContext' while setting bean property 'mappingContext'; nested exception is org.springframework.beans.factory.BeanCreationException:
Error creating bean with name 'jpaMappingContext':
Invocation of init method failed; nested exception is org.hibernate.AnnotationException:
Attribute [패키지.엔티티] was annotated as enumerated,
but its java type is not an enum [java.lang.String ...

오늘은 이 에러에 대해 글쓰고자 한다.

What Is "bean"?

글을 읽다 보면 눈에 띄는 단어가 하나 있다.

'Bean'

빈(Bean)은 스프링에서 애플리케이션의 핵심을 이루는 객체이며, Spring IoC(Inversion of Control) 컨테이너에 의해 인스턴스화, 관리,생성된다. 개발자가 인스턴스를 생성하거나 호출, 삭제하면 빈이 인스턴스가 되는거고 IoC라는 컨테이너가 열심히 관리를 해준다.

직관적으로 설명하자면, 어플리케이션이 땅! 하고 켜지면 인스턴스 빈들이 뿅 나타나는 거고 (참고로) 어노테이션이라는 아이가(@ 이걸 달고 있는 아이들) 버스가 돼서 빈들을 버스에 태워 컨테이너에 데려다준다. 그러면 컨테이너가 관리를 시작한다.

Error Analysis

에러 내용을 보면 '빈을 생성할 수 없다'라고 이야기하고 있다. 어플리케이션을 작동했을 때 초기에 진행되어야 하는 일이 안됐다는 건 JPA 초기 설정이 잘못되었다는 것이다.

결국 이 긴 에러를 분석하자면 아래와 같다.

초기 설정 잘못되었으니 다시 한 번 살펴보삼

이 에러를 마주한다면 엔티티와 레파지토리 쪽을 살펴보길 바란다.

1. 엔티티를 정확히 입력했는가
2. 릴레이션 조인을 상황에 맞게 맺었는가
3. 엔티티 클래스와 연결된 클래스들이나 어노테이션이 적절하게 배치되었는가
4. 그 외...

나의 경우에는 3번이었는데, Enum 타입 설정을 잘못해서 이 에러를 어제 마주했다. 타입을 수정했더니 잘 작동하더라!!

문의 & 오류 지적 언제나 환영합니다 :)

오늘은 소스트리에서 특정 파일 커밋에서 제외하는 방법에 대해 글쓰고자 한다. 추가로 원복하는 방법까지 쓴다. 왜냐하면.. 내가 원복하는 방법을 몰라 헤맸기 때문이다(ㅠㅠ) 그 방법도 매우 간단하니 다른 분들은 나처럼 헤매지 않길 바란다. 일단 소스트리가 무엇인지에 대해 간단히 살펴보자.

What is "Sourcetree"?

소스트리 공식 홈페이지에 가면 아래와 같이 정의하고 있다.

Git's GUI

GUI는** '그래픽 사용자 인터페이스(Graphical User Interface)'**의 약자로 사용자가 편리하게 사용할 수 있도록 입출력 등의 기능을 알기 쉬운 아이콘 따위의 그래픽으로 나타낸 것이다. 한마디로 정리하자면 사용자가 보기 좋도록 예쁘게 꾸며주고 간편하게 만들어진 것이라 할 수 있겠다.

그렇다면 소스트리는 Git을 예쁘고 간편하게 쓸 수 있는 프로그램이라 할 수 있겠다. 실제로 깃 push, pull, commit을 하려면 terminal이나 powershell이라고 불리우는 80년대 UI같은(커스텀하면 좀 예뻐지지만) 곳에다 명령어를 키보드로 입력해야 한다. 소스트리는 이 불편한 과정을 간편하게 클릭만 하면 될 수 있게끔 만들어놨다.

가끔(어쩔 땐 많이) 혼자 에러나서 꺼지는 것만 빼곤 사용하기 편리한 GUI다.

특정 파일 커밋 제외하기

그렇다면 어떻게 특정 파일을 제외할 수 있을까? 방법은 간단하다.

1. commit 할 때
2. 불필요한 파일을 '오른쪽 마우스 클릭'하여
3. '무시' 버튼을 눌러주면 된다!
4. 그러면 설정창이 나오는데 원하는대로 설정하면 된다. 이제 소스트리는 '무시' 선택된 파일을 커밋에서 더 이상 표시하지 않을 것이다! :)

하지만 작업하다 보면 변수는 언제나 발생하는 법.. 갑자기 그 파일을 커밋해야 하는 상황이 생기거나, 알고보니 그 파일은 원래 커밋했어야 하는 파일이라면?

그렇다면 우리는 무시했던 파일에 다시 관심을 줘야 한다! 무시한 파일에 다시 관심을 줘야 한다.

커밋 제외한 파일을 원복시키기

방법은 굉장히 간단하다.

1. 사용하고 있는 IDE나 에디터에서
2. 해당 파일을 오른쪽 마우스 클릭한 다음
3. Git - add 처리 해주면 된다.

그럼 소스트리는 다시 그 파일을 인식한다! 소스트리 설정 - 고급 - 저장소별 무시 목록(.gitignore) 메뉴가 있긴 한데 나는 거기서 해결할 수 없었다. 어차피 모두들 개발하면서 하나의 에디터나 IDE 사용하니까 거기서 간편하게 해결하는 게 좋은 것 같다(소스트리에서 해결 못해서 이르는그 아늬다...)

문의 & 오류 지적 언제나 환영합니다 :)

리액트 개발자들과 얘기하다 보면 요런 얘기를 심심찮게 듣는다.

"이건 컴포넌트 안에 컴포넌트를 넣고..." "children으로 컴포넌트 레이아웃을 짜고 props를 넣고..." "컴포넌트가... 어쩍저쩍..."

듣다보면 컴포넌트는 리액트의 구조를 짤 때 필요한, 기본적인 틀과 같은 느낌이 드는데.. 컴포넌트란 무엇인가?

What is "Component"?

앞선 글에서 우리는 리액트가 "HTML"을 만들어주는 라이브러리라는 것을 배웠다. 그렇다면 컴포넌트도 HTML과 관련이 있을 것이다.

컴포넌트의 정의는 아래와 같다.

HTML을 생성하는 자바스크립트 함수의 모음집

그렇다. 컴포넌트는 함수이다! 다만 HTML을 직접적으로 리턴하지는 않고 보통 JSX라는 HTML과 유사한 문법을 리턴한다. 결국 HTML과 관련이 있다. ("보통"이라는 건 꼭 JSX를 리턴해야해!!!! 는 아니라는 뜻이다)

아니, 그렇다면 JSX라는 문법은 뭐길래 컴포넌트 함수가 그걸 리턴한단 말인가?

What is "JSX"?

JSX는 리액트만의 거의 유일한 문법이다. 정의는 아래와 같다.

변형된 자바스크립트로, 자바스크립트 안에 HTML처럼 보이는 소스 코드를 사용할 수 있게 해줌

JSX에는 중괄호를 사용할 수 있는데, 그 안에는 모든 자바스크립트 표현식을 넣을 수 있다. JSX를 사용하는 목적은 다음과 같다.

자바스크립트 코드를 HTML로 만들기 위함

글을 읽으면 읽을수록 뭔 소린가 싶을 것이다. 저 목적을 이해하기 위해서는 리액트 작동 흐름을 알아야 한다.

React's Working Flow

JSX 작동 흐름은 이렇다.

1. 컴포넌트가 JSX를 리턴하면
2. 바벨과 웹팩이 JSX 코드를 바닐라 스크립트로 변환한다.
3. 변환된 코드는 HTML로 변환되고 나서
4. 컴포넌트를 렌더링 할 때 DOM으로 삽입되어 페이지에 실제로 보여진다.
5. 그러면 사용자는 네이버, 다음과 같은 페이지를 볼 수 있는 것이다.

JSX의 목적은 ... 작동 흐름 1, 2, 3번 즈음과 맞물린다. 그렇다면 합리적인(!) 의문이 든다.

"아니 그럼 컴포넌트 리턴값을 그냥 바닐라 자바스크립트로 하셈. 왜 굳이 중간에 JSX가 껴?"

그 의문은 아래에서 풀린다.

간단한 예시를 들어보자.

홈페이지에 "Hi" 문구를 뜨게 해보쇼

JSX 코드는 이렇다.

export default function App() {
    return (
        <div>Hi</div>
    )
}

바닐라 자바스크립트 코드는 이렇다.

var _temporalUndefined = {};
var App = _temporalUndefined;

App = function App() {
    return React.CreateElement(
        "div",
        null,
        "Hi!"
    );
};

둘을 비교하였을 때 어느 쪽이 더 가독성이 좋은가? 그리고 코드양은 어느 쪽이 더 적은가? 압도적으로 JSX쪽이다. 리액트가 JSX를 만든 이유 중 하나이기도 하다.

컴포넌트는 JSX 뿐만 아니라 바닐라 자바스크립트도 리턴할 수 있다. 다만, 가독성도 안 좋고 코드양도 많아서 다들 안 쓸 뿐이다. 개발자들은 게으르기 떄문에 어떻게든 더 편리한 방법을 찾지 않는가?ㅋㅋ

오늘의 포스팅은 여기까지! 문의, 오류 지적 언제나 환영합니다 :)

What is "Boiler Plate"?

위키에서는 보일러플레이트 코드를 다음과 같이 정의하고 있다.

변경이 거의 또는 전혀 없이 많은 곳에 포함되어야하는 코드 섹션

보일러플레이트라는 단어의 어원이 신문사업에서 생겼다고 한다. 1890년대에 광고나 컬럼에서 똑같이 사용되는 텍스트를 강철로 도장 찍듯이 찍기 시작한 것. 어원과 정의를 보았을 때 보일러플레이트는 아래와 같이 정의할 수 있겠다.

최소한의 변경으로 여러 곳에서 재사용되는 것

What is "CRA"?

CRA는 Create-React-App 라는 리액트 공식 명령어의 약자이다. 명령어는 아래와 같다.

npx create-react-app 프로젝트명(서비스명)

참고로 npx는 npm의 CLI이다. 명령어를 직역하자면 '리액트 어플리케이션 하나 만들어주삼' 이 되겠다. IDE나 에디터로 프로젝트를 생성할 수 있지만 CRA로 생성하면 웹팩(Webpack) 등의 세팅들을 알아서 해준다. IDE나 에디터로 생성할 시 해당 세팅을 일일이 해줘야 한다.

여담으로 CRA로 생성한 어플리케이션에는 웹팩 설정 파일이 안 보이는데 그건 CRA가 숨겨놓았기(!) 때문이다. package.json의 scripts를 통해 파일 경로를 찾을 수 있다.

그렇다면 왜 사람들은 CRA를 보일러플레이트라고 부르는 걸까?

CRA = Bioler Plate?

CRA에는 '변경 없는 (어플리케이션을 생성해주는) 코드'들이 있고 이 코드들은 '여러 곳(정확히는 여러 사람들에게)'에서 쓰인다. 이는 보일러플레이트의 역할과 일치하므로 CRA는 리액트의 보일러 플레이트라고 할 수 있겠다.

다음에는 리액트의 기본 문법에 대해서 포스팅하겠다. 문의 및 오류 지적은 언제나 환영합니다 :)

What Is React?

2013년 페이스북이 만들었다. 공식 홈페이지에는 "사용자 인터페이스를 만들기 위한 자바스크립트 라이브러리"라고 쓰여 있다. 사용자 인터페이스는 UI이고 웹 브라우저에서 보여지는 건 HTML일테니 결국 리액트는 아래와 같이 정의할 수 있겠다.

"웹 브라우저에서 보여지는 HTML을 만드는 자바스크립트 전용 라이브러리"

Fame of React?

매년 자바스크립트 관련 프레임워크, 라이브러리 등의 생태계 인지도와 관심도를 조사하는 [StateOfJS] (https://2019.stateofjs.com/ko/) 사이트에 따르면, 리액트의 인기는 2016년도부터 상당했다.

리액트와의 비교군은 중국 개발자가 만든 Vue.js, 이제는 시들해진 Angular.js, 캐릭터가 귀여운 Ember.js이다.

아래 그래프를 보면 리액트는 2016년도부터 2019년도까지 2018년 1년을 제외하고 모든 해 1위를 차지하였다. 2018년도의 1위는 Vue.js이다.

그래프에는 나와 있지 않지만 2010년도 초중반엔 Angular.js가 인기가 많았고 리액트는 논외 대상이었다. 얘기 듣기로는 리액트 공부하는 사람은 거의 무시당했다고 할 정도.. 그러나 불과 몇 년만에 상황은 뒤바뀌었다!

두 번째 이미지는 자바스크립트 프레임워크들에 대한 개발자들의 설문조사 결과를 나타낸 자료인데, 가장 왼 쪽이 리액트이다. 리액트는 모든 프레임워크들 중에 빨간색 면적이 제일 넓다. 빨간색의 의미는 아래와 같다.

전에 “사용한 적”이 있고, 다시 사용할 생각이 “있음”

참고로 파란색의 의미는 들어봤으나 관심 읎음이다ㅋㅋ

앵귤러의 인기가 몇 년도 안 돼서 시들해진 것처럼 리액트도 그렇게 될 것이라고 예상한 사람들을 비웃듯이 리액트는 자바스크립트 대표 라이브러리로서 굳건히 서있다.

도대체 무엇이 사람들로부터 리액트에 열광하게 만들었을까?

Why React?

여러가지 이유가 있을 것이다. 아토믹 패턴, SEO와 SSR, Virtual DOM ... 개인적으로 나는 아래 이유가 가장 끌린다.

리액트는 자바스크립트 기반으로 작동한다.

즉, 혹여나 리액트가 없어져도 배운 지식을 써먹을 수 있다는 소리가 된다! 어디에? 자바스크립트 스킬 업에!! 날마다 새로운 개발 기술이 만들어지고, 그걸 빨리 습득해야 하는 개발자의 입장으로서 배운 지식을 재활용할 수 있다는 말은 너무나도 큰 메리트다 ㅋㅋ

앵귤러나 뷰는 프레임워크에 맞는 문법이 따로 존재해서 개별적으로 습득해야 한다. 반대로 리액트는 JSX를 제외하고는 거의 모든 문법이 자바스크립트임!

리액트를 배우면 자바스크립트를 따로 공부할 필요가 없다고 말하는 사람이 있을 정도로 리액트는 자바스크립트와 영혼의 소울메이트다. 그리고 자바스크립트는 웹에 쓰이는 유일한 프로그래밍 언어이므로 개발자라면 필수로 배워야 하는 언어이다.

결론! 포지션에 프론트엔드가 있다면 리액트를 열심히 공부합시다 (2020년도 기준).

다음에는 리액트의 공식 명령어인 CRA에 대해 포스팅하겠다. 문의 및 오류 지적은 언제나 환영합니다 :)

> test-react@0.1.0 eject 프로젝트 directory
> react-scripts eject

sh: react-scripts: command not found
npm ERR! code ELIFECYCLE
npm ERR! syscall spawn
npm ERR! file sh
npm ERR! errno ENOENT
npm ERR! test-react@0.1.0 eject: `react-scripts eject`
npm ERR! spawn ENOENT
npm ERR! 
npm ERR! Failed at the test-react@0.1.0 eject script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.
npm WARN Local package.json exists, but node_modules missing, did you mean to install?

npm ERR! A complete log of this run can be found in:
npm ERR!     로그파일

이걸 번역하자면...

" 니가 쓴 명령어 react-scripts에서 찾을 수 없어! npm 문제 아닌 것 같어 추가 로깅이 있는 거 같은데. npm install을 했는지 확인해봐 "

그렇다면 확인 사항은

1. 명령어가 package.json scripts에 있는가?
2. (1번이 아니라면) npm install을 했는가?
3. (2번이 아니라면) 로그를 확인했는가?

나는 명령어가 스크립트에 있었고, npm install을 한 상태였다. 다만 여러 라이브러리를 추가하던 때라서 install을 짧은 시간 안에 여러 번 한 상태였음.. 로그가 쌓여서 발생한 문제라 판단하여 아래와 같이 시도하였다.

1. 캐시 정리

   npm cache clean --force

2. 기존 파일 삭제 : node_modules, package-lock.json

   rm -rf ./node_modules rm -rf ./package-lock.json

3. npm 재설치 & 재시작

   npm install && npm start

시도 후 프로젝트는 잘 작동하였다! 혹시 모르니 중간 중간에 캐시를 지워줘야 겠다.

문의 & 오류 지적 언제나 환영합니다 :)

질문과 시행착오가 가득할 수도 있지만 그 또한 내 성장의 밑거름이 되어줄거라 믿는다. 천천히, 그리고 꾸준히 기록해 나가야겠다.

오늘부터 velog 시작!