Docker ComposeでPostgreSQLとpgAdmin 4を起動したら接続時にしょうもない事でハマった

はじめに

 Docker ComposeでPostgreSQLとpgAdmin 4を起動して、pgAdmin 4からPostgreSQLに接続したら、うまく繋げなくて「??」ってなってました。
 1ヶ月後ぐらいに忘れていて、またやってしまいそうなのでメモ。

環境

  • docker-compose version 1.23.2
  • PostgreSQL 11.5
  • pgAdmin 4.13

どうやって起動したか?

何にハマったかの前に、どうやって起動したかを簡単に説明します。

以下の記事を参考にdocker-compose.ymlを参考を作成して起動しました。

何にハマったか

pgAdmin 4に接続情報を入れる際、接続先として127.0.0.1:5432を指定して「繋がらない…?」って困ってました。
127.0.0.1って、pgAdmin 4を起動しているコンテナを指しているから、繋がるはずがない。

繋げるためには、コンテナからみたホスト(環境によってことなるでしょうが、172.17.0.1とか)か、docker-compose.ymlで指定したサービス名(postgresqlとか)を指定する必要があります。

さいごに

気づいたときは、脱力しました…。

WebSphere Application Server traditionalをDockerで起動してみる

はじめに

WebSphere Application Server traditionalを起動してみました。
所々苦労したのでメモ。

環境

  • Docker version 18.09.7

使う前に知っておくべきこと

そもそもWebSphere Application Server traditionalって?

IBM WebSphere Application Server Libertyではない方のWebSphere Application Serverを traditionalと呼びます*1

WebSphere Application Server traditionalのDockerイメージの説明

以下に存在します。

ライセンス

ibmcom/websphere-traditionalの下部のリンクに説明があります。

使う際の注意点

起動にちょっと時間かかる

ibmcom/websphere-traditionalに記載のコマンドを実行しても、すぐは使えません。
起動に時間がかかります。dockerのログをみて出力が落ち着くまで待ちます。 手元で試したところ、以下のログがでたら起動しているようです。*2

{"type":"was_message","host":"was","ibm_cellName":"DefaultCell01","ibm_nodeName":"DefaultNode01","ibm_serverName":"server1","ibm_sequence":"1569160254517_000000000011A","message":"CWPKI0037I: Expiration monitor reports the following information: \n**** Subject:  Expiration Monitor ****; \n\nHostname: was\nProfile UUID: AppSrv01-BASE-1389585a-6c06-4875-bab5-66f7452fd309\nProcess type: UnManagedProcess\n\nChecking for expired certificate and certificates in the 60 days threshold period.\n\nCWPKI0735I: All certificates were searched and no expiration issues were found.\n.","ibm_datetime":"2019-09-22T13:50:54.517+0000","ibm_messageId":"CWPKI0037I","ibm_threadId":"0000006e","module":"com.ibm.ws.crypto.config.WSNotifier","loglevel":"INFO"}
{"type":"was_message","host":"was","ibm_cellName":"DefaultCell01","ibm_nodeName":"DefaultNode01","ibm_serverName":"server1","ibm_sequence":"1569160254610_000000000011B","message":"ADMR0016I: User defaultWIMFileBasedRealm\/server:DefaultCell01_DefaultNode01_server1 modified document cells\/DefaultCell01\/security.xml.","ibm_datetime":"2019-09-22T13:50:54.610+0000","ibm_messageId":"ADMR0016I","ibm_threadId":"0000006e","module":"com.ibm.ws.management.repository.FileRepository","loglevel":"AUDIT"}
管理コンソールのURLはちゃんと ibmcom/websphere-traditionalに記載されているURLを叩く

以下のURLを叩きます。


「コンテキストパスなしでも何か出るだろー」とかおもって、https://localhost:9043/を叩いても何も出ません。

ibmcom/websphere-traditionalに記載されているポートだけ開けても、デプロイしたアプリにアクセスできない

ibmcom/websphere-traditionalには記載されていないですが、アプリには9043ではないポートを使用してアクセスします。
defaulthostにデプロイする場合、デフォルトでは9080を使用してアクセスします。

よって、実際のDockerコマンドは以下のような感じになります。

