136호. 멀티도메인 환경을 도와주는 라이브러리, laravel-multidomain free

2020-05-04

안녕하세요.


오늘은 라라벨 환경에서 원소스 멀티도메인을 지원하는 편리한 방법을 소개합니다.

그전에 이 원소스 멀티도메인에 대한 간략히 사용 예는 이럴 경우가 있습니다.



  1. 임대형 쇼핑몰 서비스



  • 흔히 Cafe24 나, MakeShop 의 임대형 호스팅서비스입니다.

  • 메인 코어는 원소스로 관리되고 외부로 표현되는 Front end 영역은 여러가지 템플릿 형태로 서비스 됩니다.



  1. 임대형 콘텐츠 매니지먼트 서비스



  • 비교를 하기엔 애매한 서비스들이긴 하나, 흔히 뉴스콘텐츠를 관리하는 서비스들이 여기에 포함됩니다.


원소스 멀티도메인의 사용 예는 이 밖에도 대단히 많습니다만, 이건 비지니스 도메인과 밀접한 관계가 있기 때문에 솔루션류를 만드시는 분들은 한번쯤 고민해볼법한 방법론입니다.


원소스 멀티도메인의 장점은 코어나, 기타 공통 모듈들의 소스파일들은 단일로 관리가 되고, 잘 짜여진 프로토콜에 의해 프론트엔드 영역이나 특정 기능(Custom features)만 핸들링 되며, 이로 인한 코드 유지보수에 대한 관리포인트가 줄어든다는 장점이 있습니다.

단점은 그 반대급부에 해당됩니다. 예를 들어, 잘 짜여지지 못한 프로토콜. 그리고 광범위하고 논리없이 설계된 특정 기능을 원소스로 관리하기에는 대환장 파티가 벌어질 가능성이 농후합니다.


서론이 조금 길었는데요. 각설하고 오늘은 라라벨에서 위의 사례들을 조금 편리하게 도와주는 패키지를 소개해볼까 합니다.


바로 gecche/laravel-multidomain 이라는 패키지입니다.


따봉수는 많지 않지만 (현시간 기준 332 따봉)

막상 테스트해보고, 프로덕션 환경에서 반년 넘게 운영중인데 사용해볼만 한 패키지라 판단되어 1일1식 라라벨에서 소개해드립니다.


일단, 패키지 description 을 보면 우리가 필요한 딱 그 케이스를 이야기합니다.

코어와 동일 모듈들을 사용하지만, 코드(아마 Front-end?), 데이터베이스, 스토리지 그외 다양한 구성측면을 다르게 사용할 경우, env 파일과 기타 설정들을 다르게 설정할 수 있는 매우 간단한 방법을 제공한다고 합니다.


살짝 설정을 어떻게 동작하는지 설명 드리면,


1. Application class 교체

Laravel 초기 bootstrap 이 동작할때 위 패키지의 메인 어플리케이션을 로드하게 합니다.

그래서 우리는 bootstrap/app.php 파일의 $app 을 다음과 같이 변경해주어야하지요.


$app = new Gecche\Multidomain\Foudation\Application(
$_ENV[‘APP_BASE_PATH’] ?? dirname(__DIR__)
);

2. Application Kernels 교체 (HTTP / CLI)

app/Http/Kernel.php 와 app/Console/Kernel.php 을 모두 기존 Illuminate 에서 Gecche\Multidomain 으로 바꿔줍니다.


use Gecche\Multidomain\Foudation\Http\Cernel as HttpKernel;

use Gecche\Multidomain\Foudation\Console\Cernel as HttpKernel;

3. QueueServiceProvider 를 override

그리고 QueueServiceProvider 를 override 하죠. config/app.php 파일내에 $providers 배열에 있는 기존 큐서비스프로바이더도 교체합니다.


Gecche\Multidomain\Queue\QueueServiceProvider::Class;

여기 까지 읽으신 분들은 센스있게 딱 이해하실 껍니다.

‘아 이 패키지는, console 명령어(artisan 명령어) 뿐만 아니라 Queue도 별도의 환경설정내에서 동작시킬 수 있구나..’ 를 말이죠.


끝났습니다. 이제 vendor:publish 를 통해서 설정파일을 복사하고 사용하시면 됩니다.


사용법은 간단합니다.


php artisan domain:add site1.com
php artisan domain:add site2.com

이렇게 하시면 .env 가 존재하는 root path 에 .env.site1.com , .env.site2.com 파일들이 생성된걸 확인할 수 있죠.


그리고 각 도메인에 맞는 .env.somedomain… 들의 설정값들을 상황에 맞게 바꿔가면서 사용하시면 아주 편리하게 사용할 수 있습니다.


storage와 기타 env 에서 설정할수 있는 모든것들이 분리되어있어서, 원하신다면 프론트앤드에서 표현할 HTML / CSS / JS 등 모든 부분을 분리/설정할 수 있습니다. 꽤나 간결하게 우리가 목적한 바를 이룰 수 있죠.


아! queue와 console 도 적용된다고 위에 말씀드렸었는데요, artisan 뒤에 --domain=site1.com 이런식으로 모든 콘솔명령어에 해당 인자를 입력하면 예상한 기대값을 얻을 수 있습니다.

queue work 도 마찬가지입니다. 라라벨에서 자주 사용하는 (공식문서의 가이드대로..) supervisor 나, 스케쥴 작업을 위한 crontab 에서도 --domain 에 대한 인자값을 입력하시면 됩니다.


스케쥴의 경우에는 코드 내에 삽입할 수도 있습니다. 이렇게 말이죠.



패키지를 소개하다가 글이 다소 길어졌네요. 3줄 요약 가봅니다.


장점


  • env 가 분리되어야하는 상황에서 완전히 격리된 어플리케이션의 모습을 보여줍니다.

  • http request 뿐만 아니라, cli / queue 에 대한 작업들도 격리된 환경에서 동작합니다.

  • 그리고 쉽고, 나름대로 잘 관리되고 있는거 같습니다. (마지막 마스터 머지 날짜 : 2020, 04, 22)


단점


  • 사이트가 추가될 때마다 손이 많이 간다. (자동화시키는 스크립트를 작성하여 이 부분은 해소할 수 있다.)

  • 세줄 채우려했는데, 딱히 단점 발견이 힘듦… ??


어쨌든, 오늘도 불철주야 솔루션 개발/관리 하시는 우리 개발자형님들

멀티도메인은 이걸로 종결하시면 정신건강에 좋습니다! 혹시나, 라라벨을 이용한 멀티 도메인 솔루션을 고려중이시라면, 이 포스트가 참고가 되면 좋겠습니다.


긴 글 읽어주셔서 감사합니다.


정유찬

PHP 와 라라벨을 사랑하는 개발자. 원래는 iOS 개발자였으나, 어찌된 영문인지 서버개발을 더 많이하게 된 장래희망 : (진짜)풀스텍 개발자인 일반 개발자입니다.