docker上でQiita風ツール「 Knowledge 」を動かす

引き続き、dockerに関する備忘録。

下記の書籍の「Docker実践活用術」の章で、 Qiitaクローンの「Lodge」での利用例が紹介されていたが、

Dockerエキスパート養成読本［活用の基礎と実践ノウハウ満載！］ (Software Design plus)

ここでは、もうひとつのQiita風のナレッジツール「Knowledge 」を 後述の参照URLを参考に動かしてみる。

目次

参照書籍

いろいろな記事を参考に、dockerをとりあえず使ってみるというこれまでのスタンスだとさすがに、 限界がきたので、下記の書籍がAmazonの技術書フェアで半額になっていたので、購入して、体系的にお勉強中。

Docker実践ガイド impress top gearシリーズ

参照URL

手順においては、下記のＵＲＬの通り。

https://github.com/support-project/docker-knowledge

docker imageの取得

[root@docker ~]# docker pull koda/docker-knowledge

docker imageの確認

[root@docker ~]# docker images
docker.io/koda/docker-knowledge       latest              b94b7b9e8ded        3 weeks ago         490.3 MB
[root@docker ~]#

データ保存場所の作成

データをホスト側のファイルシステムに永続化するため、下記のディレクトリを作成し、パ＾ミッション変更

[root@docker ~]# mkdir -p ~/knowledge
[root@docker ~]# chmod a+w ~/knowledge

knowledgeのコンテナ起動

[root@docker ~]# docker run -d -p 9090:8080 -v ~/knowledge:/root/.knowledge --name knowledge koda/docker-knowledge

knowledgeにアクセス

http://dockerホストのIP:9090/

にアクセスし、knowledgeにアクセスする すると、トップ画面が起動しているので、[GetStarted]を押す

その後、ユーザー登録を行い、下記が投稿画面。

いくつか投稿ができることを 確認してみる。下記が投稿一覧画面。

コードのシンタックスハイライトなんかもばっちり利いてます。

雑感

qiita自体は、会社的にNGとなりそうだが、こちらなら無償で 社内環境でも使えそう。

今風の色味で、ナレッジ共有ツールとしてさらに検証してみたいところ。

docker上でwekanを動かす

こちらで、セットアップした環境で、wekanを動かした際の備忘録。

mytracking.hatenablog.com

後述の参照URLを参考に、wekanを動かしてみる。

目次

参照書籍

いろいろな記事を参考に、dockerをとりあえず使ってみるというこれまでのスタンスだとさすがに、限界がきたので、下記の書籍がAmazonの技術書フェアで半額になっていたので、購入して、体系的にお勉強中。

Docker実践ガイド impress top gearシリーズ

参照URL

手順においては、下記のＵＲＬの通り。

qiita.com

ここでは、上記の通り、docker-composeを使ってみることに。

データ保存場所の作成

データをホスト側のファイルシステムに永続化するため、下記のディレクトリを作成

[root@docker ~]# mkdir -p ~/docker/wekan/

docker-composeのyml を用意する。

とりあえず、よくわからないが、参照URLの通り、ymlファイルを 環境に合わせて微調整したのが、下記。

[root@docker ~]# cat ~/docker/wekan/docker-compose.yml
wekan:
  image: mquandalle/wekan
  links:
    - wekandb
  environment:
    - MONGO_URL=mongodb://wekandb/wekan
    - ROOT_URL=http://192.168.3.72:8181
  ports:
    - 8181:80 # ポートは好きなポートに
  restart: always

wekandb:
  image: mongo
  volumes:
    - /mnt/sda1/docker/wecan/data:/data/db # tmpfsでない位置を指定
    - /mnt/sda1/docker/wecan/configdb:/data/configdb # tmpfsでない位置を指定
  restart: always

wekanのコンテナ起動

[root@docker ~]# cd ~/docker/wekan
[root@docker wekan]# docker-compose up -d

wekanにアクセス

