문제상황

개인용 포폴로 새로운 웹사이트를 구축하기 시작하였습니다.

스택은 Angular2 + Node.js + Express + Mysql 일명 짝퉁 MEAN 스택이죠.

일단 AWS EC2 프리티어를 사용중에 있기 때문에 EC2 인스턴스 1개를 가지고 여러개의 서비스를 포트폴리오로 보여주고자 하였음.

그래서 EC2 서버에 nginx 리버스 프록시 서버를 올려서 특정 path 으로 들어오면 각각의 서비스를 보여주는 식으로.

예를 들면 

abc.com/aaa => 8080포트로 포워딩하여 aaa 라는 이름의 JSP 서비스로 연결!

abc.com/bbb => 3000포트로 포워딩하여 bbb 라는 이름의 node 서비스로 연결!

abc.com/ccc => 등등...

하지만 abc.com/bbb 에서 node 웹서버가 리스닝하는 3000포트로 날려주고, 노드서버는 앵귤러 페이지를 첫페이지로 뿌려줘야 하는데 문제가 생겼습니다.

앵귤러 프로젝트의 메인인 index.html은 나오지만, (기본 자식컴포넌트인) <app-root></app-root> 내용이 비어있는 것.

문제는 번들링된 파일들의 경로 문제였음.

아마도 리눅스 파일시스템 자원에 접근하는 경로가 기본적으로 /blog를 포함하지 않기 때문인 것.

1. base-href 와 deploy-url 에 대한 고민

위에 보면 <base href="/"> 태그가 존재함.

이부분은 아마 앵귤러 가상 url 라우팅에서 기본경로로 잡는 부분을 지정해주는 것 같음.

앵귤러 프로젝트를 빌드할 때

ng build -prod --base-href /test

로 빌드하면 위의 <base href="/test"> 로 빌드가 됨.

반면 deploy-url 은 정적 자원경로 앞에 prefix 형식으로 경로를 추가해 주는 것.

2. ng build -prod --base-href /blog --deploy-url /blog

ng build -prod --base-href /blog --deploy-url /blog 로 빌드한 경우 base href 속성과 정적 자원에 대한 경로 모두 /blog 가 붙으며, 정상적으로 모든 파일이 로드됨.

3. ng build -prod --base-href /blog

ng build -prod --base-href /blog 로 빌드한 경우 base href 속성이 /blog로 채워지지만, 정적 자원들은 그렇지 않아 번들링된 파일들이 로드되지 않음.

4. ng build -prod --deploy-url /blog

ng build -prod --deploy-url /blog 로 빌드한 경우 base href 의 속성은 채워지지 않았지만 정적 자원에 대한 경로는 제대로 잡힘. 현재 상황에서는 --deploy-url 옵션만 주는 것이 맞는 방법으로 보임.

하지만!

자세히 보니 url 에서 /blog 경로가 자동으로 제거된 것이 보임.

브라우저 특성이 아니라 자동으로 /blog 경로가 제거되며, 따라서 새로고침시에 기본경로로 접속하게 되어버림.

즉, base-href 옵션은 앵귤러 컴포넌트 라우팅에 사용할 기본 경로를 잡아주는 것임을 알 수 있다.

제대로 사용하기 위해서는 결국 ng build -prod --base-href /blog --deploy-url /blog 로 빌드해야 함

5. 또 다른 방법 APP_BASE_HREF 모듈 사용

위에서 나타난 url 상의 path 자동제거 현상을 잡아주는 모듈이 있음

3번 라인에서 APP_BASE_HREF 모듈을 가져오고, providers 에 userValue 값으로 원하는 경로를 설정.

이제 ng build -prod --deploy-url 옵션만 주어도 url 에서 경로가 지워지지 않는다.

(하지만 index.html 의 base href 속성은 왜 /blog 가 아닌 / 일까...)

문제상황

위와 같이 commit 진행시 위와 같은 메시지가 뜨면서 실제로 push를 하면 일부 디렉토리가 제대로 repo에 저장되지 않는 문제가 발생.

메시지에서 보이는 client 디렉토리가 제대로 연동되지 않는 현상임.

git status

깃 상태를 조회해보면 마찬가지 메시지를 볼 수 있음.

메시지 중에 

commit or discard the untracked or modified content in submodules

즉, 서브모듈로 뭔가 인식하고 있는 것!!!

1. .git 폴더 확인

find . -name '.git'

find ./ -name '.git'

 find -name '.git'

위 세가지 명령어는 동일한 결과를 보여줌

즉, 현재 위치하는 폴더부터 하위 노드를 모두 찾아가면서 '.git' 이라는 파일이 존재하면 경로를 출력해줌.

많이들 특정 모듈이 어디 설치되어 있는지 알아볼 때

find / -name '알고싶은모듈명'

으로 루트에서부터 검색하는 것 많이 써봤을거임 ㅇㅇ(위사진처럼)

우리는 현재 위치하는 디렉토리의 '.git' 폴더만 사용하고 하위 디렉토리에 있는 '.git' 은 서브모듈로 인식하지 않도록 삭제할 필요가 있는것임..

위와같이 -mindepth 2 를 중간에 옵션으로 쳐주면 자식노드부터 검색함.

2. 하위 .git 폴더 모두 삭제

뭐 일일이 직접 rm -rf 지울파일경로

이렇게 지워도 금방 할테지만 좀더 멋있게 하려면

find ./ -mindepth 2 -name '.git' -prune -exec rm -rf {} +

확인하니 자식노드들의 '.git' 파일들이 모두 지워졌음!

3. git push 실행

이제 안심하고 다시 add > commit > push 를 진행하면 깔-끔

블로그의 첫 글입니다.

사실 그동안 진행했던 프로젝트들도 많이 있었지만, 이렇게 블로그로 기록을 남기지 않았었죠. 현재 이직을 준비하면서 직접 블로그형 웹사이트를 만들어서 개인 포트폴리오 겸 공부기록 사이트로 남겨두면 참 좋겠다고 많이 생각했습니다. 하지만 개인 블로그 사이트 구축하는 것도 공부의 일종이기에... 우선하여 티스토리 블로그에 오늘부터의 기록을 조금씩 남겨보고자 합니다.

사람은 망각의 동물이라 저도 매일 개발하면서 구글링 하다보면 예전에 봤던 똑~같은 문서들을 자꾸 다시보게 되는 경우가 많아요. 이런 자주 찾는 내용들을 다루는 팁북같은 글부터... 진짜 별거 아닌데 며칠씩 막혀서 고생했던 문제(물론 해결책까지), 개발 패러다임까지 자유롭게 다루어 보려고 합니다.

일단은 체계가 없는 블로그라서 글부터 던져놓고, 나중에 카테고리는 글에 맞추어 정리해야겠네요.

마치며 제가 개발자로 마음가짐을 다잡게 한 글 공유합니다.

http://hothobbang.tistory.com/m/59