Successfully reported this slideshow.

複数Redmine環境におけるユーザ管理の効率化

0

Share

1 of 17
1 of 17

複数Redmine環境におけるユーザ管理の効率化

0

Share

Download to read offline

Description

複数Redmine環境におけるユーザ管理の効率化
Redmine multi host-usermanagement

Transcript

  1. 1. 2020/11/14 第19回redmine.tokyo 勉強会 複数Redmine環境におけるユーザ管理作業の効率化 @y503unavailable 1 複数Redmine環境における ユーザ管理作業の効率化 2020/11/14 redmine.tokyo 第19回勉強会 @y503unavailable
  2. 2. 2020/11/14 第19回redmine.tokyo 勉強会 複数Redmine環境におけるユーザ管理作業の効率化 @y503unavailable 2 自己紹介 • 名前:奈良 裕記 ( y503unavailable <- httpエラーコード503) – 製造業で開発部署のadminしてます。 • RedmineTokyoスタッフ unofficialcooking カスタマイズ情報サイト担当 – https://redmine.tokyo/projects/unofficialcooking • Kindle本やYoutube動画も作成、unofficial-redmine.org – https://www.slideshare.net/y503unavailable/unofficial-redmine-japan2020 • 6年前にRedmineサーバ統合を実施 (この時のDB構造知見が今回役に立った) – https://www.slideshare.net/y503unavailable/redmine-42182169
  3. 3. 2020/11/14 第19回redmine.tokyo 勉強会 複数Redmine環境におけるユーザ管理作業の効率化 @y503unavailable 3 お断りと連絡先 • 本LTの内容はPoC段階であり無保証です。(普段よりも) • 実施時は自己責任でお願いします。 ご意見・ご提案などは Redmine.Tokyoのunofficialcookingまでお願いします。 https://redmine.tokyo/issues/1188 画面デモなど希望あれば、ユーザディスカッションの#1か懇 親会で声掛けてください。
  4. 4. 2020/11/14 第19回redmine.tokyo 勉強会 複数Redmine環境におけるユーザ管理作業の効率化 @y503unavailable 4 Redmineは1台で足りますか? • 大規模運用で数百人/複数部署/複数用途で利用する場合、 1台のRedmine内に無理やり押し込んで運用するより、 複数のRedmineサーバに分割する方が運用し易い。 – 1台のRedmineの中でシステムレベル設定項目の使い分けは困 難。ユーザ間調整も面倒。 – Redmineの利用状況、利用者間の関係、admin間の関係、現場 差異、現場モチベーション –無理に統合 << 分割+統合管理仕組
  5. 5. 2020/11/14 第19回redmine.tokyo 勉強会 複数Redmine環境におけるユーザ管理作業の効率化 @y503unavailable 5 Redmineの設定項目分類 区分 設定者 内容 システム単位の設定 Redmine管理者 トラッカー、ロール、ワークフロー、ステータス、カ スタムフィールド定義、用語定義、ユーザグループ定 義、その他システムレベル設定 Project単位の設定 PJ管理者 プロジェクト階層毎設定、バージョン、カテゴリ、メ ンバー ユーザ設定 各ユーザ 名前、パスワード、管理者権限、言語設定など システム単位の設定項目は、Redmine管理者のみが設定できる。 つまり、サーバの統合により、Redmine管理者の権限が無くなると、従来 行えていたシステムレベルの管理作業が行えなくなる。 (本表の対象は設定項目のみ、チケット/変更記録/活動は除外した。)
  6. 6. 2020/11/14 第19回redmine.tokyo 勉強会 複数Redmine環境におけるユーザ管理作業の効率化 @y503unavailable 6 複数Redmine運用時の課題と改善案 • 単に複数Redmineを運用するだけなら苦労しない。 • しかしRedmine間で内容を連携し活用、組織単位などで集計したい場合、 運用負荷がn倍になる。 • 課題例 – 人事異動対応/各サーバ毎実行必要(人事異動/新人/退職) – 組織/ユーザ単位の利用状況集計作業が面倒 (ユーザID/組織グループがサーバ毎に異なるため、余計な変換作業が発生) • 改善案 – サーバ間でユーザとグループの定義内容の同一性を確保する。 – 変更内容を自動反映する(名前、パスワード変更、無効化、所属変更) – Redmine自体の機能で実現する必然性は無い。データはDB上だからDBの機能で実現すれば良い。
  7. 7. 2020/11/14 第19回redmine.tokyo 勉強会 複数Redmine環境におけるユーザ管理作業の効率化 @y503unavailable 7 実現手法 下記手順により対応した(DBのテーブル単位複製) 1. Redmineをprimary/secondary(複数可)に分ける。 2. ユーザ/グループ定義の変更作業はprimaryのRedmineでのみ実施 (各個人またはシステム管理者の設定) 3. secondary側は、ユーザIDを追加不可の設定にする。 管理/設定/認証/ユーザーによるアカウント登録-無効 4. DBのテーブル単位複製機能を利用 – primary上のユーザ定義/グループ定義情報の変更のみを、secondaryに複製する。(DB設定) – (usersと users-groupsテーブル) – secondary側のreadonly指定は実施しない primary secondary users,users-groupsのみ複製
  8. 8. 2020/11/14 第19回redmine.tokyo 勉強会 複数Redmine環境におけるユーザ管理作業の効率化 @y503unavailable 8 一応動いた ・動作確認内容 ユーザ/グループ定義が正しく反映されることを確認した 1. primary側のユーザ名を変更、secondary側を再表示し反映済確認 2. secondary側ユーザ名を変更、primary側を再表示し反映無確認 3. primary側ユーザ名を再度変更、secondary側を再表示し反映済確認 4. primary側グループ登録内容を変更、 secondary側を再表示し反映済確認 • 試行環境 – CentOS7,MariaDB10,Redmine4.1-trunk(unofficial-redmine版) – DB設定手順は本資料末尾の参考資料を参照 users,users-groupsのみ複製 primary secondary
  9. 9. 2020/11/14 第19回redmine.tokyo 勉強会 複数Redmine環境におけるユーザ管理作業の効率化 @y503unavailable 9 ご利益と落とし穴 • 本設定による利点 – Redmineのユーザ/グループ定義作業箇所を一か所に集約した。 (人事異動対応作業効率化) – Redmineサーバ間のデータ分析、連携が容易になった。 • 問題点と対応 – 単にDBで設定内容を一元管理しただけなので、 問題点(+対策案)は勿論ある。 (次頁以降) users,users-groupsのみ複製
  10. 10. 2020/11/14 第19回redmine.tokyo 勉強会 複数Redmine環境におけるユーザ管理作業の効率化 @y503unavailable 10 問題点と対策1 primaryへのログイン時、secondaryの最終ログイ ン日時が変更される。ユーザ使用状況把握困難 対策 ・primary側のソースを変更し更新させない – models/user.rb: def update_last_login_on! パスワード/名前変更時には変更されてしまうが、 大規模環境ならAD利用で直接変更しないのでは? 原因 users.last_login_on (最終ログイン日時)も複製されるため
  11. 11. 2020/11/14 第19回redmine.tokyo 勉強会 複数Redmine環境におけるユーザ管理作業の効率化 @y503unavailable 11 問題点と対策2 各secondaryのみのシステム管理者権限を設定できない secondary管理者へのprimary管理者権限設定は不可 対策案(未検証) • secondary内でDBのレプリケーショントリガーを利用し、 usersテーブル更新時に、特定IDにadminを強制設定する • 定期的にsqlでupdateする。(頻繁な変更は無い筈) システム管理者権限のフラグは、users.adminであり、 primaryの内容が当然複製される。
  12. 12. 2020/11/14 第19回redmine.tokyo 勉強会 複数Redmine環境におけるユーザ管理作業の効率化 @y503unavailable 12 問題点と対策3 secondary側で、ユーザ情報・グループ定義情報の 変更/追加/削除操作が可能だが primary側更新で,ユーザ情報上書/グループ定義破損する。 対策  運用で対処(危険)  secondary側のソース変更し更新操作させない  Viewcustomizeでメニューから項目削除  特定ユーザに対して一部管理者メニューを非表示にする  https://github.com/onozaty/redmine-view-customize-scripts/blob/master/hide_part_of_admin_menu.js 原因 グループ定義は、グループ定義中ユーザ単位のレコードのため
  13. 13. 2020/11/14 第19回redmine.tokyo 勉強会 複数Redmine環境におけるユーザ管理作業の効率化 @y503unavailable 13 問題点と対策4 他にも問題点あるかもしれない(未検証) 二要素認証のusers.twofa_totp_last_used_at など心配 各環境で検証お願いします。本LTはPoC段階の提案です。 原因 usersテーブル内に、定義情報とサー バ内動的情報が同居している以上不可避
  14. 14. 2020/11/14 第19回redmine.tokyo 勉強会 複数Redmine環境におけるユーザ管理作業の効率化 @y503unavailable 14 追加対応1 特定グループ定義の編集権限のみ移譲したい – 一部のグループ定義が、頻繁に変更される。 (特定secondaryのみ利用) – SEC&作業負荷面から、当該グループ定義の変更権限 のみをsecondary管理者に委譲したい。 対策 – 下記手法で外部の専用コマンドを作成する。 (特定グループIDのみ変更可能にする) – 【Redmine】Python で Redmine CLI ツールを作ってみる! https://mlog.wlaboratory.com/entry/category/tools/redmine/python-redmine-cli
  15. 15. 2020/11/14 第19回redmine.tokyo 勉強会 複数Redmine環境におけるユーザ管理作業の効率化 @y503unavailable 15 追加対応2 ユーザ・グループ定義以外の、 他のシステムレベル定義項目も共通化したい 参考資料(DB設計) • RedmineのDB設計参考資料(サーバ統合事例)https://www.slideshare.net/y503unavailable/redmine-42182169 • Redmineデータベースのテーブル構造を紐解いてみるhttps://docs.google.com/presentation/d/e/2PACX- 1vSGC3DEnLZqAEs4zRmkCsrEz4m3Uj0qo0fiMHi2JexyVYUdV6wjoUftoIhhVTc1C- r_6lJDDOBuafvu/pub?start=false&loop=false&delayms=3000&slide=id.p 対策 システムレベル項目の各テーブルも、テーブル単位で複製すれば良い。 (トラッカー,ステータス,ロール,ワークフロー,カスタムフィールド) trackers, issue_statuses , roles,roles_managed_roles, workflows, custom_fields,custom_fields_roles,custom_fields_trackers,
  16. 16. 2020/11/14 第19回redmine.tokyo 勉強会 複数Redmine環境におけるユーザ管理作業の効率化 @y503unavailable 16 参考文献(DB複製関連) 具体的なDB設定手順は、下記など参照してください。 • [MySQL][MariaDB] DBのレプリケーション構築手順 – https://qiita.com/suzutsuki0220/items/e5be03ea8f44ad2f6533 • Replication Filters – https://mariadb.com/kb/en/replication-filters/ • スレーブのレプリケーションフィルターについて – https://gihyo.jp/dev/serial/01/mysql-road-construction-news/0088 • mariadbのスレーブトリガーを試してみる。(slave_run_triggers) – https://qiita.com/sand_bash/items/b6169757e7d32df88467 • postgresql-10以降でテーブル単位の複製が可能(ロジカルレプリケーション) – https://oss-db.jp/dojo/dojo_column_01 • 論理レプリケーション – https://www.postgresql.jp/document/11/html/logical-replication.html 今回の/etc/my.cnf 追加内容(参考) 複製元Redmine [mysqld] log-bin server-id=1 expire_logs_days=5 replicate-do-table=redmine.user replicate-do-table=redmine.groups_users 複製先Redmine [mysqld] server-id=2 replicate-do-table=redmine.users replicate-do-table=redmine.groups_users 接続状況確認 show slave status; show master status;
  17. 17. 2020/11/14 第19回redmine.tokyo 勉強会 複数Redmine環境におけるユーザ管理作業の効率化 @y503unavailable 17 御清聴ありがとうございました • 各自のRedmine運用に、多少なりとも役に立て ば幸いです。 • Redmineはオープンソースソフトです。 –協力して育成&利用していきましょう。 ユーザ会はそのための場所です。 • ご意見、内容指摘の連絡先 redmine.Tokyo UnofficialCooking unofficial-redmine.org y503unavailable@ twitter, slack