ROOT_URLに記載したURL（ここではhttp://192.168.3.72:8181)にアクセス

例のように、ログイン画面が起動している。 （個人的に、この瞬間が、一番dockerのメリットを感じるところ。）

あとは、通常通り、プロジェクトを作りながら、

カードを追加したりなんかして、利用する。

雑感

クラウドなんてけしからん！ってな会社のため、 参照URLの記載の通り、「Trello使いたいけど会社が使わせてくれない」状況にある。

あるチームによっては、なんとExcelをかんばんツールに見立てて利用しているなんてところもあるため、 dockerでの手軽さを紹介して、そんなチームを助けてあげたいと思う。

docker上でgitLabを動かす

こちらで、セットアップした環境で、gitLabを動かした際の備忘録。

mytracking.hatenablog.com

下記の書籍の「Docker実践活用術」の章で、 いろいろなアプリケーションのdockerでの利用例が紹介されていたので、

Dockerエキスパート養成読本［活用の基礎と実践ノウハウ満載！］ (Software Design plus)

後述の参照URLを参考に、gitLabを動かしてみる。

目次

参照URL

手順においては、下記のＵＲＬの通り。 （※説明がシンプルで手っ取り早く、試してみたい人はおすすめのエントリ） yoru9zine.hatenablog.com

Dockerを使って、RedmineとGitLabを構築する

docker image　の取得

まずは、gitlabのイメージを取得する。

[root@docker ~]# docker pull sameersbn/gitlab:9.0.3

データ保存場所の作成

データをホスト側のファイルシステムに永続化するため、下記のディレクトリを作成

[root@docker ~]# mkdir -p ~/docker-data/gitlab
[root@docker ~]# mkdir -p ~/docker-data/gitlab-redis
[root@docker ~]# mkdir -p ~/docker-data/gitlab-pgdata

gitLabを起動する。

とりあえず、よくわからないが、参照URLの通り、起動してみる。

まずは、DBから。

[root@docker ~]# docker run -d --name my-gitlab-postgres -v ~/docker-data/gitlab-pgdata:/var/lib/postgresql -e 'DB_NAME=gitlabhq_production' -e 'DB_USER=gitlab' -e 'DB_PASS=password' -e 'DB_EXTENSION=pg_trgm' sameersbn/postgresql:9.6

つぎに、key-valueデータストア？（らしい）を起動。

[root@docker ~]#  docker run -d --name my-gitlab-redis -v ~/docker-data/gitlab-redis:/var/lib/redis sameersbn/redis:latest

最後に、gitLabを起動。

[root@docker ~]# docker run -d --name my-gitlab -v ~/docker-data/gitlab:/home/git/data --link my-gitlab-postgres:postgresql --link my-gitlab-redis:redisio --publish 10022:22 --publish 10080:80 -e 'GITLAB_PORT=10080' -e 'GITLAB_SSH_PORT=10022' -e 'GITLAB_SECRETS_DB_KEY_BASE=long-and-random-alpha-numeric-string' -e 'GITLAB_SECRETS_SECRET_KEY_BASE=long-and-random-alpha-numeric-string' -e 'GITLAB_TIMEZONE=Tokyo' -e 'GITLAB_SECRETS_OTP_KEY_BASE=long-and-random-alpha-numeric-string' sameersbn/gitlab:8.15.3

gitLabの管理画面にアクセス

ここまで、訳も分からず、先述の参照URLのまんまパクリ、 以下にアクセスしてみる。

http://dockerホストのIP:10080

基本的にここまでの作業は、先述の参照ＵＲＬのパクリのため、自分でも深くはよくわかっておりません。。。

そんなんで、うまくいくはずないだろ！っとタカをくくっていると・・・・

ちゃんと起動しているではないか！

当然、どうやってgitLabを使ってよいかもわかっていないので、 とりあえず、登録。

ログインできたので、プロジェクト作成。

ちゃんと、プロジェクトできてるし！