docker run --name test -h test -v $(pwd)/PASSWORD:/tmp/PASSWORD -p 9043:9043 -p 9443:9443 -p 9080:9080 -d ibmcom/websphere-traditional:9.0.5.0

WebSphere Application Server traditionalが使っているポート番号を調べたい場合は、以下が参考になります。

さいごに

普通にインストールするよりは格段に楽に起動まで出来ましたので、Dockerを使って起動するのおすすめです。

*1:IBM WebSphere Application Server (WAS) | 製品・ソリューション | エヌアイシー・パートナーズ株式会社

*2:止めたコンテナを再開したときは、また別のログがでるのですが割愛します。

Intellij IDEAとTomcatとコンソールの文字化け

はじめに

すごくちょっとしたことなのだけど、5分以上はまったのでメモ。

環境

事象

Tomcatを起動した際に、IntelliJ IDEAのコンソールの表示が文字化けする。

解決方法

以下のファイルに「-Dfile.encoding=UTF-8」と追記する。

C:\Users\<ユーザ名>\.IntelliJIdea2019.2\config\idea64.exe.vmoptions

はまったこと

以下のファイル記載しても、設定は有効にならない。

C:\Program Files\JetBrains\IntelliJ IDEA 2019.2\bin\idea64.exe.vmoptions

おそらく、読み込まれるファイルに優先順位があるのでしょう。

2019年7月現在CentOS 6.4をEC2で新規に使おうとしたら意外と大変だった。

はじめに

CentOS 6.4をEC2に新規インストールしたかったのですが、AWS Marketplaceに存在しませんでした。
そこで自分でAMIイメージを作ったのですが、苦労したのでメモ。

作業前に決めておくこと

HVM AMIs (GRUB)を作成するか、Paravirtual AMIs (PV-GRUB)を作成するか

両者の解説は、User Provided Kernels - Amazon Elastic Compute Cloud に記載されています。
主な違いは以下の通りです。

種類 作成したAMIを起動できるインスタンスタイプ AMI構築時のポイント
HVM AMIs (GRUB) 現行世代のインスタンスと旧世代のインスタンスタイプ(全部の旧世代で起動するかは不明)。 Partition Tableの設定が必要(parted等のコマンドで設定する)。
Paravirtual AMIs (PV-GRUB) t1等旧世代のインスタンスタイプのみ。*1 Partition Tableを設定しなくていい。
私は今回HVM AMIs (GRUB)を使うことにしました。

作業前に知っておくべきこと

ISOイメージからOSを(多分)起動できないという事実

結構調べたんですが、方法がさっぱり分からず。
私はISOイメージを使わずにセットアップしました。

どこのサイトでCentOS 6.4を配布しているのか

「何を当たり前な」と思うかと思いますが、古いディストリビューションミラーサイトではもう配布していないことがあります。
日本のミラーでは、もう、CentOS 6.4は配布していませんでした。
私はhttp://vault.centos.org/から入手しました。

インストール方法を解説したサイト

種類 サイト
HVM AMIs (GRUB) EC2でCentOS6のEBS-Backed HVM方式 AMIをゼロから作る - Qiita
Paravirtual AMIs (PV-GRUB) EC2でCentOS6のEBS-Backed AMIをゼロから作る - SEEDS Creator's Blog *2

今回私は、EC2でCentOS6のEBS-Backed HVM方式 AMIをゼロから作る - Qiita のサイトを参考に作成しました。

インストール方法を解説したサイト(EC2でCentOS6のEBS-Backed HVM方式 AMIをゼロから作る - Qiita)に対する補足

前述のサイトを見ながら作業していく中で、気づいた点があったので、僭越なのは承知なのですがメモしていきます。

OSはCentOS 6.xでも良い

作業用インスタンスを作成」ではAmazon Linux 64bitを使っていますが、私はCentOS 6.10にしました。
特別な根拠はないのですが、まあ、バージョンが近いOSの方で作業した方が良いかと思っての、験担ぎ的判断です。
ただし、途中で使うツールが時々インストールされていないので、適宜yum installでインストールする必要がありました。

EBSのパーティション作成。フォーマット。マウント」のデバイスの名前(/dev/xvdf)について

