했던 일

프로젝트의 새 문서는 GitBook에서 만들고 Git에서 관리

기존 문서 (Word, Excel, PDF, 텍스트 정도의 메모 쓰기 등)는 Git에 등록

Gitbook의 Build는 commit이 이루어질 때마다 Jenkins에서 자동으로 실행

Git에 등록 된 문서는 Fess 서버에 하루에 한 번 pull합니다.

문서 그룹을 Fess로 매일 크롤링하고 인덱싱

위의 모든 것은 AWS로 구축

전체 구성

싹둑한 것입니다만 이런 느낌입니다.

GitBook 구축

GitBook 설치

어쨌든 마크 다운 형식으로 문서를 만들고 빌드하여
html이나 PDF를 작성해, 공개하거나 프로젝트내에 전개할 수 있는 툴입니다.
이번에는 AWS의 EC2에 환경을 만들었지만 GitBook.com에서도 할 수 있으므로 용도에 따라 바꾸면 좋겠다고 생각합니다.

설치에 관해서는, 검색해 나온 선생님의 분들을 참고로 해 갔으므로, 이쪽에서는 할애합니다.

프로젝트 멤버에게 공개

공개에 이용한 Web 서버는 apache의 2.2계를 이용했습니다.
GitBook은 프로젝트의 각 팀에 대해 작성되며 매번 증가 또는 감소합니다.
그때마다 apache의 conf를 다시 쓰는 것은 번거롭기 때문에 VertualDocumentRoot를 사용했습니다.
AWS Route53에서 사내 프라이빗 도메인을 할당하고 각 하위 도메인에 대해 GitBook 및 Jenkins 작업을 생성합니다.
workspace 이하를 문서 루트로 하는 것으로 정의의 재기입의 필요성을 없애고 있습니다.

<VirtualHost *:80>
  ServerName [プライベートドメイン]
  ServerAlias *.[プライベートドメイン]
  VirtualDocumentRoot /var/lib/jenkins/workspace/%1/_book
  <Directory "/var/lib/jenkins/workspace/%1/_book">
    Options Indexes FollowSymLinks
    AllowOverride All
  </Directory>
</VirtualHost>

Jenkins와의 협력

GitBook과 Jenkins

Jenkins의 Gitlab Plugin를 사용하여 Gitlab의 Commit과 빌드를 연동하도록했습니다.

기존 문서와 Jenkins

Jenkins 내에 최신 문서를 보관하는 것이 목적입니다.
이유는 후술하는 Fess에서 이용하기 때문입니다.

Fess 구축

OSS의 전체 텍스트 검색 엔진입니다.
공식적으로도 쓰고 있습니다만. ElasticSearch를 사용하고 있습니다.
WebAPI도 지원하기 때문에 웹 기반 Google 구글 검색도 가능하다면
APICall이 시스템에서 검색 파트 역할을 할 수도 있습니다.

현재는 패키지 인스톨에 대응하고 있는 것 같기 때문에, 도입은 비교적 용이하다고 생각합니다.
나의 때(1년 반 정도 전)는 없었던 생각이 든다…

GitBook을 크롤링

GitBook의 공개 URL에 대해 크롤링하도록 설정합니다.
프로젝트 내에서 사용하는 이름 등은 [] 쓰기로 대체됩니다.

기존 문서의 파일 크롤링

Fess가 Git에서 관리하는 문서의 색인을 만듭니다.
검색 대상은 Jenkins에서 리포지토리에서 풀링한 문서가 들어 있는 폴더입니다.

크롤링할 경로 항목에서 검색에서 찾을 수 있는 문서를 어느 정도 제어합니다.
모든 파일 대상이라면 불필요한 쓰레기 파일까지 걸려 버렸기 때문입니다.

구축하고 생각한 것

GitBook을 사용하는 경우 마크 다운에 익숙하다면 편하게

Fess에서의 검색은 Excel 등의 도형 내 텍스트까지 집어 주기 때문에 세세한 검색을 할 수 있다

문서 업데이트를 더 쉽게 알 수 있습니다

OSS만으로도 나름대로 구축 할 수있었습니다

Jenkins 아저씨는 일하는 사람