以上のように、良いか悪いかは別として、よくわかっていない自分でも、 gitHubクローンな環境が手元にできるところは凄いところ。

所属する会社は、クラウドなんてけしからん！ってな会社のため、 イントラ環境で、バージョン管理したいなんてシーンを想定して、 こちらの環境で、いろいろ学習していく予定。

docker上でRedmineを動かす

こちらで、セットアップした環境で、Redmineを動かした際の備忘録。

mytracking.hatenablog.com

下記の書籍で「Docker実践活用術」の章で、 いろいろなアプリケーションのdockerでの利用例が紹介されていたので、

Dockerエキスパート養成読本［活用の基礎と実践ノウハウ満載！］ (Software Design plus)

そのノリで、まずは、お約束のRedmineを動かしてみる。

目次

参照URL

手順においては、下記のＵＲＬの通り。 （※説明がシンプルで手っ取り早く、試してみたい人はおすすめのエントリ）

yoru9zine.hatenablog.com

Dockerを使って、RedmineとGitLabを構築する

docker image　の取得

まずは、Redmineとpostgressのイメージを取得する。

[root@docker ~]# docker pull postgres:9.5.0
[root@docker ~]# docker pull redmine:3.0.7

docker image　の確認

取得したdockerイメージを確認する。

[root@docker ~]# docker images
REPOSITORY           TAG                 IMAGE ID            CREATED             SIZE
docker.io/redmine    3.0.7               fd0638cb07ab        9 months ago        588.6 MB
docker.io/postgres   9.5.0               b2b0df88a221        14 months ago       263.8 MB
[root@docker ~]#

データ保存場所の作成

データをホスト側のファイルシステムに永続化するため、下記のディレクトリを作成

[root@docker ~]# mkdir -p ~/docker-data/redmine
[root@docker ~]# mkdir -p ~/docker-data/redmine-pgdata

postgresを起動する。

取得したpostgresのイメージを下記の通り実行し、起動する。

[root@docker ~]# docker run -d --name my-redmine-postgres -v ~/docker-data/redmine-pgdata:/var/lib/postgresql/data/pgdata -e PGDATA=/var/lib/postgresql/data/pgdata -e P \
OSTGRES_PASSWORD=secret -e POSTGRES_USER=redmine postgres:9.5.0

redmineを起動する。

取得したredmineのイメージを下記の通り実行し、起動する。

[root@docker ~]# docker run -d -p 3000:3000 --name my-redmine -v ~/docker-data/redmine:/usr/src/redmine/files --link my-redmine-postgres:postgres redmine:3.0.7

dockerコンテナの確認

下記の通り、dockerコンテナの状態を確認する。

[root@docker ~]# docker ps
CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS              PORTS                    NAMES
c1664f838e88        redmine:3.0.7       "/docker-entrypoint.s"   13 seconds ago      Up 4 seconds        0.0.0.0:3000->3000/tcp   my-redmine
d05693c5a8ed        postgres:9.5.0      "/docker-entrypoint.s"   34 seconds ago      Up 25 seconds       5432/tcp                 my-redmine-postgres
[root@docker ~]#

redmineの管理画面にアクセス

以下で、アクセスすると、 http://dockerホストのIP:3000

下記の通り、画面表示され、

admin/adminでログインし、

あとは、通常通り利用するredmineを利用していくだけ。

所要時間、正味10分程度で環境がredmine環境出来上がり。う～ん、便利。

CentOS7にdockerをインストールする

dockerにソフトウェアをインストールして、 いろいろ試す必要があったため、CentOS7に dockerをインストールを行った際の備忘録。

目次

OSの前提は、以下の通り。

• CentOSは最小構成でインストール（GUIなし）
• インストールしたCentOSのバージョンは、以下の通り

[root@docker ~]# cat /etc/redhat-release
CentOS Linux release 7.3.1611 (Core)
[root@docker ~]#

• firewalledとSELinuxは無効。
• dockerはyumで標準インストール

参考書籍

以下を参考にした。

