LoginSignup
1

posted at

Organization

chef-serverからcinc-serverへの移行

SRA Advent Calendarの24日目です。
ネットワークシステムサービス第1事業部の ふじまき です。

はじめに

Chefの配布パッケージは2019年4月9日のライセンス変更後、新たにリリースされたパッケージから商用ライセンスが必要になりました。
同じ年にソースコードからChef社の商標に関わるものを取り除いたパッケージを配布する(RHELに対するAlmalinux/RockyLinuxと同じ)CINC Projectが立ち上がり、現在までに以下のパッケージがリリースされました。

  • cinc-client (chef-clientの代替)
  • cinc-workstation (chef-workstationの代替)
  • cinc-auditor (Inspecの代替)
  • cinc-server (chef-serverの代替)

最初の3つはオリジナルのパッケージと置き換えるだけでよいのですが、最後のcinc-serverへの移行はデータを引き継ぐ必要があり、CINC版のパッケージを入れるだけでは移行できません。
で、CINC Projectでは特に移行方法は説明されていないので独自に調べてみた。

アップグレードパス

以下に書かれていますが、

chef-serverのVer 12.17.15以降から最新のVer.15へアップグレードが可能になっています。
cinc-serverのver 13はリリースされていないので12.xx.xxから14 or 15へアップグレードします。

現在のバージョン アップグレード先のバージョン
chef-server ver 12.17.15以降 cinc-server ver 14 or 15

データの保存場所の違い

chef-serverとcinc-serverのデータ保存場所は以下の2つなので、基本的に持っていくだけ。

データの種類 Chef CINC
サーバの設定 /etc/opscode /etc/cinc-project
ユーザーデータ /var/opt/opscode /var/opt/cinc-project
上記ディレクトリに加えて、サーバの設定ディレクトリ内にファイル名を変えるものがあります。(後述)

アップグレード

公式の手順にそって行います。なのでバックアップを取得してますが、仮想マシンで運用している場合はスナップショットを取得しておくのが楽です。
以下はUbuntu 18.04 LTSで行っています。

PostgreSQLデータベースのバキューム

$ sudo su - opscode-pgsql
$ /opt/opscode/embedded/bin/vacuumdb --all --full
vacuumdb: vacuuming database "bifrost"
vacuumdb: vacuuming database "oc_id"
vacuumdb: vacuuming database "opscode-pgsql"
vacuumdb: vacuuming database "opscode_chef"
vacuumdb: vacuuming database "postgres"
vacuumdb: vacuuming database "template1"
$ exit

バックアップ取得

(バックアップ取得中にChefサーバが一時停止します)

$ sudo chef-server-ctl backup --yes
Locating rsync..
/usr/bin/rsync
Starting Chef Server backup
Bringing down the Chef Server
ok: down: bookshelf: 0s, normally up
ok: down: nginx: 1s, normally up
ok: down: oc_bifrost: 0s, normally up
ok: down: oc_id: 1s, normally up
ok: down: opscode-chef-mover: 0s, normally up
ok: down: opscode-erchef: 1s, normally up
(略)

chef-serverが正常かどうか確認するためにreconfigure

動作確認のためなので省略可

$ sudo chef-server-ctl reconfigure

chef-server停止

$ sudo chef-server-ctl stop || sudo chef-server-ctl kill rabbitmq
ok: down: bookshelf: 1s, normally up
ok: down: nginx: 0s, normally up
ok: down: oc_bifrost: 1s, normally up
ok: down: oc_id: 0s, normally up
ok: down: opscode-chef-mover: 78s, normally up
ok: down: opscode-erchef: 1s, normally up
ok: down: opscode-expander: 0s, normally up
ok: down: opscode-solr4: 0s, normally up
ok: down: postgresql: 0s, normally up
ok: down: rabbitmq: 0s, normally up
ok: down: redis_lb: 0s, normally up

これで個別のサービスは停止しますが、runsvやsvlogdが残っているので以下で停止

$ sudo systemctl stop private_chef-runsvdir-start.service

chef-serverパッケージ削除

$ sudo dpkg -r chef-server-core

CINC版のパスにデータ移動

CINC版を入れる前にChef Serverのデータをcinc Serverのパスにコピー
private-chef-secrets.jsonはリネーム

$ sudo cp -a /etc/opscode /etc/cinc-project
$ sudo cp -a /var/opt/opscode /var/opt/cinc-project
$ sudo mv /etc/cinc-project/private-chef-secrets.json /etc/cinc-project/private-cinc-secrets.json

cinc serverインストール

http://downloads.cinc.sh/files/stable/cinc-server/ からダウンロードしたcinc Serverのパッケージをインストール

