株式会社アイオーアーキテクトは、オープンソースなどを活用してシステム運用を最適にご提供します。

本日は、Pleasanterといノーコード、ローコードのOSSを紹介します。何かデータを纏める時にExcelを活用するかと思いますが、複数人でデータの更新したり、他のExcelのデータと連携したいとなったら、Webシステム化すると便利になってきます。そんな時にPleasanterを使うと簡単にWebシステムに出来るようになります。Plesanterとは、どんなツールかは以下のURLでご確認下さい。

https://pleasanter.org/

ここでは、Pleasanterのインストールの方法を紹介します。
インストール環境は、以下となります。
Ubuntu 22.04 LTS
PostgreSQL 14.7
Nginx 1.18
Pleasanter 1.3.37

(1).Netパッケージの削除

# apt upgrade
# apt remove 'dotnet*' 'aspnet*' 'netstandard*'
# vi /etc/apt/preferences
---
Package: dotnet* aspnet* netstandard*
Pin: origin "packages.microsoft.com"
Pin-Priority: -10
---

(2).NETをスクリプトでインストール

# wget https://dot.net/v1/dotnet-install.sh -O dotnet-install.sh
# chmod +x ./dotnet-install.sh
# ./dotnet-install.sh -i /usr/local/bin

(3)GDI+のインストール

# apt install -y libgdiplus

(4)PostgreSQLのインストール

# apt -y install vim bash-completion
# wget --quiet -O - https://www.postgresql.org/media/keys/ACCC4CF8.asc | sudo apt-key add
# echo "deb http://apt.postgresql.org/pub/repos/apt/ `lsb_release -cs`-pgdg main" |sudo tee /etc/apt/sources.list.d/pgdg.list

# apt install -y postgresql-14 postgresql-client-14
# cd /etc/postgresql/14/main/

PostgreSQLの認証方式の設定
# cp -ip pg_hba.conf pg_hba.conf.20230509

# vi pg_hba.conf
METHODの設定を以下のように修正する。
----
# IPv4 local connections:
host all all 127.0.0.1/32 scram-sha-256→md5
# IPv6 local connections:
host all all ::1/128 scram-sha-256→md5
# Allow replication connections from localhost, by a user with the
# replication privilege.
local replication all peer
host replication all 127.0.0.1/32 scram-sha-256→md5
host replication all ::1/128 scram-sha-256→md5
----

PostgreSQLのログ出力設定
# cp -ip postgresql.conf postgresql.conf.20230509

# vi postgresql.conf
以下のように修正する。
-----
log_destination = 'stderr'
logging_collector = on
log_line_prefix = '[%t]%u %d %p[%l]'
-----

PostgreSQLのサービス再起動、サービス化
# systemctl restart postgresql
# systemctl enable postgresql
Synchronizing state of postgresql.service with SysV service script with /lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install enable postgresql

PostgreSQLユーザの設定
PostgreSQL管理用のユーザー"postgres"(OSのユーザー)にパスワードを設定します。
# passwd postgres
New password:　←パスワード
Retype new password:　←パスワード
passwd: password updated successfully

# su – postgres
$ psql -U postgres
psql (14.3 (Ubuntu 14.3-0ubuntu0.22.04.1))
Type "help" for help.

postgres=#

PostgreSQLの管理ユーザー "postgres" のパスワードを設定
postgres=# alter role postgres with password 'パスワード';
ALTER ROLE

プリザンター用のデータベース "Implem.Pleasanter" を作成します。
postgres=# create database "Implem.Pleasanter";
CREATE DATABASE

以下のコマンドで作成したDBの確認を行います。
postgres=# \l
List of databases
Name | Owner | Encoding | Collate | Ctype | Access privileges
-------------------+----------+----------+-------------+-------------+-----------------------
Implem.Pleasanter | postgres | UTF8 | en_US.UTF-8 | en_US.UTF-8 |
postgres | postgres | UTF8 | en_US.UTF-8 | en_US.UTF-8 |
template0 | postgres | UTF8 | en_US.UTF-8 | en_US.UTF-8 | =c/postgres +
| | | | | postgres=CTc/postgres
template1 | postgres | UTF8 | en_US.UTF-8 | en_US.UTF-8 | =c/postgres +
| | | | | postgres=CTc/postgres
(4 rows)

全文検索用モジュール（pg_trgm）のインストール
テキストの全⽂検索に必要なモジュール（pg_trgm）をインストールします。
postgres=# \c "Implem.Pleasanter"
Implem.Pleasanter=# create extension pg_trgm;

(5)Pleasanter1.3.37をインストール

#　 wget https://github.com/Implem/Implem.Pleasanter/releases/download/Pleasanter_1.3.37.3/Pleasanter_1.3.37.3.zip
# apt install -y unzip
＃ unzip Pleasanter_1.3.37.3.zip
# mkdir /web
# mv pleasanter/ /web/.

# cd /web/pleasanter/Implem.Pleasanter/App_Data/Parameters
# cp -ip Rds.json Rds.json.20230509
# vi Rds.json
以下を修正する。
---
{
"Dbms": "PostgreSQL",
"Provider": "Local",
"TimeZoneInfo": "Asia/Tokyo",　←追記
"SaConnectionString": "Server=localhost;Database=postgres;UID=postgres;PWD=パスワード",　←修正
"OwnerConnectionString": "Server=localhost;Database=#ServiceName#;UID=#ServiceName#_Owner;PWD=SetAdminsPWD",
"UserConnectionString": "Server=localhost;Database=#ServiceName#;UID=#ServiceName#_User;PWD=SetUsersPWD",
"SqlCommandTimeOut": 600,　←修正
"MinimumTime": 3,
"DeadlockRetryCount": 4,
"DeadlockRetryInterval": 1000,
"DisableIndexChangeDetection": true
}
---

(6)CodeDefinerの実行

# cd /web/pleasanter/Implem.CodeDefiner
# dotnet Implem.CodeDefiner.dll _rds
<INFO>が多数表示され、最後に以下が標準出力されることを確認する。
<SUCCESS> Starter.ConfigureDatabase: Database configuration has been completed.
<SUCCESS> Starter.Main: All of the processes have been completed.

