GitLab mattermost PostgreSQL

Omnibus版のGitLab、Mattermostデータベースに外部ホストからJDBCで接続

投稿日:2019年9月1日 更新日:

Omnibusで入れたPostgreSQLは、

  • Unix Domainソケットで接続待機
  • Peer認証で認証

していて外部からの接続は出来ないことが前回分かりました。

今回はOmnibus版でいれたPostgreSQLに外部から接続出来るように設定していきます。

社内LANでの利用を想定しているのでセキュリティリスクはあまり考えず、TCPでソケット起動してPostgreSQLを外部に公開してしまいます。

設定手順

gitlab.rb設定

GitLabの設定は主に/etc/gitlab/gitlab.rbというRubyファイルで行います。

GitLab公式サイトを参照しながら設定していきます。

外部からPostgreSQLに接続出来るようにする

Unix Domainソケット起動をTCPソケット起動に変え、自ホストIPで公開。

# postgresql['listen_address'] = nil
postgresql['listen_address'] = "0.0.0.0"

外部からのリクエストをパスワード認証出来るようにする

JDBC接続時にパスワード認証して貰えるようにしておく。

# postgresql['md5_auth_cidr_addresses'] = ["127.0.0.1/32"]
postgresql['md5_auth_cidr_addresses'] = ["0.0.0.0/0"]

TCPポートを変更(任意)

GitLabと同じホスト内で別のPostgreSQLが起動しているとポートがバッティングしてしまいます。任意で変更しておきます。

# gitlab_rails['db_port'] = 5432
gitlab_rails['db_port'] = 6543

# postgresql['port'] = 5432
postgresql['port'] = 6543

ポートを変更した場合はファイアウォールを開けておきます。

# firewall-cmd --add-port=6543/tcp --zone=public --permanent
success
# firewall-cmd --reload
success

設定変更をGitLabに反映

「gitlab-ctl reconfigure」コマンドで反映します。
GitLabが起動していないと失敗するので起動したままで。

# gitlab-ctl reconfigure

  (snip)

Recipe: <Dynamically Defined Resource>
  * service[unicorn] action restart
    - restart service service[unicorn]
  * service[sidekiq] action restart
    - restart service service[sidekiq]
  * service[gitlab-monitor] action restart
    - restart service service[gitlab-monitor]
  * service[postgres-exporter] action restart
    - restart service service[postgres-exporter]

Running handlers:
Running handlers complete
Chef Client finished, 17/768 resources updated in 46 seconds
gitlab Reconfigured!

PostgreSQL設定

接続ユーザにパスワードをつける

gitlab.rbからSQLを流す用のユーザが「gitlab」ユーザとして用意されていることが分かります。

# postgresql['sql_user'] = "gitlab"

デフォルトではPeer認証だったのでパスワードが付いていません。
gitlabユーザのパスワードを作ってパスワード認証出来るようにします。

# su gitlab-psql

-sh-4.2$ gitlab-psql -d gitlabhq_production
psql (10.9)
Type "help" for help.

// ユーザ一覧を確認
gitlabhq_production=# \du
                                       List of roles
     Role name     |                         Attributes                         | Member of
-------------------+------------------------------------------------------------+-----------
 gitlab            | <-- このユーザのパスワードを設定                                                           | {}
 gitlab-psql       | Superuser, Create role, Create DB, Replication, Bypass RLS | {}
 gitlab_mattermost |                                                            | {}
 gitlab_replicator | Replication                                                | {}

// gitlabユーザのパスワードを設定
gitlabhq_production=# \password gitlab
Enter new password: ここでは"gitlab"と入力
Enter it again: 
gitlabhq_production=#

同じ手順でmattermost_productionデータベースに繋ぎ、gitlab_mattermostユーザにパスワードを付けておくと、MattermostのDBにもJDBC接続出来るようになります。

-sh-4.2$ gitlab-psql -d mattermost_production

mattermost_production=# \password gitlab_mattermost

外部ホストからJDBC接続する為の準備が完了しました。

外部ホストからの接続動作確認

DBクライアント「jailer」で接続してみます。(jailerについては以下参照)

設定してきた下記のパラメータで接続設定。
(Mattermostデータベースに繋ぐ場合は読み替えてください)

  • URL : jdbc:postgresql://GitLabのIP:6543/gitlabhq_production
  • User : gitlab
  • Password : gitlab

GitLab Omuniub版のPostgreSQLに外部ホストからJDBCで接続出来ました。

まとめ

Omnibus版GitLab、Mattermostのデータベースに外部から接続出来ました。

データベース内容をMetabaseで分析して、「mattermostのナレッジ共有チャンネルで誰が一番知識共有に貢献しているか」とか見える化し、月間トップはご褒美、とかの催しを運営するとチームモチベーションも上がるし面白いですよ。

-GitLab, mattermost, PostgreSQL

執筆者:

関連記事

SSHトンネルを使ってリモートデータベースをBI

クラウド上のDBを分析する為、ローカルPCにSSHトンネル(ポートフォワード)環境を作ります。 リモートDBポートにクラウド外からセキュアに接続できれば、クラウドにBIツールを入れる手間が省けます。 …

Mattermostのチャンネル発言数をMetabaseでビジュアル化する

オンプレGitLabでMattermostを使えるようにした後の活用法として、「ナレッジチャンネル」を運営してチームの知識を共有する営みをしている開発現場も多いと思います。 ミーティングではなくチャッ …

ERROR: Several keys given – pgcrypto does not handle keyring、またはERROR: Corrupt ascii-armor

gpgキーストアに同じUIDで複数の鍵ペアを登録してしまうと、ファイルにexportした際に1ファイルに複数の鍵情報が入ってしまい、1ファイル1鍵を期待しているpgcryptoに怒られます。 目次1 …

開発用PostgreSQLをCentOSにインストールしてSQLを流すまで

開発や勉強に使う為のPostgreSQLをCentOSにインストールします。 インストールから基本操作を体験して、0からデータベースを構築する経験を積んでおきます。 目次1 環境2 インストール手順を …

pgcryptoで公開鍵暗号の動作確認

共通鍵暗号で暗号化されたデータはパスワードが漏洩すると復号される危険が高まるのに対し、公開鍵暗号で暗号化されたデータは秘密鍵とパスワードの二つが漏洩しないと復号できません。 APサーバとDBサーバ通信 …

 

shingo.nakanishi
 

東京在勤、職歴2n年中年ITエンジニアです。まだ開発現場で頑張っています。

19歳(1996年)から書き始めたアウトプット用プライベートWeb日記数が5,000日を超え、残りの人生は発信をして行きたいと思い、令和元日からこのサイトを開始しました。勉強と試行錯誤をしながら、自分が経験したIT関連情報を投稿しています。

私と同じく、今後IT業界で生計を立てて行きたいと考えている方や、技術共有したいけど仲間が居なくて孤独、といった方と一緒に成長、知識共有して行けたら楽しいな、と思っています。