$ sudo dpkg -i cinc-server-core_15.3.2-1_amd64.deb

cinc-serverの15.3.2未満を使う場合、この修正が行われていないので手で修正

$ sudo sed -i.bak 's!/opscode/!/cinc-project/!' /opt/cinc-project/embedded/upgrades/001/036_reindex_postgres13.rb

アップグレード処理

$ sudo cinc-server-ctl upgrade

CINC版ではファイルのownerが変わっているがChefサーバからの移行の場合、変更処理が行われないので手で直します。
owner:groupの両方がopscodeのものと、ownerだけopscodeのものがあるので2回に分けて修正

$ sudo find /var/opt/cinc-project -uid `id -u opscode` -a -gid `id -g opscode` -exec chown cinc:cinc {} \;
$ sudo find /var/opt/cinc-project -uid `id -u opscode` -exec chown cinc {} \;

cinc serverを起動

$ sudo cinc-server-ctl start

動作確認して問題なさそうであればゴミ削除

$ sudo cinc-server-ctl cleanup
$ sudo apt-get purge chef-server-core
$ sudo rm -rf /var/opt/opscode
$ sudo rm -rf /etc/opscode
$ sudo rm -rf /var/log/opscode

おわり。

補足

SSE 4.2非対応CPU環境でchef serverが起動しない(cinc serverも同様)

以下で報告されているネタ
https://github.com/chef/chef-server/issues/3451
https://github.com/chef/chef-server/issues/3511

Javaがzlibのcrc関数を呼び出す時に変なデータを渡してるのが原因

zlib 1.2.12の変更で発生するようになったので、zlib側が大人の対応して、1.2.13で修正されました。
SSE4.2対応CPUの場合はSSE命令で処理されるので問題は発生しません。

非対応CPUの場合、chef(cinc) server 14 or 15に同梱されているOpenSearchが踏みます。
その場合は/opt/cinc-project/embedded/lib/にあるzlib.soを1.2.13のものに入れ替えればOK(Issue #3511にコメント書いておいた)

非力な環境でOpenSearchのセットアップに失敗する

下記のようなエラーが出て失敗するOpenSearchのセットアップに失敗することがあります。

---- Begin output of export JAVA_HOME="/opt/cinc-project/embedded/open-jre/";
./securityadmin.sh -f ../securityconfig/internal_users.yml -icl -nhnv -cert /opt/cinc-project/embedded/opensearch/config/admin.pem -cacert /opt/cinc-project/embedded/opensearch/config/root-ca.pem -key /opt/cinc-project/embedded/opensearch/config/admin-key.pem
 ----
STDOUT: Security Admin v7
Will connect to localhost:9300
ERR: Seems there is no OpenSearch running on localhost:9300 - Will exit
STDERR:
---- End output of export JAVA_HOME="/opt/cinc-project/embedded/open-jre/";
./securityadmin.sh -f ../securityconfig/internal_users.yml -icl -nhnv -cert /opt/cinc-project/embedded/opensearch/config/admin.pem -cacert /opt/cinc-project/embedded/opensearch/config/root-ca.pem -key /opt/cinc-project/embedded/opensearch/config/admin-key.pem
 ----
Ran export JAVA_HOME="/opt/cinc-project/embedded/open-jre/";
./securityadmin.sh -f ../securityconfig/internal_users.yml -icl -nhnv -cert /opt/cinc-project/embedded/opensearch/config/admin.pem -cacert /opt/cinc-project/embedded/opensearch/config/root-ca.pem -key /opt/cinc-project/embedded/opensearch/config/admin-key.pem
 returned 255

OpenSearchのアカウント情報を作成する際、OpenSearchが起動完了していないらしく(多分リソース不足)リトライ回数内で完了しない模様
/opt/cinc-project/embedded/cookbooks/infra-server/recipes/opensearch.rb の中のadd internal user to opensearch security pluginというexecuteリソースのretry_delay(リトライ間隔)を長くすればOK

execute 'add internal user to opensearch security plugin' do
  command <<~EOF
    export JAVA_HOME="/opt/#{ChefUtils::Dist::Org::LEGACY_CONF_DIR}/embedded/open-jre/";
    ./securityadmin.sh -f ../securityconfig/internal_users.yml -icl -nhnv \
    -cert #{opensearch_opt_conf_dir}/admin.pem \
    -cacert #{opensearch_opt_conf_dir}/root-ca.pem \
    -key #{opensearch_opt_conf_dir}/admin-key.pem
  EOF
  cwd "#{opensearch_opt_plugins_dir}/opensearch-security/tools/"
  user OmnibusHelper.new(node).ownership['owner']
  retries 10
  retry_delay 5 # 1->5に変更
end

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
What you can do with signing up
1