当然なのですが、AWSコンソール上から/dev/sdf以外でマウントした場合は別の名前になります。
lsblk*3コマンドを使用して、自分の環境ではどういう名前になっているか確認してから作業します。

私が作業したインスタンスではlsblkは以下の結果になりました。

$ lsblk
NAME    MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda    202:0    0   8G  0 disk
└─xvda1 202:1    0   8G  0 part /
xvdb    202:16   0  30G  0 disk
└─xvdb1 202:17   0  30G  0 part

ですので、私の環境ではdev/xvdbを使用することになります。

EBSのパーティション作成。フォーマット。マウント」のフォーマットで指定するデバイス名は末尾に1がついている方

ちゃんと記事を読めば失敗しないのですが、デバイス名は末尾に1がついている方を使用してください。
私の場合は以下の通りですね。

mkfs.ext4 /dev/xvdb1

うっかり、末尾に1がついてない方を指定してもコマンドは成功してしまうのですが、Partition Tableが変になってしまい、grubの設定ではまります。

間違った場合、parted -lで確認した際にloopというみたことないPartition Tableになります。
以下に間違った場合の例を示します。

# parted -l
Model: Xen Virtual Block Device (xvd)
Disk /dev/xvda: 8590MB
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Number  Start   End     Size    Type     File system  Flags
 1      1049kB  8590MB  8589MB  primary  ext4         boot


Model: Xen Virtual Block Device (xvd)
Disk /dev/xvdb: 32.2GB
Sector size (logical/physical): 512B/512B
Partition Table: loop

Number  Start  End     Size    File system  Flags
 1      0.00B  32.2GB  32.2GB  ext4

インストール用の yum.conf を作成で前提としているrikenさんのmirrorが無い

http://vault.centos.org/のみでどうにかします。

鍵のダウンロード

cd /mnt
wget -O ../RPM-GPG-KEY-CentOS-6 http://vault.centos.org/6.4/os/x86_64/RPM-GPG-KEY-CentOS-6

repos.confの作成の内容は以下のようにします。

vi ../repos.conf
[ami-base]
name=CentOS-6 - Base
mirrorlist=file://${PWD}/../mirrorlist.centos
gpgcheck=1
gpgkey=file://${PWD}/../RPM-GPG-KEY-CentOS-6

[ami-updates]
name=CentOS-6 - Updates
mirrorlist=file://${PWD}/../mirrorlist.centos.updates
gpgcheck=1
gpgkey=file://${PWD}/../RPM-GPG-KEY-CentOS-6||<

repos.confから参照するmirrorlist.centosは以下のように作成します。

vi ../mirrorlist.centos
http://vault.centos.org/6.4/os/x86_64/

repos.confから参照するmirrorlist.centos.updatesは以下のように作成します。

vi ../mirrorlist.centos.updates
http://vault.centos.org/6.4/updates/x86_64/

あとは記事通りでOK

うっかり手順を飛ばさないように気を付けて行いましょう。

さいごに

こうやって整理して書くと大半は参考記事通りなんですが、HVM AMIs (GRUB)とParavirtual AMIs (PV-GRUB)の違いをちゃんと理解しておらず、やたら時間が掛りました。
Paravirtual AMIs (PV-GRUB)の手順で途中までやって、「あれ。なんか使いたいインスタンスタイプで起動できない??」となって、あーだこーだして時間を浪費する結果に。

*1:これが実は結構な制約で、東京リージョンの場合、GUIから選べるインスタンスがあんまり無いです。Linux AMI 仮想化タイプ - Amazon Elastic Compute Cloudに載っているものは選べてよさそうなんですが、実際に選べるのはもっと少ないという。

*2:明確にはParavirtual AMIs (PV-GRUB)と記載されていないのですが、「作成したEBSをAMI化する」のところでHVM AMIs (GRUB)作成時には選べないカーネルを選択しているので、区別がつきます。

*3:Linux で Amazon EBS ボリュームを使用できるようにする - Amazon Elastic Compute Cloud

mvn site:siteでやたらスタックトレースが出力される

はじめに

実用上問題ないのですが、mvn site:siteを実行するとスタックトレースがいっぱい出力されます。
無視して良いのか気になったので調べてみました。

環境

続きを読む

Apache Maven Site PluginでArtifactResolutionExceptionが出力されて困ることがある。