CentOS 7実践ガイド

yumでdockerインストール

[root@docker ~]# yum install -y docker

dockerの起動と自動起動設定

[root@docker ~]# systemctl start docker
[root@docker ~]# systemctl enable docker
Created symlink from /etc/systemd/system/multi-user.target.wants/docker.service to /usr/lib/systemd/system/docker.service.
[root@docker ~]#

dockerのバージョン確認

[root@docker ~]# docker -v
Docker version 1.12.6, build 96d83a5/1.12.6
[root@docker ~]#

docker-composeのダウンロードと実行権限付与

[root@docker ~]# curl -L https://github.com/docker/compose/releases/download/1.3.1/docker-compose-`uname -s`-`uname -m` > /usr/local/bin/docker-compose
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   600    0   600    0     0    226      0 --:--:--  0:00:02 --:--:--   226
100 7968k  100 7968k    0     0   657k      0  0:00:12  0:00:12 --:--:--  909k
[root@docker ~]# chmod +x /usr/local/bin/docker-compose
[root@docker ~]#

こちらのコンテナ環境で、いろいろなソフトウェアの検証を行っていく。

Redmineを使ったITIL的な運用プロセス管理

に続き、日常の運用にまつわる課題をRedmineで解決できるかの検証備忘録。

目次

背景など

所属する会社（一応システム会社の情シス）では、 日々ヘルプデスク業務や問合せ業務が頻繁に発生するが、 概ね、どこにでもあるような以下の課題が発生している。

• 当事者同士の口頭・メールベースでやり取りが可視化・蓄積化されずらい。 （しかも、個人に割り当てされるメール容量が少ないため、メールを最終的には削除せざるを得ない。)

• 問い合わせに端を発し、課題管理・ 変更管理といった形でプロセス遷移していった場合、その遷移が事後的に追いづらい。 （あの件どうだったっけ？が頻発する。）

以下の参考書籍には、顧客サポート業務をRedmineを使用して行っている好例があっため、先述の課題をRedmineで改善できないかと考えたのがそもそもの発端。

入門Redmine 第5版

やりたいこと

概ね以下のような感じでやりたいことは、とてもシンプルなもの。

• 問合せ履歴の蓄積　

• ITILをイメージしたプロセス遷移

Redmineでの設定方針について

• ITILのプロセスを「トラッカー」で表現し、それぞれステータス更新させる。

• ITILにでてくるようなプロセスをすべて表現せずに、必要最小限のプロセスを実装するため、問合せ管理・インシデント管理、課題管理・変更管理プロセスをベースとする。

• 変更管理では、マネージャー承認が行われるように、ワークフロー承認（もどき）を入れる。

設定するプロセスのイメージ図

一つのチケットを様々なプロセス（Redmine上はトラッカーとして表現）遷移させる システム変更が必要な対応においては、変更管理プロセスに基づく、ワークフロー承認後、システム変更対応を実施し、完了させる。

プロセスのイメージは、下記ような感じ。

登場人物

ここで、検証するために以下のユーザーを用意する。

ユーザーID	ユーザー名称	権限
manager	管理者　太郎	承認者
staff	担当者　次郎	申請者
oahelp	OAヘルプ隆司	ヘルプデスク

ユースケース

検証を行うにあたり、以下のユースケースを前提とする。

①ヘルプデスク(oahelp)にエンドユーザーからあるアプリケーションが利用できないとの問い合わせが入る。

②ヘルプデスク(oahelp)は、問合せ内容をインフラ部門担当（staff）にエスカレーションするため、Redmineの「問合せ管理トラッカー」に問合せ内容を登録する。

③インフラ部門担当（staff）は、当該問い合わせを「インシデント管理トラッカー」にプロセス遷移させ、一次切り分けを実施する。

④インフラ部門担当（staff）は、原因をアプリケーションのメーカに問い合わせるとともに、当該チケットを「課題管理トラッカー」にプロセス遷移させ、課題管理する。