Description

複数Redmine環境におけるユーザ管理の効率化
Redmine multi host-usermanagement

Transcript

  1. 1. 2020/11/14 第19回redmine.tokyo 勉強会 複数Redmine環境におけるユーザ管理作業の効率化 @y503unavailable 1 複数Redmine環境における ユーザ管理作業の効率化 2020/11/14 redmine.tokyo 第19回勉強会 @y503unavailable
  2. 2. 2020/11/14 第19回redmine.tokyo 勉強会 複数Redmine環境におけるユーザ管理作業の効率化 @y503unavailable 2 自己紹介 • 名前:奈良 裕記 ( y503unavailable <- httpエラーコード503) – 製造業で開発部署のadminしてます。 • RedmineTokyoスタッフ unofficialcooking カスタマイズ情報サイト担当 – https://redmine.tokyo/projects/unofficialcooking • Kindle本やYoutube動画も作成、unofficial-redmine.org – https://www.slideshare.net/y503unavailable/unofficial-redmine-japan2020 • 6年前にRedmineサーバ統合を実施 (この時のDB構造知見が今回役に立った) – https://www.slideshare.net/y503unavailable/redmine-42182169
  3. 3. 2020/11/14 第19回redmine.tokyo 勉強会 複数Redmine環境におけるユーザ管理作業の効率化 @y503unavailable 3 お断りと連絡先 • 本LTの内容はPoC段階であり無保証です。(普段よりも) • 実施時は自己責任でお願いします。 ご意見・ご提案などは Redmine.Tokyoのunofficialcookingまでお願いします。 https://redmine.tokyo/issues/1188 画面デモなど希望あれば、ユーザディスカッションの#1か懇 親会で声掛けてください。
  4. 4. 2020/11/14 第19回redmine.tokyo 勉強会 複数Redmine環境におけるユーザ管理作業の効率化 @y503unavailable 4 Redmineは1台で足りますか? • 大規模運用で数百人/複数部署/複数用途で利用する場合、 1台のRedmine内に無理やり押し込んで運用するより、 複数のRedmineサーバに分割する方が運用し易い。 – 1台のRedmineの中でシステムレベル設定項目の使い分けは困 難。ユーザ間調整も面倒。 – Redmineの利用状況、利用者間の関係、admin間の関係、現場 差異、現場モチベーション –無理に統合 << 分割+統合管理仕組
  5. 5. 2020/11/14 第19回redmine.tokyo 勉強会 複数Redmine環境におけるユーザ管理作業の効率化 @y503unavailable 5 Redmineの設定項目分類 区分 設定者 内容 システム単位の設定 Redmine管理者 トラッカー、ロール、ワークフロー、ステータス、カ スタムフィールド定義、用語定義、ユーザグループ定 義、その他システムレベル設定 Project単位の設定 PJ管理者 プロジェクト階層毎設定、バージョン、カテゴリ、メ ンバー ユーザ設定 各ユーザ 名前、パスワード、管理者権限、言語設定など システム単位の設定項目は、Redmine管理者のみが設定できる。 つまり、サーバの統合により、Redmine管理者の権限が無くなると、従来 行えていたシステムレベルの管理作業が行えなくなる。 (本表の対象は設定項目のみ、チケット/変更記録/活動は除外した。)
  6. 6. 2020/11/14 第19回redmine.tokyo 勉強会 複数Redmine環境におけるユーザ管理作業の効率化 @y503unavailable 6 複数Redmine運用時の課題と改善案 • 単に複数Redmineを運用するだけなら苦労しない。 • しかしRedmine間で内容を連携し活用、組織単位などで集計したい場合、 運用負荷がn倍になる。 • 課題例 – 人事異動対応/各サーバ毎実行必要(人事異動/新人/退職) – 組織/ユーザ単位の利用状況集計作業が面倒 (ユーザID/組織グループがサーバ毎に異なるため、余計な変換作業が発生) • 改善案 – サーバ間でユーザとグループの定義内容の同一性を確保する。 – 変更内容を自動反映する(名前、パスワード変更、無効化、所属変更) – Redmine自体の機能で実現する必然性は無い。データはDB上だからDBの機能で実現すれば良い。
  7. 7. 2020/11/14 第19回redmine.tokyo 勉強会 複数Redmine環境におけるユーザ管理作業の効率化 @y503unavailable 7 実現手法 下記手順により対応した(DBのテーブル単位複製) 1. Redmineをprimary/secondary(複数可)に分ける。 2. ユーザ/グループ定義の変更作業はprimaryのRedmineでのみ実施 (各個人またはシステム管理者の設定) 3. secondary側は、ユーザIDを追加不可の設定にする。 管理/設定/認証/ユーザーによるアカウント登録-無効 4. DBのテーブル単位複製機能を利用 – primary上のユーザ定義/グループ定義情報の変更のみを、secondaryに複製する。(DB設定) – (usersと users-groupsテーブル) – secondary側のreadonly指定は実施しない primary secondary users,users-groupsのみ複製
  8. 8. 2020/11/14 第19回redmine.tokyo 勉強会 複数Redmine環境におけるユーザ管理作業の効率化 @y503unavailable 8 一応動いた ・動作確認内容 ユーザ/グループ定義が正しく反映されることを確認した 1. primary側のユーザ名を変更、secondary側を再表示し反映済確認 2. secondary側ユーザ名を変更、primary側を再表示し反映無確認 3. primary側ユーザ名を再度変更、secondary側を再表示し反映済確認 4. primary側グループ登録内容を変更、 secondary側を再表示し反映済確認 • 試行環境 – CentOS7,MariaDB10,Redmine4.1-trunk(unofficial-redmine版) – DB設定手順は本資料末尾の参考資料を参照 users,users-groupsのみ複製 primary secondary
  9. 9. 2020/11/14 第19回redmine.tokyo 勉強会 複数Redmine環境におけるユーザ管理作業の効率化 @y503unavailable 9 ご利益と落とし穴 • 本設定による利点 – Redmineのユーザ/グループ定義作業箇所を一か所に集約した。 (人事異動対応作業効率化) – Redmineサーバ間のデータ分析、連携が容易になった。 • 問題点と対応 – 単にDBで設定内容を一元管理しただけなので、 問題点(+対策案)は勿論ある。 (次頁以降) users,users-groupsのみ複製
  10. 10. 2020/11/14 第19回redmine.tokyo 勉強会 複数Redmine環境におけるユーザ管理作業の効率化 @y503unavailable 10 問題点と対策1 primaryへのログイン時、secondaryの最終ログイ ン日時が変更される。ユーザ使用状況把握困難 対策 ・primary側のソースを変更し更新させない – models/user.rb: def update_last_login_on! パスワード/名前変更時には変更されてしまうが、 大規模環境ならAD利用で直接変更しないのでは? 原因 users.last_login_on (最終ログイン日時)も複製されるため
  11. 11. 2020/11/14 第19回redmine.tokyo 勉強会 複数Redmine環境におけるユーザ管理作業の効率化 @y503unavailable 11 問題点と対策2 各secondaryのみのシステム管理者権限を設定できない secondary管理者へのprimary管理者権限設定は不可 対策案(未検証) • secondary内でDBのレプリケーショントリガーを利用し、 usersテーブル更新時に、特定IDにadminを強制設定する • 定期的にsqlでupdateする。(頻繁な変更は無い筈) システム管理者権限のフラグは、users.adminであり、 primaryの内容が当然複製される。
  12. 12. 2020/11/14 第19回redmine.tokyo 勉強会 複数Redmine環境におけるユーザ管理作業の効率化 @y503unavailable 12 問題点と対策3 secondary側で、ユーザ情報・グループ定義情報の 変更/追加/削除操作が可能だが primary側更新で,ユーザ情報上書/グループ定義破損する。 対策  運用で対処(危険)  secondary側のソース変更し更新操作させない  Viewcustomizeでメニューから項目削除  特定ユーザに対して一部管理者メニューを非表示にする  https://github.com/onozaty/redmine-view-customize-scripts/blob/master/hide_part_of_admin_menu.js 原因 グループ定義は、グループ定義中ユーザ単位のレコードのため
  13. 13. 2020/11/14 第19回redmine.tokyo 勉強会 複数Redmine環境におけるユーザ管理作業の効率化 @y503unavailable 13 問題点と対策4 他にも問題点あるかもしれない(未検証) 二要素認証のusers.twofa_totp_last_used_at など心配 各環境で検証お願いします。本LTはPoC段階の提案です。 原因 usersテーブル内に、定義情報とサー バ内動的情報が同居している以上不可避
  14. 14. 2020/11/14 第19回redmine.tokyo 勉強会 複数Redmine環境におけるユーザ管理作業の効率化 @y503unavailable 14 追加対応1 特定グループ定義の編集権限のみ移譲したい – 一部のグループ定義が、頻繁に変更される。 (特定secondaryのみ利用) – SEC&作業負荷面から、当該グループ定義の変更権限 のみをsecondary管理者に委譲したい。 対策 – 下記手法で外部の専用コマンドを作成する。 (特定グループIDのみ変更可能にする) – 【Redmine】Python で Redmine CLI ツールを作ってみる! https://mlog.wlaboratory.com/entry/category/tools/redmine/python-redmine-cli
  15. 15. 2020/11/14 第19回redmine.tokyo 勉強会 複数Redmine環境におけるユーザ管理作業の効率化 @y503unavailable 15 追加対応2 ユーザ・グループ定義以外の、 他のシステムレベル定義項目も共通化したい 参考資料(DB設計) • RedmineのDB設計参考資料(サーバ統合事例)https://www.slideshare.net/y503unavailable/redmine-42182169 • Redmineデータベースのテーブル構造を紐解いてみるhttps://docs.google.com/presentation/d/e/2PACX- 1vSGC3DEnLZqAEs4zRmkCsrEz4m3Uj0qo0fiMHi2JexyVYUdV6wjoUftoIhhVTc1C- r_6lJDDOBuafvu/pub?start=false&loop=false&delayms=3000&slide=id.p 対策 システムレベル項目の各テーブルも、テーブル単位で複製すれば良い。 (トラッカー,ステータス,ロール,ワークフロー,カスタムフィールド) trackers, issue_statuses , roles,roles_managed_roles, workflows, custom_fields,custom_fields_roles,custom_fields_trackers,
  16. 16. 2020/11/14 第19回redmine.tokyo 勉強会 複数Redmine環境におけるユーザ管理作業の効率化 @y503unavailable 16 参考文献(DB複製関連) 具体的なDB設定手順は、下記など参照してください。 • [MySQL][MariaDB] DBのレプリケーション構築手順 – https://qiita.com/suzutsuki0220/items/e5be03ea8f44ad2f6533 • Replication Filters – https://mariadb.com/kb/en/replication-filters/ • スレーブのレプリケーションフィルターについて – https://gihyo.jp/dev/serial/01/mysql-road-construction-news/0088 • mariadbのスレーブトリガーを試してみる。(slave_run_triggers) – https://qiita.com/sand_bash/items/b6169757e7d32df88467 • postgresql-10以降でテーブル単位の複製が可能(ロジカルレプリケーション) – https://oss-db.jp/dojo/dojo_column_01 • 論理レプリケーション – https://www.postgresql.jp/document/11/html/logical-replication.html 今回の/etc/my.cnf 追加内容(参考) 複製元Redmine [mysqld] log-bin server-id=1 expire_logs_days=5 replicate-do-table=redmine.user replicate-do-table=redmine.groups_users 複製先Redmine [mysqld] server-id=2 replicate-do-table=redmine.users replicate-do-table=redmine.groups_users 接続状況確認 show slave status; show master status;
  17. 17. 2020/11/14 第19回redmine.tokyo 勉強会 複数Redmine環境におけるユーザ管理作業の効率化 @y503unavailable 17 御清聴ありがとうございました • 各自のRedmine運用に、多少なりとも役に立て ば幸いです。 • Redmineはオープンソースソフトです。 –協力して育成&利用していきましょう。 ユーザ会はそのための場所です。 • ご意見、内容指摘の連絡先 redmine.Tokyo UnofficialCooking unofficial-redmine.org y503unavailable@ twitter, slack

More Related Content

Related Books

Free with a 30 day trial from Scribd

See all

Related Audiobooks

Free with a 30 day trial from Scribd

See all

×