はじめに

件名通りのことが発生して、地味に困ったのでメモ。

環境

解決方法

以下の記事に記載されています。
tcollignon.github.io

解決方法の補足

私は「Tell maven-site-plugin to not using inheritence」の部分を読んで解決したのですが、ちょっと苦労したので補足。

前述の記事は閉じタグが書いてない

忘れずにprojectを閉じる必要があります。

<project name="test" combine.self="override">
</project>
上記は何にかく?

以下のファイルに書きます。

前述のproject要素だけでもOKです。

/src/site/site.xml

さいごに

Apache Maven Site Plugin、時々手強い……。

Jenkins 2.5以降のDeclarative PipelineでCheckstyle PluginとFindBugs Pluginを使いたい

はじめに

Jenkins 2.5以降のDeclarative PipelineでCheckstyle PluginとFindBugs Pluginを使おうとしたら、やたら苦労したのでメモ。

環境

  • Jenkins ver. 2.60.3

したかったこと

  • Declarative Pipeline*1でPipelineを書く。
  • Maven で出力したCheckstyleとSpotbugsの結果をJenkinsに表示する。
  • parallelとか凝ったことはせず、シンプルにまずはやりたい。

Pipelineの書き方の例

mvnがBUILD FAILUREになっても後続が実行されるようにcatchErrorで囲みます。

pipeline {
//中略
    stage('checkstyle and spotbugs') {
        when {
          branch 'develop'
        }
        steps {
          catchError{
            sh 'mvn checkstyle:check spotbugs:check'
          }
          checkstyle canComputeNew: false, canRunOnFailed: true, defaultEncoding: '', healthy: '', pattern: '', unHealthy: ''
          findbugs canComputeNew: false, canRunOnFailed: true, defaultEncoding: '', excludePattern: '', healthy: '', includePattern: '', pattern: '', unHealthy: ''
        }
    }
//中略
}

checkstyleおよびfindbugsプラグインは先に書いても結果を収集してくれるので、これでもいけます。

pipeline {
//中略
    stage('checkstyle and spotbugs') {
        when {
          branch 'develop'
        }
        steps {
          checkstyle canComputeNew: false, canRunOnFailed: true, defaultEncoding: '', healthy: '', pattern: '', unHealthy: ''
          findbugs canComputeNew: false, canRunOnFailed: true, defaultEncoding: '', excludePattern: '', healthy: '', includePattern: '', pattern: '', unHealthy: ''
          sh 'mvn checkstyle:check spotbugs:check'
        }
    }
//中略
}

はまったこと

pluginの解説をみると全部のパラメータにoptionalと書いてあるが、省略するとpipeline実行時にエラーが発生する。

首記のとおりです。以下のリファレンスを読むと全部のパラメータにoptionalと書いてあるのに……。

リファレンスを見てもさっぱりわからないので、【Jenkins】Declarative Pipeline入門 - Qiita で解説されている「コードスニペットを自動で生成してくれる機能」を使用して生成したコードを貼りつけました。

Mavenの実行結果がBUILD FAILUREになると後続処理が実行されない

首記の仕様があるため、以下のように記述すると結果がJenkinsに表示ません。
mvn checkstyle:check、mvn spotbugs:checkともに指摘を検知するとBUILD FAILUREになりますものね。

//中略
        steps {
          sh 'mvn checkstyle:check'
          checkstyle canComputeNew: false, canRunOnFailed: true, defaultEncoding: '', healthy: '', pattern: '', unHealthy: ''
          sh 'mvn spotbugs:check'
          findbugs canComputeNew: false, canRunOnFailed: true, defaultEncoding: '', excludePattern: '', healthy: '', includePattern: '', pattern: '', unHealthy: ''
        }
//中略

さいごに

苦労してpiplelineを書いたのですが、Checkstyle PluginとFindBugs PluginはDeprecatedです。
Warnings Next Generation Pluginが後継のpluginのようです。

余談ですが、最初、この名前みても後継のpluginであることが分からなかったです。
この記事書いている途中に復習していて気づいた。

*1:余談ですが、Scripted Pipelinesという別の書き方が存在することを知らず、「なんか書き方複数あるっぽい??」と混乱しながら調査してた