⑤インフラ部門担当（staff）は、本事象の原因がメーカ問い合わせにてわかったため、変更計画をたて、管理者（manager）の承認を得るために、「変更管理トラッカー」にプロセス遷移させ、承認依頼を行う。

⑥管理者（manager）は、変更内容を承認し、対応日を指示する。

⑦インフラ部門担当（staff）は、管理者（manager）から指示を受けた期日に対応を行う。予定通り作業を完了したため、チケットを「完了」させる。

ヘルプデスク(oahelp)の問合せ登録

①ヘルプデスク(oahelp)にエンドユーザーからあるアプリケーションが利用できないとの問い合わせが入る。

②ヘルプデスク(oahelp)は、問合せ内容をインフラ部門担当（staff）にエスカレーションするため、Redmineの「問合せ管理トラッカー」に問合せ内容を登録する。

問合せ登録を行うプロジェクトは「ITILプロセス」として、 トラッカーはこんな感じで、ITILプロセスをイメージしたもの。

ここでは、ヘルプデスク(oahelp)でログインし、「問合せ管理トラッカー」上に問合せ内容をエスカレーションのために登録する。

登録されると、下記の感じで、チケット登録される。

インフラ部門担当(staff)の「インシデント管理」

③インフラ部門担当（staff）でログインし、当該問い合わせを「インシデント管理トラッカー」にプロセス遷移させ、一次切り分けを実施する。

登録されたチケットを確認し、

ヘルプデスクからエスカレーションされたチケットを「問合せ管理」⇒「インシデント管理」トラッカーにプロセス遷移させ調査を開始する。

登録後、プロセス遷移の履歴とコメントが履歴化される。

インフラ部門担当(staff)の「課題管理」

調査が難航したため、メーカーに問合せを行うとともに、 「インシデント管理」トラッカーに登録されたチケットを 「課題管理」トラッカーにプロセス遷移し、課題管理を行う。

登録後、プロセス遷移の履歴とコメントがさらに履歴化される。

インフラ部門担当(staff)の「変更管理（承認依頼）」

メーカーからの回答を受領し、事象の原因が分かったため、 「変更管理」トラッカーにプロセス遷移させ、管理者 太郎(manager)に 変更の承認依頼を行う。

「変更管理」トラッカーに変更すると、ステータス制限のため、 承認が完了しないと、ステータス変更できない。

登録後、プロセス遷移の履歴とコメントがさらに履歴化される。

管理者 太郎(manager)の「変更管理（承認）」

管理者 太郎(manager)がログインし、インフラ部門担当(staff)からの承認依頼を承認するため チケットをクリックする。

管理者 太郎(manager)は、「変更管理」トラッカーのステータスを「承認」できるので、 承認する。さらに、対応日を3/10として指示する。

登録後、プロセス遷移の履歴とコメントがさらに履歴化される。ステータスも「承認」となる。

プロジェクトのカレンダーに対応予定日（3/10)が登録される。

インフラ部門担当(staff)の「変更管理（対応待ち）」

改めて、インフラ部門担当(staff)でログインし、承認が行われたので、 「対応待ち」ステータスに変更できるようになる。

インフラ部門担当(staff)の「変更管理（完了）」

最終的に、対応が完了したら、ステータスを「完了」に変更し、 チケットもクローズさせる。

チケットがクローズし、

いままでの登録内容が履歴化される。

以上の感じで、問合せに端を発した１つのチケットが様々なプロセス（ここではトラッカー）遷移を経ながら、 最終的には、クローズされ、その経緯もバッチリ履歴化されるため、 内容をよりシャープにさせていけば、より高精度な業務が実現できそう。

※こんな高機能のソフトウェアを無償で利用できるようにしてくれた 　開発者・コミュニティの人たちに唯々感謝するばかり。

Redmineで残業申請ワークフロー

目次

参考書籍

引き続き、以下を参照。

入門Redmine 第5版

背景など

