GitLab-CE(Omnibus)8を11までアップグレードさせる

皆さま、こんにちわ。

久々の更新です。ホントに久々 笑

定期的に更新したいと思いつつ、ついつい間隔が空いてしまい反省。。。

今日はGitLab Community Edition 8.11.2を11.0.3にアップグレードした時の備忘録。 いくつか手が止まるポイントがありましたので、その辺りも含めまとめてみました

f:id:namio6243:20181021122733p:plain

検証環境

※Omnibus packageを利用

手順

パッケージをインストールする元はこちら packages.gitlab.com

アップグレードする際、いくつかのバージョン経由して試してます

8.11.2--->8.17.8

# yum upgrade gitlab-ce-8.17.8-ce.0.el6.x86_64

試してみるとスンナリいかず、以下のようなPostgreSQLのエラー出ます(Migration処理が失敗している?)

gitlab preinstall: Automatically backing up only the GitLab SQL database (excluding everything else!)
Dumping database ... 
Dumping PostgreSQL database gitlabhq_production ... pg_dump: [archiver (db)] connection to database "gitlabhq_production" failed: could not connect to server: そのようなファイルやディレクトリはありません
    Is the server running locally and accepting
    connections on Unix domain socket "/var/opt/gitlab/postgresql/.s.PGSQL.5432"?
Backup failed
[FAILED]
gitlab preinstall: 
gitlab preinstall: Backup failed! If you want to skip this backup, run the following command and
gitlab preinstall: try again:
gitlab preinstall: 
gitlab preinstall:   sudo touch /etc/gitlab/skip-auto-migrations

なので、言われた通りに回避策を実施します

# sudo touch /etc/gitlab/skip-auto-migrations

再度トライするとインストール成功!

# yum upgrade gitlab-ce-8.17.8-ce.0.el6.x86_64

アップグレードしたらreconfigureします(自動的に再起動もされる)

アップグレード後、稀にprocessが上がらなかったりしたので念のためやる。 実行すると、経過が出力されるんですがどうやらChefが実行されてるらしい

# gitlab-ctl reconfigure

ステータスをチェックしてみると全て正常に見える

# gitlab-ctl status
run: gitlab-workhorse: (pid 13682) 139s; run: log: (pid 1156) 4793s
run: logrotate: (pid 14292) 118s; run: log: (pid 12511) 599s
run: nginx: (pid 13698) 139s; run: log: (pid 1155) 4793s
run: postgresql: (pid 13551) 192s; run: log: (pid 1153) 4793s
run: redis: (pid 13542) 193s; run: log: (pid 1163) 4793s
run: sidekiq: (pid 13674) 140s; run: log: (pid 1172) 4793s
run: unicorn: (pid 14302) 118s; run: log: (pid 1162) 4793s

続いて、メジャーバージョンを上げます

8.17.8--->9.0.0

# yum upgrade gitlab-ce-9.0.0-ce.0.el6.x86_64

特に問題なくアップグレード成功

また念のため、reconfigure実行

# gitlab-ctl reconfigure

さらに続いて、メジャーバージョンを上げます

9.0.0--->10.0.3

# yum upgrade gitlab-ce-10.0.3-ce.0.el6.x86_64

しかし、これだとPostgreSQLバージョンが低いのでアップグレード失敗します

という訳でPostgreSQLを先にアップグレードする

※psqlを使うので事前にpathを通しておくこと
# gitlab-ctl pg-upgrade

成功すると、9.2--->9.6にアップグレードされます

再度メジャーバージョンアップにトライすると成功します

# yum upgrade gitlab-ce-10.0.3-ce.0.el6.x86_64

忘れずにreconfigureを実行

# gitlab-ctl reconfigure

※version10になるとUIが結構変わる

ここからはスンナリとアップグレードが進みます

直接11迄アップグレードしようとすると失敗するので、10.8.0を経由する

# yum upgrade gitlab-ce-10.8.0-ce.0.el6.x86_64

忘れずにreconfigureを実行

# gitlab-ctl reconfigure

続いでさらに11.0.3にアップグレードする

# yum upgrade gitlab-ce-11.0.3-ce.0.el6.x86_64

