매번 정해진 대로 하다 보니까 각각의 과정에서 개념들이 어떻게 쓰이는지 잘 모르겠다.
NS레코드란?
AWS에서 Route53으로 호스팅 영역을 만들 때 NS레코드를 매번 만드든다.
NS서버는 이름 서버로, NS 레코드는 인터넷에서 해당 도메인의 IP주소를 갖치 위해 가야할 곳을 알려주는 개념이다.
A레코드는?
NS 레코드를 통해서 IP주소를 등록한 후에는 A레코드를 만든다.
이 A레코드는 도메인 주소와 서버 IP주소를 직접 매핑시키는 방법이다.
도메인 tistory.com 을 예로 든다면, A record는 '티스토리 도메인은 IP 주소 121.53.105.234 에 연결 되어 있다' 라고 말하는 역할을 한다고 보면 된다.
CNAME 레코드는?
이 레코드는 도메인 별명 레코드라고 불리는데, 도메인 주소를 또 다른 도메인 주소로 이중 매핍시킬 때 사용된다.
daum.net로 지정한 도메인이 있다고 하면, CNAME을 daum2.net으로 지정해 daum2.net를 입력하면 daum.net로 접근하게 해주는 것이다.
A레코드에 한계는 IP주소가 변경되면, 도메인에 등록된 IP주소도 변경해줘야 해서 번거롭다.
CNAME 레코드는 IP 주소가 자주 변경되는 환경에서 좋다고 한다.
another.co.kr 와 others.co.kr 두개의 서브 도메인을 메인 도메인인 main.co.kr 로 매핑시키는 CNAME 레코드로 저장하고, main.co.kr이라는 주소를 서버 IP 1.1.1.100 주소로 매핑시키는 A 레코드로 저장하여 도메인 인프라를 구성해 놓았다고 해보자.
서버의 IP 주소가 바뀌었을 때 main.co.kr의 A 레코드 정보만 변경시키면 나머지 CNAME으로 연결된 서브 도메인들은 따로 작업이 필요 없어진다.
[참고자료]
nginx sites-available, sites-enabled는 뭐야?
sites-available 디렉터리는 모든 설정 파일을 저장하는 용도이고, sites-enabled 디렉터리는 sites-available 디렉터리에 생성된 설정 파일 중에서 실제 적용할 설정 파일의 심볼릭 링크를 생성하는 용도이다.
nginx는 sites-enabled 디렉터리에 생성된 링크 파일의 심볼릭 링크를 통해 sites-available 디렉터리의 설정 파일을 읽고, 이를 실행하게 된다.
이 방식은 꼭 필요할까?
Nginx - Do I really need sites-available and sites-enabled folders?이 글처럼, 그냥 설정파일에 블록 정보를 넣어주면 된다.
다만, 설정 파일에 이런 저런 설정들이 들어가다보니 내용이 너무 많아지는 게 좀 유지 보수 측면에서 불편하다는 느낌이 들긴한다.
이 경우에는 include만 해주면 sites-available에 만들어놓은 설정 파일을 참조해서 쓸 수 있어 관리에 용이하다.
cf) 찾아보니 inclue를 하면 굳이 심볼릭링크를 설정해주지 않아도 되는 것 같다.
이 패턴이 deprecated됐다는 얘기도 봤는데, 그건 특별한 상황에 한정된 것으로 보인다.
Why is sites-enabled and sites-available deprecated?
여기 글을 보면
I still use this pattern on every platform where I use either nginx or apache. It’s much easier wrt config management to drop in whatever file you need to the include directory than it is to programmatically/selectively edit the main config. Whoever thinks this is a bad idea doesn’t understand systems management.
I still plan to use this pattern until they completely remove the capability from the code. Even then, I might patch it back in.
설정 파일을 관리하는 매우 쉬운 방식이라고 한다. 이건 NGINX에만 국한되는 게 아니라 인프라 관리에서 모두 통용되는 것으로 보인다.
다만, 아래와같은 내용도 있었다.
The Debian-specific convention caused unnecessary confusion. Consider:
It is more convenient to rename a file in conf.d/ (change the extension to something other than ".conf") than to manage symbolic links across directories (by default, all files in sites-enabled are processed, regardless of extension).
Novice administrators might put a configuration file in sites-available, instead of a symbolic link. Hilarity ensues later, when the file is deleted in an attempt to "disable" the site.
Or the file is copied to sites-enabled, instead of symbolically linked, leading to more hilarity as the file versions grow out of sync.
Trying to shoehorn the nginx configs into an apache mindset blurs the lines between the two engines in an inconsistent and non-portable way. Nginx administrators from other architectures have an unnecessary learning curve to assist Debian users.
The symbolic link mechanism is so clunky that a concerned netizen saw fit to write popular scripts to perform the task. See https://github.com/perusio/nginx_ensite .
conf.d is significantly shorter to type than sites-available / sites-enabled (and you need to type both, frequently) even with tab completion.
심볼릭 링크는 관리하기 번거롭고, 초보자들이 실수하기 쉽다는 내용으로 보인다.
양측의 의견이 모두 어느정도 타당한 것으로 보이는데..
사실 이걸 지금 고민하기엔 내가 인프라에 대한 지식이 너무 없고
결정적인 차이를 만드는 것도 아닌 거 같다.
다만, 심볼릭 링크를 잘 모르는 상황에서 이걸 쓰는 건 별로 내키지 않고 conf로 관리하는 게 더 편해보인다.
sudo cp /etc/nginx/sites-enabled/* /etc/nginx/conf.d/
//우선 파일을 복사한다.
sudo mv /etc/nginx/conf.d/plaything.team /etc/nginx/conf.d/plaything.team.conf
//파일 이름을 .conf로 변경한다.
nginx 설정 파일에는 위 내용을 남겨둔다.