勤務管理の厳正化が叫ばれる昨今、所属する会社でも残業申請が行わている。 概ね、以下のような残業申請の形態（一応システム会社）。

• 基本Excelでの申請台帳形式
• 申請者が事前にExcelに以下の内容を入力する。
  • ①申請日・②時間・③残業予定時間・④概要・⑤内容。
• 申請者が上司にメールする。
• 上司が内容を確認し、承認/却下とその理由も添えてExcelに記載し、回答する。
• 事後申請の場合は、申請者がその旨記載し、入力する。

こんなイメージの申請台帳

上記は、いろいろな問題をはらんでいるものの最大の問題が、

「Excelの台帳を誰かが開きっぱなしにすると、申請自体ができない」

という最も単純かつ根本的な問題に行きつき、そのわずらわしさから、申請自体がおざなりになるという事態が頻発。

改善点

上述の申請方法の改善を踏まえ、やりたいのは、概ね以下のようなもの。

• Excelに変わるいつでも申請できるインターフェースを備えている。
• 凝ったことではなく、手軽さ・シンプルさを優先する。
• 基本的に、無料。
• ちょっとしたワークフロー（もどき含む）を回せる。
• 申請の状況を一覧で把握できる。
• 事後的に、申請状況を統計・レポート化できる。

Redmineで残業申請

当初、BPMN 製品である以下の製品を調査したものの、

https://www.activiti.org/

Bonita BPMの概要 – Bonita BPM 日本語ドキュメント

どれも、機能豊富すぎて、少し手軽さに欠けたのと、 自分自身使い方もよくわからなかったため、断念。

そんな折、まさに、求めていることをやっている偉大な先人の記事を 見つけたので、記事を参考にRedmineを使い、検証をしてみることに。

Redmineで残業申請をしてみる

Redmineの設定について

以下の設定を行う。

• プロジェクトは「勤務管理」プロジェクト
• トラッカーとして、「残業申請（事前）」・「残業申請（事後）」を設定
• 「残業申請（事前）」のステータス遷移は基本的に下記の通り。
  • ①[申請者]新規
  • ②[申請者]申請中
  • ③[承認者]承認or却下
  • ④[申請者]完了
  • ⑤[承認者]確認
• 「残業申請（事後）」のステータス遷移は基本的に下記の通り。
  • ①[申請者]新規
  • ②[申請者]事後申請
  • ③[承認者]確認

申請/承認画面

申請/承認画面は若干のカスタムフィールドを追加したうえで、以下のよう感じ。

登場人物

ここで、検証するために以下のユーザーを用意する。

ユーザーID	ユーザー名称	権限
manager	管理者　太郎	承認者
staff	担当者　次郎	申請者

承認のワークフロー（もどき）

• 事前申請用のトラッカーに申請者用のステータス設定を行い、初期値は「申請中」・管理者の承認後は、「完了」ステータスに変更可能。
• 事後申請用のトラッカーに申請者用のステータス設定を行い、「事後申請」ステータスのみ変更可能。
• 事前申請用のトラッカーおよび事後申請用のトラッカーについて、承認者はすべてのステータス変更が可能。

ステータスマトリックスは、下記の感じ。

事前申請（例）

まずは、申請者でログインする。

該当のプロジェクト（ここでは[勤務管理]）を選択。

事前申請のフォームに事前申請内容を登録し、チケット作成

チケットが「申請中」で登録された

承認者でログインする。

事前申請の「未完了」クリック

登録された事前申請をクリック

承認を選択する。

承認登録する。

承認済みとして登録。

再度、申請者でログインし、該当の申請をクリックする。

予定通り、作業が完了して旨の理由及び、作業実績時間を 入力し、「完了」ステータスに変更する。

最終的な履歴。

事後申請（例）

申請者が「事後申請」ステータスにして、事後申請。

承認者が、「完了」ステータスにして、事後申請についてチクリと理由を登録する。

上記のように、RedMine使えば、Excel勤務管理台帳の代替以上のことができそう。