LoginSignup
1
0

More than 1 year has passed since last update.

@saitamanokusa

JobScheduler 2.4.1 → 2.5.1 アップデート時のメモ

Last updated at Posted at 2023-01-08

概要

JobScheduler 2.5.0および2.5.1 アップデート時に対応した箇所のメモ。
※私が利用している環境における対応のメモです。
※導入時期や、利用している機能によって、必要な対応は異なります。

Agent のステータスが not compatible (Ver. 2.5.1で解消)

問題

ダッシュボード、リソースの画面にて、Agent ver 2.5.0 であっても not compatible の警告表示が出る

対応

joc サービスを再起動することで、正常表示となることを確認

ver 2.5.1 で解消したことを確認済み

joc が起動しない (ver. 2.5.1で解消)

問題

新規インストールや、アップデート直後のJOCは起動したが、OSを再起動で、起動しなくなる
/var/log/messagesに下記メッセージを確認

Nov 19 15:32:34 js7joc jetty.sh: Starting Jetty: /opt/sos-berlin.com/js7/joc/jetty/bin/jetty.sh: 行 524: /var/run/joc/joc.pid: そのようなファイルやディレクトリはありません

該当ディレクトリが存在しないことを確認。作成後、正常起動を確認

mkdir /var/run/joc
chown scheduler: /var/run/joc

対応

joc サービス起動設定 /usr/lib/systemd/system/joc.service を確認するとpidの位置が変更となっている
ver. 2.4.1 では PIDFile=/opt/sos-berlin.com/js7/joc/joc.pid
ver. 2.5.0 では PIDFile=/var/run/joc/joc.pid

OS再起動時に、/var/run/joc以下が削除されることが原因。
そこで下記設定を追加することで、再起動時に/var/run/jocが消えないように対応

/etc/tmpfiles.d/joc.conf

#Type   Path                    Mode    UID        GID        Age  Argument
d       /var/run/joc            0755    scheduler  scheduler  -

ver. 2.5.1 で解消したことを確認済み

joc https 接続時のSNIエラー

問題

JOCへのアクセスにhttpsを使用している場合、適当なSSL証明書では、IPアドレス、ドメイン名の不一致によるSNIエラーがでる
HTTP ERROR 400 Invalid SNI

対応

検証用などで、https接続時に、適当な自己署名証明書で済ませている場合は、差し替えが必要。
証明書のSANに、ドメイン名、IPアドレス、ホスト名など、接続時に使いそうな情報を登録したものを使用する。（自己署名でも対応可）

JETTY_BASE が /opt/sos-berlin.com/js7/joc の場合
/opt/sos-berlin.com/js7/joc/start.ini の jetty.sslContext.keyStorePath で指定している証明書

httpのみの利用や、httpsの実装をリバースプロキシで行っている場合は、特別な対応は不要です。

モニター変数の変更について

通知で使用するモニター変数に、JOC_REVERSE_PROXY_HREF_XXXが追加された。
これにより、JOC_HREF_XXXにて、ドメイン名部分が定まらない問題の対応がなされた。

settings - joc にて、joc_reverse_proxy_url が追加されていることを確認。
ここに http://js7.saitamanokusa.net:4446 と入力すれば、下記モニター変数に、指定ドメインでの通知が飛ぶようになる
（設定追加後、Monitorサービスの再起動で反映された）

  • JOC_REVERSE_PROXY_HREF_JOB
  • JOC_REVERSE_PROXY_HREF_JOB_LOG
  • JOC_REVERSE_PROXY_HREF_ORDER
  • JOC_REVERSE_PROXY_HREF_ORDER_LOG
  • JOC_REVERSE_PROXY_HREF_WORKFLOW

joc_reverse_proxy_url 未設定の場合は、上記モニター変数は空となるため注意

その他、モニター変数で2.4.1より非推奨となっているものがあるので置き換えが必要
https://kb.sos-berlin.com/display/JS7/JS7+-+Notification+-+Configuration

  • MON_OS_WARN (非推奨) → MON_N_WARN に置き換え
  • MON_OS_WARN_TEXT (非推奨) → MON_N_WARN_TEXT に置き換え

通知の動作状況のチェック

ver. 2.4で、通知の動作が変更となったが、この点を改めて確認した。
※2.5アップデート内容とは関係ない。

問題

従来(2.3系まで)

  • 正常終了時は、Workflow終了時のみ通知
  • 警告、エラー時は随時通知

現状(2.4.1以降)
※Notificationの設定によって、動作が異なる

  • 各Job毎にSccessの通知
  • WorkflowJob設定を消すと、警告や、Failパーツ利用時のエラーが通知されない

原因

この修正が影響していると考えられる
https://change.sos-berlin.com/browse/JOC-1368?src=confmacro

  • WorkflowJob の要素がある場合は、Job単位の通知を対象とする
  • WorkflowJob の要素がない場合は、Workflowの通知を対象とする

このため、Workflowの通知とJobの通知を区別して設定をする必要がある。

通知イベントの整理

Workflow実行状態に応じた通知イベントの発生状況を整理しました。
※色付きは通知を飛ばしたいイベント

通常のWorkFlow実行（複数Job）
各Jobの終了時およびWorkflow終了時に通知イベントが発生する