(7)Pleasnterの起動確認

# cd /web/pleasanter/Implem.Pleasanter
# dotnet Implem.Pleasanter.dll

以下のコマンドで動作確認したら、「Ctrl+C」で終了します。

別のターミナルで以下のコマンドを実行し、プリザンターが起動していることを確認します。
# curl -v http://localhost:5000/
* Trying 127.0.0.1:5000...
* Connected to localhost (127.0.0.1) port 5000 (#0)
> GET / HTTP/1.1
> Host: localhost:5000
> User-Agent: curl/7.81.0
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 302 Found
< Content-Length: 0
< Date: Tue, 07 Jun 2022 04:59:38 GMT
< Server: Kestrel
< Location: http://localhost:5000/users/login?ReturnUrl=%2F
< X-Frame-Options: SAMEORIGIN
< X-XSS-Protection: 1; mode=block
< X-Content-Type-Options: nosniff
<
* Connection #0 to host localhost left intact

(8)Pleasanterサービス用スクリプトの作成

/etc/systemd/system/pleasanter.service を以下の内容で新規作成します。
# vi /etc/systemd/system/pleasanter.service
---
[Unit]
Description = Pleasanter
Documentation =
Wants=network.target
After=network.target

[Service]
ExecStart = /usr/bin/dotnet Implem.Pleasanter.dll
WorkingDirectory = /web/pleasanter/Implem.Pleasanter
Restart = always
RestartSec = 10
KillSignal=SIGINT
SyslogIdentifier=dotnet-pleasanter
User = root
Group = root
Environment=ASPNETCORE_ENVIRONMENT=Production
Environment=DOTNET_PRINT_TELEMETRY_MESSAGE=false

[Install]
WantedBy = multi-user.target
---

(9)サービスとして登録・サービスの起動

# systemctl daemon-reload
# systemctl enable pleasanter
Created symlink /etc/systemd/system/multi-user.target.wants/pleasanter.service → /etc/systemd/system/pleasanter.service.
# systemctl start pleasanter

(10)リバースプロキシ（NginX）のセットアップ

# apt install -y nginx
# systemctl enable nginx

# vi /etc/nginx/conf.d/pleasanter.conf
---
server {
listen 80;
server_name 192.168.X.X;
client_max_body_size 100M;
location / {
proxy_pass http://localhost:5000;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection keep-alive;
proxy_set_header Host $host;
proxy_cache_bypass $http_upgrade;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
}
---

# systemctl restart nginx

(11)Pleasanterにログイン
以下のURLからログインします。
http://XX.XX.X.X/users/login
ID: Administrator
PW: pleasanter（初期パスワード）

参考URL；　https://pleasanter.org/manual/getting-started-pleasanter-ubuntu

Ubuntu 24.04だと、OTRSのフォークであるZnunyは公式レポジトリに登録されています。

$ lsb_release -d
Description: Ubuntu 22.04 LTS

$ apt search znuny
Sorting... Done
Full Text Search... Done 
otrs2/jammy 6.2.2-2 all
Open Ticket Request System Znuny

ご存知のかたもいらっしゃると思いますが、OTRSはオープンソースからプロプライエタリへと切り替わったため、後継としてznunyが採用となったというところでしょうか。otrs2というパッケージ名にそんな含みを感じます。

なお、2022/06/24時点でのZnunyの最新版は6.3.4となります。やや古いバージョンですし、6.2.xはLTS扱いではありません(現時点では6.0/次のLTSは6.5予定がZnunyとしてのLTS扱いです)ので本番用途にはあまりお勧めできませんが、とりあえず触ってみる分には問題ないかと思います。

Znunyのロードマップが更新されています。

https://www.znuny.org/en/roadmap

現時点では6.0.44と6.3.2が最新でざっくりいうと6.0が今年いっぱいで次のLTSが6.5で2024年いっぱいとなります。

6.3等の6.x系は原則次のリリースまでとなっています。これまでの実績から考えるとだいたい3～4ヶ月となります。

• 6.0 LTS (リリース済み): EOL 22末 or 6.5リリースまで
• 6.3.2(リリース済み): EOL:6.4リリースまで

• 6.4 : 6～7月リリース予定　EOL: 6.5リリースまで
• 6.5 LTS: 2022Q4 or 2023Q1(2022末or2023年初)  EOL: 2024/12/31
• 7 : 2023 Q1予定

EOLが明示されるのはありがたいのですが、期間がちょっと短いなぁ..

今回は開発者向けのおはなしです。

お遊びでVue.js触ろうと思って、vue-cliでプロジェクトのscaffoldを作成したのですが、ホットリロードが効かない。ググると結構あるあるのようです。ただ、スタックのバージョンによってころころ変わるようで、ググった限りで同じ方法で解決している方いらっしゃらなかったのでメモ兼ねてご紹介しておきます。

スタックは以下の通り。2022/5/15時点の組み合わせです。

• nodejs: 18.1.0
• npm: 8.8.0
• @vue/cli : 5.0.4
• vue: 3.2.33

Node.jsはWSL上で動かしてブラウザはWindows側です。

結論から行くと、vue.config.jsを以下のように編集。

const { defineConfig } = require('@vue/cli-service')
module.exports = defineConfig({
  transpileDependencies: true,
  configureWebpack: {
    watchOptions :{
      aggregateTimeout: 300,
      poll: 1000
    }
  }
})

私の環境ではこの設定でホットリロードかかるようになりました。

ググって試したのを書いておくと、

https://qiita.com/ntm718/items/6023b0063f78d53192a1

module.exports = {
  configureWebpack: {
    devServer: {
      watchOptions: {
        poll: true
      }
    }
  }
}

defineConfigがないので合わず。

https://www.miracleave.co.jp/contents/1333/post-1333/

module.exports = defineConfig({
  transpileDependencies: true,
  configureWebpack: {
    watch: true
  }
})

[DEP_WEBPACK_WATCH_WITHOUT_CALLBACK] DeprecationWarning: A ‘callback’ argument needs to be provided～みたいな警告が出て、起動はするものの効かず。

https://stackoverflow.com/questions/53589853/vue-cli-3-hot-reload-suddenly-not-working-in-browsers

やっぱだめ

module.exports = defineConfig({
  transpileDependencies: true,
  devServer: {
    watchOptions: {
      poll: true
    }
  }
})

Invalid optionsで起動せず。

webpackまわりっぽいので、そっちで調べて

https://github.com/vuejs-templates/webpack/issues/432

あたりからこれまでのいくつかの設定方法を組み合わせて冒頭の設定に行き着きました。

スタックが大きいと厄介ですねぇ。ともあれこれまでの対応を残してくださってる皆様に感謝です。

　ジョブ管理ソフトウェアというと、SenjuやJP1を思い浮かべる方が多いかと思います。でも、費用が高いので、もう少し廉価にジョブ管理が出来ないかと、オープンソースを探すとHinemosやJS7が出てきます。私は、どの製品も触ったことがありますが、どれも一長一短があると認識しています。その中でも弊社で取扱いの多いOTRSと親和性のあるJobScheduerと連携して、リリース管理システムを構築したことのある最近のJobScheduerについてご紹介します。

　最近のJobSchedulerは、2021年7月にJS7® JobScheduler V.2.0.0としてブランド名を変えてリリース致しました。これまでとは、JobSchedulerコントローラ、エージェント、JOCコックピットが一新されました。以下、JS7® JobScheduler V.2.0.0を「JS7」と言います。まず、JS7を簡単に紹介します。

JS7の動作環境

　ジョブを実行する対象サーバは、以下のプラットフォームに対応しています。

JS7のメリット

JS7の導入メリットは以下の2点考えられます。

(1)プログラマブルな管理が可能
ジョブの定義は、プログラミングすることで実現できます。対応言語は、他言語対応（Java, Perl, JavaScript, VBScript, Powershell, シェル等）しており、プログラマブルに定義する特徴があります。従って、外部のOSSから動的にジョブを投入、定義したい時などは、お勧めなOSSとなっております。
(2)プロダクトの保守サポート費が安価

詳しくは、OSSラボ株式会社のサイトをご覧ください。（こちら）

開発環境でdockerを使っているとだんだんイメージ、コンテナが増えてきていざ整理しようとすると収集がつかなくなることが多々あります。イメージは階層構造をとるため、「こいつは一体どのイメージから参照されているのか？消していいものなのか？」と悩むことになりがちです。

皆考えることは似たようなもので以前グラフ表示をしてくれるツールを使っていたのですが名前がわからなくなってしまったのでさらっと作ってしまいました。

グラフ表示は自力でやると大変ですのでCytoscape.jsというライブラリにお世話になることにします。グラフ表示といっても棒グラフや折れ線グラフのほうではなく、依存関係を表す有向グラフの方です。これを使うと有向グラフをいい感じに表示してくれます。ということで、こんな感じのグラフを(比較的)簡単に表示できます。

画像から想像つくかもしれませんが、拡大・縮小や、ノードの位置の移動などもCytoscape.jsがよろしくやってくれます。実際の画面も置いておきますので、気になる方は触ってみてください。

Cytoscape.jsが動いてる画面サンプル

※ 画面サンプルは少し加工してスタティックなHTMLにしていますのでdockerからデータは取ってきていません

ニーズがあるかどうかはわかりませんがせっかくなのでソースはgithubに置いておくことにします。

docker-graph -Show dependency graph of docker images/containers

こちらはコンテナやイメージの状態を取得してそれに応じた表示をしてくれます。

ネタとして今回はdockerのイメージを使いましたがCytoscape.jsは結構使いでがあるライブラリで、構成管理などで複雑な依存関係がある場合などにわかりやすく表示するなど、色々用途が考えられます。時間とやる気ができたらOTOBO/Znuny上で実装するかもしれません。

弊社のサポートサイトでも(当然ながら?)OTOBOを使用しており、問い合わせの管理だけではなくお客様向けのナレッジベース(FAQ)もOTOBOの機能を使って公開しています。

現状ですとOTRSの保守契約を頂いているお客様、OTOBOの保守契約を頂いているお客様それぞれ向けのFAQを限定公開しているのですが、記事一覧で権限のない記事のタイトルが表示される問題が確認されました。

詳細を追うとOTOBOで顧客インタフェースにかなり手を入れており、その中でのエンバグのようで、OTRSでは発生していなかった問題となります。

タイトルのみで記事そのものは見えないこと、(弊社の場合)情報の性格上機密となるような情報はないのですが気持ちが悪いため、内容も鑑みて修正を行いました。

これについては多分困っている他のOTOBOユーザーもいるでしょうから、合わせて本家のほうにプルリクエストを送っておきました。現時点で先方の動きはないですが、コードの修正がそのまま取り込まれるかはともかくとして不具合の修正は将来のバージョンで行われるかと思います。

https://github.com/RotherOSS/FAQ/pull/12

他社はわかりませんが弊社の場合、ソースはがしがし読みます(がしがし直すと収集つかなくなるので((いつくしま))で直します)。感覚的なものですがこれまでの10年ほどでOTRSも含めれば全体の6,7割(以上)は見てきたんじゃないかと思います。コードベースで動きを押さえて必要なら修正依頼かけることができるのがOSSの良いところですね。

余談ですが、Web会議なのをいいことに、「XXはこういうことできますか？」という質問に対して裏でコード調べて「それはできます」と答えるなんてことをちょこちょことやっていたり、いなかったりします。黙っているからといって寝てませんよ:-)

OTRSはヘルプデスクが発祥ですが、追加モジュールを導入することによりITILに基づく運用管理を行うことができるようになります。
これら運用管理系の追加モジュールを総称してITSMと呼んでいます。

ITSMの機能についてもお試しいただけるようにDockerHubにてDockerイメージを公開しました。
https://hub.docker.com/r/ioarchitectjp/otrs5_itsm_jp/

以下のようにしてITSM入りのOTRSをお試しいただけます。先に公開したotrs5_helpdesk_jpにITSMモジュールを追加したものですので、アカウント情報などについてはそちらのラボノートも参照ください。

取得方法・起動方法はhelpdeskの時とほぼ同じです。

# docker pull ioarchitectjp/otrs5_itsm_jp
# docker run -p 8081:80 -d ioarchitectjp/otrs5_itsm_jp

ITSMでは以下の機能が追加されます。

・構成管理
・変更管理
・サービスレベル管理
・インシデント問題管理

また、Helpdeskの追加モジュールである以下のモジュールもついでに追加しています。

・FAQ
・アンケート(Survey)
・稼働時間管理

画面はITSMでの管理画面です。

ITSMなしの場合(Helpdesk)も並べておきます。画面上部のメニューの項目と、設定項目が増えているのが見て取れるのではないかと思います。

細かい使い方・機能紹介については追ってラボノートにてご紹介していく予定です。

Dockerイメージで公開しているOTRSのデモ版ですが、OTRSのバージョンを5.0.11に更新しました。

前が5.0.9でしたので1個飛ばしになってます。リリースノートは以下を参照ください(英語です)

Release Notes: OTRS 5 Patch Level 11
Release Notes: OTRS 5 Patch Level 10

OTRSは結構活発にアップデートされています。今回はマイナーバージョンアップですのでそれほど目立った変化はありませんが、どうせ試すなら新しいもので試したいですよね。

イメージはDockerHubから取得できます。

なるべく本家の更新についていけるように頑張ります。
あとはITSMモジュール等は鋭意追加していきたいところではあります。こちらはしばしお待ち下さい。

DockerHubで公開しているOTRS評価用のイメージですが、複数メンバーで機能強化したいということもあり、イメージのパスを変更しました。

旧: hirami/otrs5_helpdesk_jp
新: ioarchitectjp/otrs5_helpdesk_jp

位置付け的には私個人のレポジトリから、弊社の公式(?)レポジトリに移動という形になります。

既存のイメージでお試しされている分について影響は出ないと思いますが、今後OTRSの色々な機能を試せるような強化・改良は新の方に対して行われることになります。新のほうもよろしくお願いいたします。

DockerHubに公開しているDockerイメージを更新しました。今回の目玉はメール送受信機能がすぐに試せるようになっている点です。

OTRSはメールと連携させてこそその本領を発揮するアプリです。通常ですとメールアカウントを用意したりOTRS側の設定をしたりと一手間かかるのですが、事前設定済みのDockerイメージを使ってサクッと試してみてください。

まず最初にDockerイメージを取得もしくは更新してください。取得方法については以前ラボノートに書いた内容と変わっていません。そちらを参照してください。

まずはお客様からの問い合わせがあった(つもり)として、OTRSにメールを投げて見ましょう。
このイメージではウェブメーラーを同梱していますので、お使いのPCでの設定は不要です。

http://<DockerホストのIPアドレス>:8080/webmail
にアクセスしてログインしてください。IDはcust01、パスワードもcust01でログインできるようになっています。

ログインしたら、”Compose”を押してメールを作成してください。メールの宛先は、helpdesk@eval-mail.local.domain としてください。

このアドレスがOTRSに紐づけられている問い合わせ受付用のメールアドレスとなっています。
“Send”を押すとメールが送られます。

さて、いよいよOTRSの出番です。サポート担当者となった(つもり)で、OTRSにログインしてみてください。

http://<DockerホストのIPアドレス>:8080/otrs/index.pl
本当はちゃんとアカウントを作るのが正しい使い方なのですが、とりあえず今回は root@localhost でログインしてみましょう。初期のパスワードは otrs-ioa です。

どうですか？ お客様からの問い合わせメールが届いているのではないかと思います。届いていないようでしたらしばらくお待ちください。OTRSでは定期的にメールをチェックして取り込むようになっています。5〜10分ほどかかる場合があります。

問い合わせメールはチケットとしてOTRS上に起票されています。届いたメールはOTRSが自動的に判断し、新規であれば番号が採番され、それ以降はチケット番号で管理することができます。

さて、問い合わせが来ているのですから返事をしないといけませんね。チケットを開いて、画面中央の”返信”を選択してください。プルダウンで”empty response”という項目があると思いますのでそれを選択すると、返答用のフォームが開きます。ブラウザによってはポップアップがブロックされる場合がありますので許可してください。

何か適当な文面を作って”メール送信”を押してみてください。

チケットに送信履歴が記録されます。
複数のメンバーでサポートをしている場合でも、いったい誰が、いつ、どんな内容をやり取りしたのかを一覧することができます。また、本記事では触れませんが、お客様への返信前にサポートメンバー内部で対応を協議したり、後ろに控えている二次受付メンバーにチケットの処理を任せたりといったことも可能です。

ここで一旦顧客に戻って、ウェブメーラーを開いてみてください。先ほどOTRSで送信した内容がメールとして届いていると思います。差出人はヘルプデスクのアドレスとなっていますので、途中まで対応していたメンバーがお休みといったような場合でも別の誰かが対応したりといったことが容易になっています。

このメールにさらに返信すると、OTRSはチケット番号を自動識別して、同一チケットに紐づけてくれます。実際に返信してみたり、別の新規メールを送ってみたりしてみてください。

また、Webメーラでアカウント cust02 パスワード cust02 で別のお客様となることもできます。
どんな見え方をするかを試してみるのも良いかと思います。

OTRSを使った問い合わせ対応はこのような感じで行われます。実際の業務では複数のメールアドレスを使ってもう少し細かく振り分けたり、フィールドを追加してもっと細かく情報管理したりと色々と設定を行っていく場合がほとんどですが、とりあえずメールのやり取りのイメージは持っていただけるのではないかと思います。

DockerでOTRSをインストールせずに評価する のラボノートでDockerを使ったOTRSの動かし方を書いたのですが、「Dockerの入ったマシン？そんなの用意できないよ〜」といった声が聞こえてきました。

そういう時はAWSで動かしてしまうのが楽です。
AWSではDockerをサービスとして利用できるそのものズバリのEC2 Container Serviceというものもありますが、VPC一式作りに行ったりと評価にはちょっと大げさな気がします。ですが、Dockerは普通のEC2インスタンスでも簡単に動かすことができます。

まずEC2でインスタンスを1個作ります。OSはAmazon Linuxが良いでしょう。
立ち上がったらログインして、dockerをインストールします。と言っても3つコマンドを叩くだけです。

$ sudo yum install -y docker
$ sudo service docker start
$ sudo chkconfig docker on

これでもうDockerが使える状態になります。次に先の記事の通りにOTRSのDockerイメージを取ってきて実行です。

$ sudo docker pull ioarchitectjp/otrs5_helpdesk_jp
$ sudo docker run -d -p 8080:80 ioarchitectjp/otrs5_helpdesk_jp

あとはブラウザからアクセスすれば晴れてOTRSが使えるようになります。簡単ですね。

ちなみにもしEC2インスタンスを再起動した場合にはDockerコンテナも手動で立ち上げてあげる必要があります。

$ sudo docker ps -a
CONTAINER ID        IMAGE                                COMMAND             CREATED             STATUS                      PORTS                  NAMES
50e146436b7b        docker.io/ioarchitectjp/otrs5_helpdesk_jp   "/otrs.sh"          15 hours ago        Up 15 hours                 0.0.0.0:8080->80/tcp   ecstatic_khorana

とやって、IMAGEがotrs5_helpdesk_jpのCONTAINER IDを控えておきます。ここだと50e146436b7bですね。

そのIDを指定して、docker startとすればまたOTRSが使えるようになります。

 
$ sudo docker start 50e146436b7b

dockerの機能は色々とありますが、OTRSの評価に使う分にはこれぐらい知っておけば十分です。是非お気軽にお試しください。

「Dockerネタばっかりでたまには弊社主力プロダクトのOTRSの話もせんか！」という声がどこからか聞こえてきたのでたまにはOTRSネタですw

OTRSのインストール方法については弊社のもの含めて幾つか出回っていますが、「インストール面倒臭い」と思われる方もいらっしゃるかもしれません。

というわけで、OTRSのDockerイメージを用意してみました(またDockerネタに戻るという..)。
Docker Hubで公開しましたので、Dockerがインストールされているマシンがあればコマンド2発でOTRSをお試しいただけます。

$ docker pull ioarchitectjp/otrs5_helpdesk_jp
$ docker run -d -p 8080:80 docker.io/ioarchitectjp/otrs5_helpdesk_jp

以上です。

あとは

http://[IPアドレス]:8080/otrs/index.pl

にアクセスすれば、OTRSにログインできます。
初期状態では以下のアカウントが有効になっていますので、こちらでログインしてユーザーを作ってください。
ID: root@localhost
PW: otrs-ioa

DBをDocker上に置いているのでパフォーマンス面で不利だったり、バックアップ等本番で必須となるであろう処理を省略していたりしますので本番としての運用はお勧めしませんが、とりあえず簡単にOTRSを試してみるという点では十分かと思います。

本格的に使いたい、どう使っていけばいいのか相談したいという場合には是非弊社にお声がけください ：-P

※ 2016/6/24 Dockerイメージのパスを修正しました

いつぞやDockerをバージョンアップして動かなくなるという記事を書いたのですが、またやってしまいました(汗)

CentOS7の環境です。

$ cat /etc/redhat-release 
CentOS Linux release 7.2.1511 (Core) 

思わずyum updateをやって再起動をかけて、docker psをしたら、

$ docker ps
Cannot connect to the Docker daemon. Is the docker daemon running on this host?

とつれない返事。

/var/log/messagesを見ると、

Apr 13 21:51:43 docker02 systemd: Starting Docker Application Container Engine...
Apr 13 21:51:43 docker02 journal: Forwarding stdin to journald using Priority Informational and tag docker
Apr 13 21:51:43 docker02 kernel: device-mapper: table: 253:6: thin: Couldn't open thin internal device
Apr 13 21:51:43 docker02 kernel: device-mapper: ioctl: error adding target to table
Apr 13 21:51:43 docker02 journal: time="2016-04-13T21:51:43.332220800+09:00" level=fatal msg="Error starting daemon: error initializing graphdriver: Could not query and save base device UUID:Error running deviceCreate (ActivateDevice) dm_task_run failed"

あらぁ。またやっちまったぁ。ということでググることしばし..

https://bugs.centos.org/view.php?id=8960

あたりを参考にして、/etc/sysconfig/docker-storageのDOCKER_STORAGE_OPTIONSの内容をクリアします。

#DOCKER_STORAGE_OPTIONS="--storage-driver devicemapper --storage-opt dm.fs=xfs --storage-opt dm.thinpooldev=/dev/mapper/centos-docker--pool --storage-opt dm.use_deferred_removal=true --storage-opt dm.use_deferred_deletion=true "
DOCKER_STORAGE_OPTIONS=""

systemctl start dockerでなんとか上がってくれました。

$ docker ps 
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES

docker ps -a で使っていたイメージも一応無事そうです。

どうもCentOSだとバージョンアップ時に色々トラブル出ます > docker
私だけでしょうかorz
プロダクションでもdockerを入れると有効な局面はいくつか見てきているのですが、うーん。
セキュリティ関連面でパッケージをupdateしないというのは問題ありますし、dockerだけ上げないとしてもdocker(というかLXC)はカーネルと密接に関連する部分がありますので多分kernelのアップデートも止めないと何か問題が出てきそうです。ただkernelのアップデートをしないのはそれで問題ありそうですし..
ちょっと悩ましいところです。

あ、バージョンアップ後のdockerは、

$ rpm -qi docker
Name        : docker
Version     : 1.9.1
Release     : 25.el7.centos
Architecture: x86_64
...

です。上げる前のバージョンは残念ながら控えていませんが前回のラボノートあたりの頃のバージョンです。

またやっちまったぜ、ということでネタにしておきます。

＜openMAINTのインストール手順＞

openMAINTは資産管理に特化したソフトウェアです。ソフトウェア概要は、過去のブログ記事をご参考下さい。ここでは、openMAINTの操作感を確認するための環境を構築する手順を紹介します。

CentOS7
PostgreSQL9.4
Tomcat7
JDK1.6

（１）Oracle JDK1.6のインストール

openMAINT1.0はOracle JDK1.6を推奨しているので、こちらのバージョンをインストールします。

# sh jdk-6u45-linux-x64-rpm.bin
Unpacking...
Checksumming...
Extracting...
UnZipSFX 5.50 of 17 February 2002, by Info-ZIP (Zip-Bugs@lists.wku.edu).
inflating: jdk-6u45-linux-amd64.rpm
inflating: sun-javadb-common-10.6.2-1.1.i386.rpm
inflating: sun-javadb-core-10.6.2-1.1.i386.rpm
inflating: sun-javadb-client-10.6.2-1.1.i386.rpm
inflating: sun-javadb-demo-10.6.2-1.1.i386.rpm
inflating: sun-javadb-docs-10.6.2-1.1.i386.rpm
inflating: sun-javadb-javadoc-10.6.2-1.1.i386.rpm
Preparing... ########################################### [100%]
1:jdk ########################################### [100%]
Unpacking JAR files...
rt.jar...
jsse.jar...
charsets.jar...
tools.jar...
localedata.jar...
plugin.jar...
javaws.jar...
deploy.jar...
warning: %post(jdk-2000:1.6.0_45-fcs.x86_64) scriptlet failed, exit status 5
Installing JavaDB
Preparing... ########################################### [100%]
1:sun-javadb-common ########################################### [ 17%]
2:sun-javadb-core ########################################### [ 33%]
3:sun-javadb-client ########################################### [ 50%]
4:sun-javadb-demo ########################################### [ 67%]
5:sun-javadb-docs ########################################### [ 83%]
6:sun-javadb-javadoc ########################################### [100%]
Done.
<pre>

現状ではCentOS標準レポジトリ内のOpenJDKが優先されているため、インストールしたOracle JDKに切り替えを行う。

# alternatives --install /usr/bin/java java /usr/java/jdk1.6.0_45/bin/java 300
# alternatives --config java
There are 3 programs which provide 'java'.
  Selection    Command
-----------------------------------------------
*+  1           /usr/java/jdk1.6.0_45/bin/java
Enter to keep the current selection[+], or type selection number: 		← "1"(jdk1.6.0_45)を入力

（２）PostgreSQLのインストール

PostgreSQLをpostgres.orgよりインストールします。

# rpm -ivh http://yum.postgresql.org/9.4/redhat/rhel-7-x86_64/pgdg-centos94-9.4-1.noarch.rpm
# yum --disableplugin=priorities install -y postgresql94-server postgresql94-devel

導入後・DBを初期化する。

# /usr/pgsql-9.4/bin/postgresql94-setup initdb

起動時設定を行う。

# systemctl start postgresql-9.4
# systemctl enable postgresql-9.4

管理者ユーザにパスワードを設定する。

# su - postgres
# psql
psql (9.4.1)
Type "help" for help.
postgres=# alter role postgres password '<DB管理者パスワード>';
ALTER ROLE
postgres=# \q
-bash-4.2$ exit

接続時のアクセス制御設定を変更する。

# vi /var/lib/pgsql/9.4/data/pg_hba.conf
# "local" is for Unix domain socket connections only
local   all             all                                     md5  # <- 変更
# IPv4 local connections:
host    all             all             127.0.0.1/32            md5  # <- 変更
# IPv6 local connections:
host    all             all             ::1/128                 md5  # <- 変更

変更を反映します。

# systemctl restart postgresql-9.4

（３）Tomcat7のインストール

Tomcatをインストールし、設定を修正します。

# yum install -y tomcat

以下の4点を修正します。

JAVA_HOME="/usr/java/jdk1.6.0_45"
JAVA_OPTS="-Dfile.encoding=UTF8 -Xms256m -Xmx1024m -XX:MaxPermSize=256M -server"
TOMCAT_USER="root"
LANG="ja_JP.UTF-8"

（４）JDBCのインストール

PostgreSQL9.4のJDBCドライバをインストールします。

# wget http://jdbc.postgresql.org/download/postgresql-9.4-1200.jdbc4.jar
# cp postgresql-9.4-1200.jdbc4.jar /usr/share/tomcat/lib/

（５）サービススクリプトの修正

サービススクリプトの実行ユーザを変更します。

<pre># vi /usr/lib/systemd/system/tomcat.service
User=root				← rootに修正
Group=root				← rootに修正

（６）tocmatの起動設定を行う。

# systemctl enable tomcat
# systemctl start tomcat

（７）CMDBuildのインストール
以下のURLよりパッケージをダウンローし、配布物を展開後、Jarをtomcatのwebapps以下に配備する。
https://sourceforge.net/projects/openmaint/files/latest/download

# unzip openmaint-1.0-2.3.1.zip
# cd openmaint-1.0-2.3.1/
# cp openmaint-1.0-2.3.1.war /usr/share/tomcat/webapps/openmaint.war
# systemctl restart tomcat

これでインストール完了です。

（８）openMAINTの初期設定
ブラウザでopenMAINTにアクセスし、初期設定を行う。URLは以下の通り。
http://<サーバのIP>:8080/openmaint/

初回起動時にはセットアップの画面に自動的に遷移する。
Choose Default languagesで”日本語”を選択。Show languages selection in login boxにチェックを入れ、Nextを選択する。

データベース設定については以下の値を入力する。

CMDBuildデータベースタイプ : “デモ”
データベース名 : “cmdbuild”
Sharkスキーマを作成 : チェックを入れる
ホスト: “localhost”
ポート: “5432”
スーパーユーザー: “postgres”
パスワード:
ユーザタイプ: “スーパーユーザ”

入力後、”テスト接続”ボタンを押し以下の接続成功の画面が表示されることを確認。”完了”でダイアログを閉じる。

データベースの設定が完了すると、以下の画面が表示される。OKを押下します。

データベースの設定が完了すると、以下の画面が表示されます。管理者名：admin、管理者パスワード：adminでログインします。

＜資産管理ソフトウェア：　openMAINTの紹介＞

openMAINTは、建物、設備、可動資産および関連の維持活動を管理するための資産管理のオープンソースです。CMDBuild（構成管理のOSS）をベースにイタリアのTecnoteca社により開発されたソフトウェアです。本ソフトウェアはオープンソースとしてAGPL v3ライセンスで公開されています。使用感は、以下の動画（英語版）を見るとイメージできるかと思います。

openMAINT：　 http://www.openmaint.org/en?set_language=en

Tecnoteca社：　http://www.tecnoteca.com/en

ソフトウェアダウンロード：　https://sourceforge.net/projects/openmaint/files/latest/download

ソフトウェアの機能：　http://www.openmaint.org/en/documentation/online-demo-overview

プレゼン資料：　http://www.slideshare.net/openmaint/slide-openmaint-eng?ref=

インストール手順：　http://192.168.3.100/wp/archives/date/2015/04/

＜新着情報＞　2015年5月15日にopenMAINTの最新バージョンは、1.0がリリースされました。
ライセンス　AGPLv3

（１）openMAINTで管理できること
①スペース＆アセット・インベントリ
インベントリすることを可能にし、具体的なワークフローやレポートを管理します：
・集合住宅、建物、フロア、部屋
・設備（電気工場、水道、暖房/空調システム等排水システム、セキュリティ、データ伝送）
・上記の植物に属する技術的な資産
・家具
・外部インフラ（道路網、サイクルレーン、照明など）及び緑地（庭園、公園、など）
②ファシリティ＆環境
③ロジスティック管理
④経済管理
⑤GIS＆BIMのサポート

（２）openMAINTの機能
機能は、CMDBuildと殆ど同じように利用することになります。

①資産情報の管理
・資産情報の種類を複数作成（削除不可）
・資産情報間のリレーションの作成
・資産情報間のリレーションをグラフ表示（４階層まで）
・資産情報ごとにアクセス権限付与
・資産情報の情報を検索
・資産情報をCSVインポート、エクスポート
・リレーションの属性を定義

②Web管理者コンソール（ユーザー／管理モジュール）

③Webサービス（SOAPインターフェース）
・OCS Inventory NGと連携することで、リポジトリ情報の自動取得をCIに
自動インポートする事が出来ます。
・OTRSと連携することで、インシデントとの紐付けが出来ます。

推奨の動作環境
CMDBuildは、以下のソフトウェアにより動作します。
・Tomcat 7
・PostgreSQL 9.3
・OS：　CentOS6/7,Redhat Enterprise Linux 6/7
・JDK：　1.6
・メモリ：　8GB
・ディスク：　120GB

弊社では開発環境の一部にdockerを使っています。
さすがにインフラ系が絡む部分があるので準本番(ステージング)は仮想マシン直上に置きますが、開発や検証の場合、dockerによるスナップショットは開発・検証効率の向上にかなり効きます。
とはいえdockerもノートラブルというわけではないので焦ることもなくはないです。たまたま出くわしましたのでメモ兼ねてご紹介します。

OSはCentOS6、dockerはEPELの1.0を使っていて、「そろそろアップデートしとかないとな〜」といった軽いノリで、yum update docker-ioとか掛けてしまいました。

$ yum info docker-io
Name        : docker-io
Arch        : x86_64
Version     : 1.0.0
Release     : 6.el6
(略)
Available Packages
Name        : docker-io
Arch        : x86_64
Version     : 1.4.1
(略)

で、検証用のdockerコンテナを上げようとして、「あれ？docker動かないや…」

$ docker ps -a
FATA[0000] Cannot connect to the Docker daemon. Is 'docker -d' running on this host?

1.0ではサービスはなかったはずなので、サービス上げればいいかな〜

$ service start docker
Starting docker:                                           [  OK  ]

よしよし。これで動くかな？

$ docker ps -a
FATA[0000] Cannot connect to the Docker daemon. Is 'docker -d' running on this host?

… あらぁ？
所詮開発環境ですので、実データ等が入ってるコンテナはないので最悪失われてもなんとかはなるのですが、されど開発環境。色々試行錯誤した内容がイメージとして残ってますので全部なくなったといった事態は避けたいところです..

落ち着いてまずログを見ます。

$ less /var/log/docker
...
time="2015-02-17T13:02:05+09:00" level="info" msg="WARNING: You are running linux kernel version 2.6.32-504.8.1.el6.x86_64, which might be unstable running docker. Please upgrade your kernel to 3.8.0."
time="2015-02-17T13:02:05+09:00" level="info" msg="Listening for HTTP on unix (/var/run/docker.sock)"
/usr/bin/docker: relocation error: /usr/bin/docker: symbol dm_task_get_info_with_deferred_remove, version Base not defined in file libdevmapper.so.1.02 with link time reference

カーネル3.8.0以降を使えと言われてしまっています。CentOS6の標準カーネルは2.6で3.8はありません。docker1.4はカーネル3.8以降に依存するのか。さてどうしたものか…

案1: dockerのバージョンを戻す
案2: 言われてる通りカーネルのバージョンを上げる

案1の場合、dockerのバージョンダウンになりますので、ひょっとするとレポジトリの内容に影響が出る可能性が0ではないです。dockerホストは最悪ボロボロになってもまあ建て直せばOKですが、レポジトリが失われるのは避けたいところ。ということで、ホスト側でスナップショットで保険をかけて案2でいくことにします。

CentOS標準では3.8は提供されていませんが、困ったときのEPELということで、EPELから3.xのカーネルを取ってくることにします。

rpm -Uvh http://www.elrepo.org/elrepo-release-6-6.el6.elrepo.noarch.rpm
sudo yum install --enablerepo=elrepo-kernel kernel-ml

起動時にカーネルを切り替えて、ホストを上げ直します。

# uname -ar
Linux docker 3.19.0-1.el6.elrepo.x86_64 #1 SMP Mon Feb 9 11:00:58 EST 2015 x86_64 x86_64 x86_64 GNU/Linux

これでうまくいくといいな〜と思いつつ、dockerサービスを上げて、dockerコマンド叩いてみます。

$ docker ps -a
FATA[0000] Cannot connect to the Docker daemon. Is 'docker -d' running on this host?

あらぁ。ダメっすか。再度ログを確認。 カーネルバージョン上げろというメッセージは消えましたが、dm_task_get_info_with_deferred_removeほにゃらというメッセージが出ていました。

time="2015-02-17T13:46:11+09:00" level="info" msg="+job serveapi(unix:///var/run/docker.sock)"
/usr/bin/docker: relocation error: /usr/bin/docker: symbol dm_task_get_info_with_deferred_remove, version Base not defined in file libdevmapper.so.1.02 with link time reference

libdevmapper.so .. デバイスマッパーまわりということで、周辺モジュール絡みだな、と当たりをつけ、device-mapperをアップグレードしてみます。

# yum update device-mapper

docker はホストとコンテナでカーネルを共有する技術の関係上、カーネルとその周辺モジュール/コマンドまわりのバージョンについては比較的シビアなところがあります。dockerが出る前にdockerが使っているLXCという技術を直で触っていた時期があるのですが、こいつもカーネルと周辺モジュールのバージョンがかなりシビアで、組み合わせで動いたり動かなかったりということが結構ありました。
ハードウェアをエミュレーションする仮想化技術と異なり、仕組み上、カーネルのプロセス空間を分けたり分割したグループ毎にファイルシステムを分けたりしてますので仕方のない部分ではあります。その辺の動作原理をある程度把握していればトラブルシュート出来ますが、理解せずに動いたからいいやでいくと、今回みたいにバージョンアップではまったりということが往々にしてある技術であることは気をつけたいところです。
… ハマっといて言うのも格好悪いですが。

念のためリブートして、再度挑戦。

$ docker ps -a
CONTAINER ID        IMAGE                 COMMAND                CREATED             STATUS                          PORTS                                    NAMES

なんとか動作するところまでこぎつけました。ホスト側のgrubをカーネル3.8で起動するように設定してとりあえずは復旧。やれやれです。

前述のとおりdockerではホストとコンテナでカーネルが共有されています。ホスト側のカーネルのバージョンを上げた場合、コンテナ側のカーネルも入れ替わることになります。
今回の場合コンテナ側で見た時にはこれまではカーネル2.6で動いていたのに対し、今後はコンテナもカーネル3.19で動く形になります。

厳密にはこの差異がアプリの動作に影響するかどうかについてはコンテナ毎に判断する必要がありますので動いて即OKとは一概には言えません。ただし、このホストで動かしているアプリについてはカーネルに依存するものが基本的にないことがわかっているため今回はこれでOK。この辺は動かしているアプリの特性・中身をきちんと把握しておかないと余計なリスクをしょいこむことになりますので注意したいところではあります。

さらに言えば弊社の場合、dockerの開発環境から即本番とすることはなく、一度仮想マシン直上のステージング環境で動作確認を取るようにしているのでこの辺の部分の影響はそこで弾くという考え方です。保険はかけつつ、開発効率はトップギアに持っていかないと時間いくらあっても足りませんからね。

まあ何はともあれ、作ったイメージ類救えてとりあえず一安心。といっても開発環境(それも仮想環境のホスト)とはいえCentOS6にカーネル3.xはちょっとアレですので、おとなしくCentOS7ベースにお引っ越しすることにしたいところ。さて、イメージのお引越しどうするかなぁ…

ということで続く..かもしれませんｗ

＜Getinfoで構成管理情報を取得＞

ITILの構成管理として取得すべき情報として、サーバのスペック、OSのバージョン、パッケージのバージョンなどがあります。これら構成情報は、ZabbixやOCS Inventory NGなどのオープンソースを活用すると簡単に取得出来ます。それらの構成アイテム情報をOTRSのCMDBで管理すると、アプリケーションのコンフィグなどの構成情報も管理できないかと考える方も少なくないかと思います。そのような時は、getinfoとfabricなどのオープンソースを連携してOTRSのCMDBで管理させることも出来ます。ここでは、getinfoのインストール、設定について紹介しようと思います。

（１）getinfoで取得できる情報とは
getinfoは、サーバの次の情報をディフォルトで取得することが出来ます。シェルの設定値を追記、修正すれば、色々なコンフィグを取得することも出来ます。
・OSのバージョン
・カーネルのバージョン
・カーネルパラメータの設定情報
・メモリの使用状況
・ファイルシステム関連の情報
・NICの情報
・スタティック・ルーティングの設定情報
・DNS参照の設定情報
・インストール済みパッケージの情報
・yumリポジトリ情報
など

（２）getinfoのインストール
この手順は、CentOS6.5のものです。

# rpm --import http://elrepo.org/RPM-GPG-KEY-elrepo.org
# rpm -Uvh http://elrepo.org/elrepo-release-6-5.el6.elrepo.noarch.rpm
# yum -y install getinfo
# rpm -qa | grep getinfo
getinfo-1.2-1.el6.elrepo.noarch

（３）設定を修正
取得したいコンフィグを追加します。ここでは、httpd.confを追記します。

# vi /usr/local/bin/getinfo.sh
---
PRGSNET=$PRGSNET:"cat /etc/httpd/conf/httpd.conf"
---

（４）コンフィグ情報を取得
コンフィグ情報を取得するスクリプトを実行します。

# /usr/local/bin/getinfo.sh

（５）取得したコンフィグ情報を確認
取得したコンフィグ情報は、/tmp以下にbasedata.******というファイル名で生成されます。

# cat /tmp/basedata.tgxfBE
以下は一部抜粋です。
== BEGIN chkconfig --list | grep -Ei 'network|wpa' ==
network 0:off 1:off 2:on 3:on 4:on 5:on 6:off
== END?? chkconfig --list | grep -Ei 'network|wpa' ==

== BEGIN cat /etc/httpd/conf/httpd.conf ==
#
# This is the main Apache server configuration file.? It contains the
# configuration directives that give the server its instructions.
# See <URL:http://httpd.apache.org/docs/2.2/
（省略）
# ErrorLog logs/dummy-host.example.com-error_log
# CustomLog logs/dummy-host.example.com-access_log common
#</VirtualHost>
== END?? cat /etc/httpd/conf/httpd.conf ==

httpd.confのファイルをそのまま取得しているので、コメントアウトしている部分など不要な記述も取得していまいす。不要な記述を削除したかったりする場合は、getinfoを使わず、スクリプトを作ってしまった方が良いかもしれません。