忘れずにreconfigureを実行

# gitlab-ctl reconfigure

以上でアップグレード完了!

ちなみにステータスを確認してみると、色々プロセスが増えていることがわかる

prometheusなどのmonitoring toolもパッケージに含まれるようになったみたい

# gitlab-ctl status
run: alertmanager: (pid 29641) 95s; run: log: (pid 27683) 645s
run: gitaly: (pid 30926) 19s; run: log: (pid 8226) 2659s
run: gitlab-monitor: (pid 29666) 94s; run: log: (pid 8330) 2649s
run: gitlab-workhorse: (pid 30902) 19s; run: log: (pid 1153) 4572s
run: logrotate: (pid 29702) 93s; run: log: (pid 3703) 3985s
run: nginx: (pid 29708) 93s; run: log: (pid 1154) 4572s
run: node-exporter: (pid 29790) 92s; run: log: (pid 8277) 2655s
run: postgres-exporter: (pid 29798) 92s; run: log: (pid 8306) 2651s
run: postgresql: (pid 29806) 91s; run: log: (pid 1149) 4572s
run: prometheus: (pid 30945) 18s; run: log: (pid 8258) 2657s
run: redis: (pid 29829) 90s; run: log: (pid 1150) 4572s
run: redis-exporter: (pid 29833) 90s; run: log: (pid 8292) 2653s
run: sidekiq: (pid 30841) 32s; run: log: (pid 1151) 4572s
run: unicorn: (pid 31087) 13s; run: log: (pid 1152) 4572s

追記

auto migrationを外した影響だと思いますが, バージョンアップ後に出た影響で確認できたものを下記にまとめる

macでpyenv使うときのコマンドメモ

皆さま、こんにちわ

python使ってますか?最近は機械学習が流行りすぎて、pythonも注目されてますね、 ちなみに私の所属している会社でも使ってますが、機械学習には使ってませんwww

pythonは大きく分けて、2系と3系があり、お互いに互換性がありません。 なので、2系と3系切り替えるの簡単にやりたいよねってことで私はpyenvを使ってます

pyenvとはpythonのバージョンを簡単に切り替えられるようにしてくれる管理ツールです

github.com

pyenvの使い方すぐ忘れるので、以下にメモっておく

使い方

インストール可能な一覧取得

$ pyenv install --list

インストール

$ pyenv install {version}

適用中のversionを確認

$ pyenv version

インストール済みのversion一覧取得

$ pyenv versions

特定のディレクトリ配下でのみ利用する場合

$ pyenv local {version}

全体で利用する場合(どこのディレクトリに移動しても使える)

$ pyenv global {version}

RundeckからMySQLに接続しにいく際に出る `WARN: Establishing SSL connection without server's identity verification is not recommended` を止めてしまう

皆さま、どうもこんにちわ。

最近Rundeckばっかり触ってて小ネタがいっぱいですw

今回の小ネタは、RundeckでリポジトリDBにMySQLを使っている際に、SSL設定を明示的に無効にしていないと下記のようなメッセージが常に出る(証明書使ってない場合)

Wed May 09 21:26:00 JST 2018 WARN: Establishing SSL connection without server's identity verification is not recommended. According to MySQL 5.5.45+, 5.6.26+ and 5.7.6+ requirements SSL connection must be established by default if explicit option isn't set. For compliance with existing applications not using SSL the verifyServerCertificate property is set to 'false'. You need either to explicitly disable SSL by setting useSSL=false, or set useSSL=true and provide truststore for server certificate verification.

ということで、ジョブを実行する度にエラーログに出力されてうるさいのでSSLを無効にしてしまう(いいのかw?)

ちなみに試した環境はこちらと一緒です

RundeckでMySQL利用時に作成されるテーブル内容調査 - namio's blog

設定手順

下記のようにuseSSL=falseを追加する

[root@rundeck1 ~]# vi /etc/rundeck/rundeck-config.properties
〜〜略〜〜
dataSource.url = jdbc:mysql://{mysqlのホスト名}/{DB名}?autoReconnect=true&useSSL=false

再起動して反映すればメッセージはでなくなる

[root@rundeck1 ~]# systemctl restart rundeckd