Workflowの状態 Notificationで検出できる通知イベントWorkflow/Job + TYPE
Workflow開始 －
Job開始 －
Job正常終了 Job - SUCCESS
Job開始 －
Job正常終了 Job - SUCCESS
Workflow正常終了 Workflow - SCCESS

途中で警告
警告を出すが、エラーにはしない場合 (returncode,stderr,shorter,longerなど ※Jobの設定による)
警告発生時点で、Jobの通知イベント発生
ただしエラーにならなければ、Job、Workflow終了時に通知イベントが発生する

Workflowの動作 Notification設定で検出できる通知イベントWorkflow/Job + TYPE
Workflow開始 －
Job開始 －
Job警告 Job - WARNING
Job正常終了 Job - SUCCESS
Workflow正常終了 Workflow - SCCESS

Jobがエラーで終了
この場合、JobエラーとWorkflowエラーの両方の通知イベントが発生

Workflowの動作 Notification設定で検出できる通知イベントWorkflow/Job + TYPE
Workflow開始 －
Job開始 －
Jobエラー Job - ERROR
Workflowエラー Workflow - ERROR

FAILパーツ利用でエラー終了
FailパーツはJobのエラーと見なされず、Workflowエラーの通知イベントのみが発生

Workflowの動作 Notification設定で検出できるイベントWorkflow/Job + TYPE
Workflow開始 －
途中省略 －
FAILパーツ利用 －
Workflowエラー Workflow - ERROR

つまり検出したい通知イベントは、下記３つ

  • Workflow - SCCESS
  • Job - WARNING
  • Workflow - ERROR

対応

Notification設定を、下記のように修正することで、意図した通知が飛ぶようになりました。

  • ObjectFragment に2つの設定を追加
    • any_job ・・・ WorkflowJobを追加したもの（中身は空でよい）→Job通知イベントを検出
    • any_workflow ・・・ WorkflowJobを削除したもの→Workflow通知イベントを検出
  • 通知タイプ毎に、NotificationObjectの設定を分ける
    • SUCCESS → any_workflow (Workflow通知イベントのみを対象)
    • WARNING → any_job (Job通知イベントのみを対象)
    • ERRROR → any_workflow (Workflow通知イベントのみを対象)

ちょっと分かりづらいですが、こんな設定で対応してます
image.png

Notification スキーマ差し替え（docker版のみ）

問題

Notification の設定にて、SystemNotificationの設定が表示されない。
(DB接続エラーなど発生した場合の通知機能)

対応

docker版jocは、マウント先を再作成しない限り、スキーマファイルの更新が行われない。
この影響で、docker版でアップデートをした場合、Notificationのメニューが変更されない。
対策として、手動での差し替えが必要。
https://kb.sos-berlin.com/display/JS7/JS7+-+Notification+XSD+Schema+file+not+found

上記サイトより、Notification_configuration_v1.0.xsd をダウンロードし、JETTY_BASE/resources/joc/xsd/notification/Notification_configuration_v1.0.xsdを上書きします。

こちらの記事で構築した場合は、下記ファイルを上書きしてください。
JS7® JobScheduler docker-compose で起動(MySQL版)
JS7® JobScheduler docker-compose で起動(PostgreSQL版)
js7-joc-primary-config/xsd/notification/Notification_configuration_v1.0.xsd

上書き後、Notificationメニューを開き直すと Configurations - Notifications よりSystemNotificationが選べるようになります。
（サービス再起動もなく、既存の設定のまま、メニュー変更が反映された）

※2.5.1 で新規セットアップの場合は不要

※通常のセットアップ環境では、アンインストール、インストールのタイミングで更新されます。

dockerでhttps対応する場合にjocが起動しない

問題

ver 2.4.1 までは、 単純に https-keystore.p12,https-truststore.p12 の2つのファイルを配置し、 docker 起動時のオプションを指定すれば、https有効での起動ができた。
（JS7® JobScheduler docker-compose で起動(MySQL版) の手順に従う場合は、js7-joc-primary-configディレクトリ以下に2ファイルを配置）
【参考】JS7 - Configuration for Docker Containers

ver 2.5.1 では、 https-keystore.p12 を配置すると、 joc のコンテナが起動しない。

原因

joc ver 2.5.x イメージより、 JETTYの起動設定が、start.iniではなく、start.d以下のファイルを読み込むようになった。しかし、start.d以下には、keystore, trustsotre 関連の設定が入っていない。

対応

start.d 以下に、jetty_ssl.ini (ファイル名は適当) を作成し、下記設定を追加することで、https 有効での起動ができることを確認。

## Keystore file path (relative to $jetty.base)
jetty.sslContext.keyStorePath=resources/joc/https-keystore.p12

## Truststore file path (relative to $jetty.base)
jetty.sslContext.trustStorePath=resources/joc/https-truststore.p12

## Keystore password
jetty.sslContext.keyStorePassword=jobscheduler

## KeyManager password (same as keystore password for pkcs12 keystore type)
jetty.sslContext.keyManagerPassword=jobscheduler

## Truststore password
jetty.sslContext.trustStorePassword=jobscheduler

## Connector port to listen on
jetty.ssl.port=

なお補足ですが、jetty.sslContext.keyStorePath の設定値は恐らく反映されず、
https-keystore.p12 固定となるようです。

※カスタム証明書を利用する際は、このファイル名にする必要がある

1
0
0

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
  3. You can use dark theme
What you can do with signing up
Sign upLogin
1
0