whywaita Advent Calendar 2018 17日目
個人的にwhywaitaの好きなところ
ノリで登録したけど書くことが特に無いので個人的にwhywaitaの好きなところを書きます。
深夜テンションで書いたポエムに必ずリアクションをくれるところ
深夜、京都を代表する和菓子の一つの食べ物をハンドルにしている某氏から、
彼女?との惚気話を聞かされ、精神が壊れてtimesにポエムを投下していると必ずリアクションをしてくれます。
優しいですね。
ちなみに付けてくれるリアクションは12/15 の記事にも書かれていた :ok_woman:
です。
松屋にめっちゃ反応するわいわいた
新大阪駅前の松屋を見つけた時に、指をさしながら「えぇ!?あれ!?マジっ!?やばくね!?」って感じの宝物を見つけた子供みたいな顔でめっちゃアピールされのを覚えています。
このことからとても松屋が好きなんだろうなということが伺えます。
10分ほど笑いがこらえられず腹筋が筋肉痛になりました。
ちなみに私は毎日夕食に松屋で330円の牛丼ミニを食べるのが日課です。
スペルが分かりにくい問題
今ではwhywaitaと空で書けますが初めはwhywhyitaなのかwywaitaなのかwiwhytaなのかなかなか覚えられなかった気がします。
最初の頃はわざわざSlackかTwitterを開いてIDをコピペしてました。
でも実は未だに稀によく間違えます。
(これ好きなところ全く関係ないですね)
実はネコ科の動物
実はwhywaitaはネコ科の動物、というかネコらしいです。
whywaitaの後輩が言っていたので間違いありません。(私じゃないです)
トーク力がすごい
突然5分間で小話してくれと言われてスッとこなせちゃうのカッコいい
あの時100人くらい居た気がするんですけど流石すぎる
私ならプレッシャーで逃げ出してしまう気がする
さすがわいわいたです。
LT力?がすごい
毎回よくあの短時間でスライド作ってあのクオリティでLTが出来るなぁと感心します。
トーク力の高さもあいまって毎回おもしろいです。
さすがわいわいたです。
その、なんかこう...、そこはかとなくいい感じですよね!
さすがわいわいたです。
まとめ
ハンドルのスペルが分かりにくくて深夜テンションで書いたポエムに必ずリアクションをくれてトーク力とLT力があり松屋にめっちゃ反応するそこはかとなくいい感じなネコ
さすがわいわいたです。
煽ってないです。
WCDI Advent Calendar 2018 1日目
これは WCDI Advent Calendar 2018 1日目の記事です。
こんにちはこんばんは。初代部長です。 ダラダラと適当なことを書きます。
ちなみに現在時刻は 2018/12/01 22:21 です。(間に合うのかこれ)
初日から遅刻してしまうのもアレなので頑張って書きます()
そもそもWCDIってなんやねんって話ですが、遡ること4年前、私が学生時代に作った「情報技術研究部」というサークルが、技術系のコンテストに出る時に使っていたチーム名です。
なんやかんやでサークルの名前とチーム名がごっちゃになっていってWCDI=サークルみたいな認識になっている気がします。
(本当はWCDIという名前を考えたのは私の先輩で、その先輩からWCDIを受け継いだのが始まりだったり色々と有るんだけれど話が長くなるのでまた後日)
このさーくる、私が1年生の時に作って、そこから1年半くらいは人が集まらず(新しく入部した人もすぐに幽霊部員になってしまって)事実上の活動休止状態になってたような気がしますが、
私が卒業した去年の3月時点ではちゃんと毎日勉強会を開くくらいにはまともに活動するようになっていたので、なかなかいい感じのサークルになったなあと嬉しく思ってます。
夏休み返上して毎日20時まで勉強会やってたのは今考えるとなかなかハードだった気もしますが、アレはアレで楽しかったです。
目標だった在学中に部室を手に入れてラックをおいて楽園を作る的なアレは結局在学中には間に合いませんでしたが、どうやら私が卒業した後に実現できたみたいです。
Advent Calendarは前からWCDIでやってみたかったけれど、結局出来ずじまいで、今回冗談でやらないの?と聞いたら優秀(?)な後輩が一瞬で作ってくれました。
本当はサークルを立ち上げた時の感動秘話的なアレを書こうとしていたのだけれど、インターネッツに公開するようなことでも無いので心の内に秘めておきます。
( 本当は書くつもりだったけど忘れてただけだなんて言えない )
(なんか無限に書くことが有るような気がしていたけれど、実際に書き始めるとあんま書くこと無いですね)
まあ文才も無いしあんまり長いこと書いても読みにくいだけなのでこのくらいで
感動秘話的なのは次回か来年のAdvent Calendarで書くことにします。
--
ところで書いたのはいいんですけどこれどこにアップロードしよう?
とりあえず三日坊主になってたブログに投下しておきます。
ISUCON6で予選敗退した
ISUCON6の予選にチームWCDIとして出てきました。
スコアは6,000ちょいでした。
別のメンバーが詳しく書いてるので感想的なものだけ。
ISUCONは前々から興味があって出たいなーとか思っていたのですが
なかなか一緒に出てくれるメンバーが集まらなかったりで参加できずじまいでした。
今回は運良くメンバーが見つかったので念願の初参加です。
事前準備する時間がほとんどなかったのでとりあえず全員が書ける言語でってことでPythonを選択しました。
(ただ今までの予選の結果や本戦の言語選択を見ると若干Python不利なんじゃないかなーとか思ってたのはここだけの秘密。)
私の担当はRedisまわりやキャッシング的な部分でした。
とりあえずRedisを使うのは初めてだったので一週間ぐらいで突貫工事しました。
ただ本番でDBをRedisに乗せようってことになったのですが普段やってないことはやっぱり出来ないものですね...結局実装が間に合わないだろうと判断して断念してしまいました。(くやしい
ISUCONは事前準備が大事だと言う話をちらほら見かけたのですが
まさにそのとおりだなと感じました。
でもチームメンバーとあーだこーだ言いながらチューニングしていくのはやっぱり楽しかったです。 次回は本戦行けるといいなあ。
第6回ICTSCトラブルシューティングコンテストで優秀賞をもらった&writeupのようなもの
2016-09-15 "感想とか" の下辺りに成績表やメンバーのブログなどを追記しました
8月27,28日に大阪で開催された第6回トラブルシューティングコンテストにチームWCDIとして参加してきました。
今回もひっそりと記録を書き残しておきたいと思います。
今回で4回目の参加です。前回と同じくサーバサイドを担当しました。
ちなみに第5回の記事↓
blog.hnron.net
今見たら前回の記事があまりにも適当だったので今回は割と真面目に書きます。
今年のメンバー
前回のメンバーから3年生が1人抜けて代わりに1年生が1人入りました。
3年2人、2年2人、1年1人の構成です。
役割分担ですが、今回はサーバサイド2人、ネットワークサイド2人、フルスタック1人にし、
サーバとネットワークでどちらかに問題が偏った場合に、片方に負荷がかかりすぎないような構成にしました。
戦略とか色々
前回までの反省から戦略は色々と考えていました。
役割分担とか
(今年は色々と事情が変わりましたが、)
例年通りなら問題は、「1日目午前、1日目午後、2日目午前、2日目午後」の4つの区切りに分けて出題されます。
基本的には午前から午後、1日目から2日目とまたいで問題が出題されることはなく、制限時間はからなず各区切り内で終わるように設定されていました。
また、問題はだいたい3問ずつ出題され、サーバとネットワークの比率が 2:1 or 1:2 になるように出題されています。
前回まではサーバ3人ネットワーク2人のように分けていたため、人数が少ない方に高難易度の問題が集中すると負荷が偏ってしまうことがありました。
これを踏まえ今回の役割分担ではフルスタック枠を1人分用意しました。
結果として2日目午前までは安定して問題を解くことが出来ました。
しかし、2日目の午後は例年とは違った形で出題されました。午前からまたいで出題された問題が1問 + 午後新たに出題された問題が5問の計6問を2時間で解くことになりました。
かなり異例の問題ラッシュでしたが、問題が解けたかは置いておいて1人フルスタック構成がいい感じに機能し1人1問を上手く割り振れました。
(問題を解いている最中はサーバ問題4問ネットワーク問題2問だと思っていた)
範囲とか
いままでの反省から全員が同じ範囲を勉強するよりも、手分けして出来るだけ広範囲をカバーしたほうが安定するような気がしたので勉強内容がかぶらないよう担当範囲を調整しました。
また当日のタスク振りをスムーズにするために、勉強会ごとにどの技術をどのくらい学習したか(構築してトラブル事例を調べた、ドキュメント読んだだけなど)をslackにあげて共有しました。
slackといえば当日の情報共有は今までownCloudなどを用意していたのですが、slackだけでよくね?となったので今回はslackのみです。
問題の解き方とか(サーバサイド)
結構前からこのスタイルだったのですが、一番最初にトラブルの原因を見つけた人がそのまま解答提出まで一人で行うという感じで問題を解いています。
もう少し詳しく説明すると
問題が出題されたら誰がどの問題を解くかを割り振ります。(基本的にはその人が解きたい問題)
問題に割り振られた人が一人なら問題ないのですが、もし複数人が割り振られた場合は原因究明までは協力して行います。
ただし、トラブルの解決と報告は基本的に誰か一人だけで行うという感じです。
これは複数人でトラブルシュートしている際の「あれ?誰か今何かした?」などの "やらかした" 系を出来る限り防ぐためです。
本来であればコミュニケーションや情報共有をしっかり行っていれば "やらかした" は起こらないはずですが、
当日緊張していたりテンパったりするとわりと "やらかす" 場合が結構あったりするので自然とこのスタイルで問題を解くようになっていました。
気になってること
他のチームが2日目午後でどんな感じにメンバーにタスクを振ったのかが気になってます。
他には、さっき書いた問題の解き方で「トラブルの解決と報告は一人で行う」という方法ですが、他のチームはどういうふうに問題を解いてるかも気になっています。
結果
結果は優秀賞(2位)でした。
430点中、1位は219点、私達は175点でした。
2日目午前までの段階で9問中7問ぐらい解けていたのでそれなりに自信があったのですが、
2日目午後を6問中5問ほど落としてしまっているはずなので、そこができていたらと思うと結構悔しいです。
感想とか
今回も楽しかったです。
スコアサーバや出題パターンの変更など、新要素がいくつかあって新鮮味がありました。
個人的には2日目午後がいい感じに緊張感と絶望感があって楽しかったです。
また、いくつか新たな反省点も出てきたので次回はこれを踏まえて戦略を立てたいと思います。
チーム的には結構安定してきたように思います。 第3回大会ではボロ負けでしたが、第4回で最優秀賞、第5回で5位、第6回で優秀賞と安定して上位を取れるようになってきました。
サーバ問題は大体解けるようになってきたのでネットワーク側で確実に点が取れるように強化したいです。
次回は最優秀賞取ります (でも次回運営募集してたら運営もやってみたかったり)
2016-09-15 【追記】
追記その1
成績表が送られてきたので公開しておきます。
2日目午後、落とした問題が6問中5問だと思ってたら全問落としてた
あとやっぱり運営OBつよい
トラコンの成績表晒し
— うーろんちゃ氏 (@hnron) September 7, 2016
自分はWCDIチーム pic.twitter.com/o6P7jh6Y4Q
追記その2
最優秀賞のチームの方がブログでこの記事を紹介してくれてました。(ありがとうございます)
追記その3
あと後輩が残りのwritewpを書いてくれました。
writeup的な
以下writeupです
自分が触った問題だけです
答えがあってるかは保証できません
多分今年も公式で解答を出すと思うのでそんなに詳しくは書きません
Q3(1日目午前) 移行したアプリケーションが動かない!
アプリケーションはエラーログが表示されない仕様だったのでMySQLの設定とかログとか見てました。
書き込みが文字化けしていたので文字コードかなと思い色々探ってましたが特に問題はなし。(今考えたら文字化けはわざとでミスリードを狙ってたのかも)
後輩がおもむろにループバックアドレスに対してtcpdumpしたところ、MySQLのパケットを拾えたのでそこからエラーメッセージを拾ってきて原因を突き止めました。
ちなみにそのエラーメッセージ↓
In aggregated query without GROUP BY, expression #1 of SELECT list contains nonaggregated column 'dengon.message.id'; this is incompatible with sql_mode=only_full_group_by
後は後輩がやってくれました。
ちなみに提出した解答
ご依頼にありました件につきまして、サーバの更新によりMySQLのバージョンが変わってしまったのが原因でした。 新しいバージョンのMySQLは、「sql_mode」によるSQL文の判定条件が変わっており、以前より厳密に判定されるようになっていました。 tcpdumpでパケットを見て確認したところ、今回の伝言板アプリケーションはこの厳密な規格にそぐわない形式でgroup by句が使われているため、SQLでエラーが発生して投稿に失敗しておりました。 今回のプログラムはELFファイル(実行ファイル)だったため、ソースコードの変更は不可能だと判断し、MySQLサーバの設定の変更を行いました。そのため、以下のファイルを追加したしました。 /etc/mysql/conf.d/mysqld.cnf > [mysqld] > sqlmode=NOENGINE_SUBSTITUTION 以上の操作により正常に投稿が出来ることを確認いたしました。 以上、よろしくお願いいたします。
Q6(1日目午後) VMがネットワークにつながらない!
片方のVMにはアクセス出来るがもう片方にはアクセスできないという現象が発生してました。
arpingしたところ、どうやらmacアドレスが被っていたようなので、それをそのまま報告しました。
また、つながらない方のVMと同じIPアドレスを使用しているコンピュータがもう1台いるみたいだったのでそれも報告しておきました。
正式な解答?はVMをコピーしたらmacアドレスがそのままコピーされてしまってmacアドレスがコンフリクトした、だそうです。
最初はGARPでイタズラされてるのかなとも思い判断に悩みましたが、tcpdumpの結果や、
1年の後輩が勉強会中にVirtualBoxで同じことをやらかしていたのを思い出し、macアドレスが被っただけかなぁと判断しました。
Q7(1日目午後) 自動マウントをしてくれない!
/etc/security/pam_mount.conf.xml
ファイルを見てみたら普通にRead-Onlyの設定になっていました。
他にトラブルになりそうなものだと /etc/skel/private
ファイルが作成されていました。
ディレクトリに作成し直そうとしたのですが、root権限で消せなかったので lsattr したところ、案の定「i」フラグが設定されていたので chattr でフラクを削除、ファイルをディレクトリに作成し直しました。
あとは pam_mount.conf.xml
内の mountpoint
を修正しました。
mountpoint="home" ↓ mountpoint="/home"
その後 test01〜test05 ユーザを作成し、privateディレクトリがちゃんと配布されていることと、自動マウントが正常に出来ていることを確認しました。
解答文は長いので原文は載せませんが、
- /etc/skel/ディレクトリにprivateディレクトリを作成
/etc/skel/private
ファイルをchattr -i
して削除したあと、privateディレクトリを作成した。
- ユーザを作成
- pam_mount.conf.xmlの編集
- ファイルが作成できるか確認テスト
をやったことをコマンド付きで解答に書いて送りました
Q9(2日目午前) レプリケーションが出来ない!
一瞬NoSQLを期待しましたが普通にMySQLでした。(そろそろNoSQL系の問題が出てもいい気がする
$ show slave status\G
コマンドから得た情報と、MySQLのエラーログから原因を突き止めていきました。
MySQLのログとか
接続先が無いと怒ってるっぽい
# MySQLのログファイル 160828 7:40:50 [ERROR] Slave I/O: error connecting to master 'repl@192.168.5.5:3306' - retry-time: 60 retries: 86400, Error_code: 2013 # show slave status\G の結果 error connecting to master 'repl@192.168.5.5:3306' - retry-time: 60 retries: 86400
レプリケーションの設定情報
なんかmasterのIPが間違ってる
mysql> show slave status\G *************************** 1. row *************************** Slave_IO_State: Connecting to master Master_Host: 192.168.5.5 ← !!! masterのIPが間違ってる !!! Master_User: repl Master_Port: 3306
masterのIP修正
mysql> STOP SLAVE; mysql> change master to MASTER_HOST='192.168.11.3'; mysql> start slave;
記憶が正しければこの時点でiptablesの tcp/3306 が空いていないことに気づいて開けたはずです。
MySQLのエラーログを確認する。
まだどこかが間違っているみたい
160828 11:19:14 [ERROR] Slave I/O: error connecting to master 'repl@192.168.11.3:3306' - retry-time: 60 retries: 86400, Error_code: 1130
ユーザ情報を確認してみたらreplユーザのHostの設定が間違ってました。
$ mysql -u root --password=password -e "select Host, User, Password from mysql.user;" +--------------------+------+-------------------------------------------+ | Host | User | Password | +--------------------+------+-------------------------------------------+ | localhost | root | *139..................................... | | problem11-template | root | *139..................................... | | 127.0.0.1 | root | *139..................................... | | 192.168.5.% | repl | *22F..................................... | +--------------------+------+-------------------------------------------+
replユーザの設定を修正
mysql> rename user 'repl'@'192.168.5.%' to 'repl'@'192.168.11.%';
この後MySQLのログかなんかで server-id が被っていると怒られたので修正しときました。
server-id=100 この行を以下のように変更 server-id=101
とりあえず分かった原因は
- tcp/3306 が空いていない
- slaveのMySQLの設定で、指定されたmasterのIPアドレスが間違っている
- master側のMySQLのユーザ設定で、replユーザのログイン可能Hostが「192.168.5.%」(正しくは192.168.11.%)と誤った設定がされている
- masterとslaveでserver-idが被っていたため、slaveが止まってしまう
解決方法
- master側のiptablesで tcp/3306 を開ける
- slaveのMySQLの設定で、masterのIPを正しく変更する
- masterのMySQLで、replユーザの設定を正しく変更する
- slaveのserver-idを変更する
- 一度DBを削除し、レプリケーションし直した
これに叩いたコマンドの詳細を添付してレプリケーションが出来ることを確認したと運営に報告しました。
他の問題(自分が触ってないやつで覚えているもの)
前回運営がIP電話でトラブっていたので今回SIPが出そう!と予想して対策してましたがダメでした...
IPv6問題は対策でv6のルーティングプロトコルや相互運用について調べたり構築したりしていて、指定された機材にNAT64の機能が無いことを知っていたので騙されずに済みました。
ここら辺の話はきっと後輩が書いてくれるはず
ArchLinux上で運用していたRedmineをDockerコンテナに移行したときのメモ
移行するにあたっての経緯
RedmineをArchLinux上で運用していたのですが、Redmine絡みのパッケージをアップデートするたびに問題が発生して運用が辛かった
やっぱ時代はDockerでしょ(適当
と言うことでdockerに移行しました。
その時の作業内容を残しておこうと思います。
そういえば...全く更新していなかったのですがRedmineって今バージョン3.2.0なんですね(アップデートほったらかしにしてた)
(RubyやOpenSSLを最新のパッケージにアップデートすると動作しなくなってたのこいつのせいなんじゃ...)
まずRedmineを最新バージョンに上げ、動作確認してからDockerに移行しました。
(せっかくArchLinuxで運用していたんだし、素直にaur/redmineのパッケージ使っておけばアップデート楽だったなと今更後悔)
ちなみにDockerに移行するとこの前やったowncloudとかの連携が全部出来なくなりますが、正直使ってなかったので無かったことにします。
現在のRedmineの環境
- ArchLinux
- Apache: 2.4.18-2
- Redmine: 3.0.3
- postgresql: 9.5.1-2
Dockerへ移行する前にRedmineのアップデート
Dockerに移行する前に、Redmineを最新バージョンに上げて動作確認したので一応手順を残しておこうと思います。
Redmineの公式ドキュメントを参考にアップデートしました。
バックアップ
まずPostgresqlをまるごとバックアップします。
身内用なので問答無用で落として物理&オフラインバックアップしました。(Postgres止めてディレクトリごとコピー)
その後Redmineもディレクトリごとコピーしてバックアップしておきました。
$ sudo systemctl stop httpd.service $ sudo systemctl stop postgresql.service $ sudo cp -a /srv/redmine-3.0.3 /srv/redmine-3.0.3- $ sudo cp -a /var/lib/postgres/data /var/lib/postgres/data-
新しいバージョンのRedmineと入れ替える
では早速アップデートします。
Redmineの公式から最新バージョンのtarファイルを落として展開
$ wget http://www.redmine.org/releases/redmine-3.2.0.tar.gz $ sudo tar fvxz redmine-3.2.0.tar.gz -C /srv/
設定ファイルやその他のファイルの移動
各設定ファイルを新しいconfigディレクトリにコピー
$ sudo cp redmine-3.0.3/config/database.yml redmine-3.2.0/config/database.yml $ sudo cp redmine-3.0.3/config/configuration.yml redmine-3.2.0/config/configuration.yml
filesディレクトリを新しいRedmineにコピー
$ sudo cp -r redmine-3.0.3/files/* redmine-3.2.0/files/
pluginsディレクトリを新しいRedmineにコピー
$ sudo cp -r redmine-3.0.3/plugins/* redmine-3.2.0/plugins/
gemとかbundleとか(rubyワカラナイ
Redmineの実行に必要なgemをインストール
$ cd redmine-3.2.0/ $ bundle install --without development test $ bundle exec rake generate_secret_token
パーミッションの設定
$ sudo chown root:root redmine-3.2.0/ -R $ cd redmine-3.2.0 $ sudo chown -R http:http files log tmp public/plugin_assets $ sudo chmod -R 755 files log tmp public/plugin_assets
データベースの更新
$ sudo systemctl start postgresql.service $ sudo bundle exec rake db:migrate RAILS_ENV=production $ sudo bundle exec rake redmine:plugins:migrate RAILS_ENV=production
クリーンナップ
$ sudo bundle exec rake tmp:cache:clear tmp:sessions:clear
Apacheの設定
#新しいRedmineのディレクトリに変更する DocumentRoot "/srv/redmine-3.2.0/public"
トラブルシュート
エラーその1
There was an error parsing `Gemfile`: Permission denied @ rb_sysopen - /srv/redmine-3.2.0/config/database.yml. Bundler cannot continue.
https://wiki.blue-it.org/Redmine#Website_won.27t_come_up
ここを参考にしました
config/database.ymlのパーミッションを修正
$ sudo chmod 644 config/database.yml
エラーその2
App 8703 stderr: Rails Error: Unable to access log file. Please ensure that /srv/redmine-3.2.0/log/production.log exists and is writable (ie, make it writable for user and group: chmod 0664 /srv/redmine-3.2.0/log/production.log). The log level has been raised to WARN and the output directed to STDERR until the problem is fixed.
production.logのパーミッションを修正。
他にもあるかもしれないので以下をもう一度実行しておきました。
$ sudo chown -R http:http files log tmp public/plugin_assets $ sudo chmod -R 755 files log tmp public/plugin_assets
新機能の追加
管理 -> ロールと権限
ここで新しく追加された機能を有効にしておきます。
動作確認
redmineにアクセスしてちゃんと動作するか確認します。
Dockerコンテナにマイグレーション
と、言うことでアップデートと動作確認が終了しました。
これをDockerコンテナ(別サーバ)に移行します。
今回本番環境はdocker-composeを使います。
kubernetesとかで管理出来たらいいのですが今回は時間が無いのでそのうちやります(たぶん
本番環境にマイグレーションする前に、ローカルのdockerで移行手順や動作確認などのテストをしたのですがそこは割愛します。
ということで、以下の方法でマイグレーションしました。
- redmineサーバからDBとfilesをコピーしてくる
- docker-composeの用意
- DBのマイグレーション
- filesディレクトリのマイグレーション
移行先の環境と使用するdockerイメージ
環境
- ArchLinux
- docker:1.10.3
- docker-compose:1.6.2
使用するdockerイメージ(全部オフィシャル
- redmine:latest
- postgres:9.5
- busybox:latest
移行先のdockerサーバは、別コンテナで複数のwebサービスが動いているのでそれらをリバースプロキシ(dmp1ce/nginx-proxy-letsencrypt
)で振り分けています。
1. redmineサーバからDBとfilesをコピーしてくる
Redmineサーバで以下のコマンドを使用してDBデータとfiles内をdockerサーバにコピーします。
redmine_server$ sudo -u postgres pg_dumpall -c > pg_redmine.dump redmine_server$ cd /srv/redmine-3.2.0/ redmine_server$ tar fvcz ~/redmine_files.tar.gz files # (私は一度ローカルに持ってきてから移行先サーバにコピーしました) redmine_server$ scp pg_redmine.dump redmine_files.tar.gz docker-server:distination
2. docker-composeの用意
ディレクトリ構成
redmine-compose ├── containers │ ├── postgres-datastore │ │ └── Dockerfile │ └── redmine-files-datastore │ └── Dockerfile └── docker-compose.yml
containers/redmine-files-datastore/Dockerfile
FROM busybox VOLUME /usr/src/redmine/files CMD tail -f /dev/null
containers/postgres-datastore/Dockerfile
FROM busybox VOLUME /var/lib/postgresql/data CMD tail -f /dev/null
docker-compose.yml
postgres-datastore: build: containers/postgres-datastore redmine-files-datastore: build: containers/redmine-files-datastore some-postgres: image: postgres:9.5 volumes_from: - postgres-datastore environment: POSTGRES_PASSWORD: PASSWORD POSTGRES_USER: redmine some-redmine: image: redmine volumes_from: - redmine-files-datastore links: - some-postgres:postgres environment: VIRTUAL_HOST: redmine.example.org VIRTUAL_PORT: 3000 LETSENCRYPT_HOST: redmine.example.org LETSENCRYPT_EMAIL: example@example.org
some-redmineのenvironmentは、リバースプロキシにdmp1ce/nginx-proxy-letsencrypt
を使用しているのでそっちで使用する環境変数です。
一応そのプロキシのdocker-composeを載せておきます。
#nginx-proxy-compose/containers/certs-datastore/Dockerfile FROM busybox VOLUME /etc/nginx/certs/ CMD tail -f /dev/null #nginx-proxy-compose/docker-compose.yml certs-datastore: build: containers/certs-datastore some-proxy: image: dmp1ce/nginx-proxy-letsencrypt:latest ports: - "80:80" - "443:443" volumes_from: - certs-datastore volumes: - /var/run/docker.sock:/tmp/docker.sock:ro environment: DEFAULT_HOST: example.org
3. DBのマイグレーション
まずpostgresとpostgresのデータ用コンテナのみを建ち上げます。
docker_server$ docker-compose up -d postgres-datastore some-postgres
postgresコンテナにredmineデータベースのリストアをします。
docker_server$ cat pg_redmine.dump | docker exec -i redminecompose_some-postgres psql -U postgres
postgresのRedmineロールのパスワードを設定しなおします。
(Dockerに移行する際にRedmineロールのパスワードを変更していなければやらなくて大丈夫)
# docker exec -i -t redminecompose_some-postgres psql -U redmine postgres=# \password postgres=# \q
4. filesディレクトリのマイグレーション
残りのコンテナの建ち上げます。
# docker-compose up -d
redmineのfilesディレクトリをdocker側に移行
# docker run -i -t --rm \ --volumes-from=redminecompose_redmine-files-datastore_1 \ -v /path/to/redmine_file.tar.gz:/tmp/redmine_file.tar.gz \ busybox sh # tar fvxz redmine_files.tar.gz -C /usr/src/redmine/ (tarの仕方によっては/usr/src/redmine/files)
しばらく動かしてみて問題なかったので上手くdockerに移行できたみたいです。
メールの設定は必要になった時に行う予定です。
これからはRedmineの新しいバージョンがリリースされてもRedmineのコンテナだけを入れ替えれば済むので管理が楽になりそうです。
やっぱDocker良いですね
参考サイト
user_sqlを使ってownCloudとRedmineを連携してみた
user_sqlというownCloudのプラギンを使うと、RedmineのアカウントでownCloudにログイン出来るように連携できるらしい
ということで試してみた。
2015/12/12 追記
- Redmine側でログインIDに大文字が入っていると、user_sqlで連携しているユーザがowncloudでログイン出来ない問題ですが、原因が分かりました。
- user_sql.phpの137行目、355行目に
strtolower($uid)
があるのですが、これのstrtolower($uid)
のstrtolower
を消して$uid
だけにするとログイン出来るようになります。 - ただ
strtolower
を外すことによってどんな問題が発生するかはまだ分かりません。 - とりあえず今のところは問題なく使えています。
2015/08/30 追記
- この方法でユーザの連携を行うと、一部のユーザがログイン出来ないことがわかった。原因はRedmine側のログインIDに大文字アルファベットが入っているとownCloudにログイン出来ないみたい。
- ownCloud側でユーザを確認するとログインIDがすべて小文字に変換されていて、その小文字に変換されているIDを使用してもログインすることは出来なかった。
- 一応Redmine側のログインIDをすべて小文字アルファベットで登録すれば連携に関しては問題ないと思う。 対策を考え中...
パッケージのダウンロードと展開
https://apps.owncloud.com/content/show.php/user_sql?content=155512
ここからuser_sqlをダウンロード
展開してコピー
$ sudo -u http tar fvxz user_sql-388830cefba7.tar.gz -C /usr/share/webapps/owncloud/apps/ $ sudo -u http mv /usr/share/webapps/owncloud/apps/user_sql-388830cefba7 /usr/share/webapps/owncloud/apps/user_sql
/usr/share/webapps/owncloud/appsディレクトリにぶっこむだけ
後はowncloudが勝手に認識してくれるわーい
ownCloudでの設定
左上のプルダウンから「アプリ」を選択
無効のタブの下の方に「SQL user backend」があるので有効に。
なかったらApacheを再起動すると出てくるかも
有効にしたら右上のプルダウンから「管理」
設定項目に「SQL」というのが追加されてるはず。
後は設定項目を入力していく。
分からないところはpsqlでRedmineのテーブルを見てそれっぽいのを選択
Connection settings SQL Driver : PostgreSQL Host : localhost Username : redmine Database : redmine Password : my_password
Advanced Settings Table : users Username Column : login Password Column : hashed_password Real Name Column : firstname Encryption Type : Redmine
とりあえずこれだけ設定すればRedmineのアカウントでログイン出来た。
注意点
/usr/share/webapps/owncloud/apps
にぶっこむディレクトリ名は、user_sql/appinfo/info.xml
の
<id>user_sql</id>
と同じにしなければownCloud側で認識はするけどアプリを有効にしようとすると No app name specified
って怒られる
http://stackoverflow.com/questions/21700112/no-app-name-specified-in-owncloud
ちなみにinfo.xmlファイルの
<name>SQL user backend</name>
がownCloudのappsに表示されるアプリ名
最初これを知らずにuser_sqlが無い無いと探しまわってしまった
参考 公式ドキュメント
yaml_dbを使ってMySQLからPostgreSQLにRedmineを移行した
MySQLからPostgreSQLに移行したのでその時のメモ
移行ツール
yaml_dbを使用する
適当にググっているといくつかのサイトで、本家?のyaml_dbは4.x系のRailsに対応していないという記事がいくつかあったのだが、
https://github.com/yamldb/yaml_db
https://rubygems.org/gems/yaml_db
githubとここを見る限り4.x系も対応したみたいなのでそのまま本家のyaml_dbを使うことにする。
Postgresqlに新しいDBを作成
ここを参考に作成
http://www.redmine.org/projects/redmine/wiki/RedmineInstall#PostgreSQL
$ sudo -upostgres psql
psql$ CREATE ROLE redmine LOGIN ENCRYPTED PASSWORD 'my_password' NOINHERIT VALID UNTIL 'infinity'; psql$ CREATE DATABASE redmine WITH ENCODING='UTF8' OWNER=redmine;
config/database.ymlの編集
production: adapter: postgresql database: redmine host: localhost username: redmine password: "my_password" encoding: utf8
こんな感じで変更
これを先にやらずにbundleするとpostgresqlのgemが入らなかった
yaml_dbとgemのインストール&アップデート
yaml_dbをGemfileに追加
/srv/redmine/Gemfile の、gemが並んでいる場所に「gem "yaml_db"」を追加する
$ sudo vim /srv/redmine-3.0.3/Gemfile
それっぽい場所に
gem "yaml_db"
を追加
gemのインストールとアップデート
$ sudo bundle update $ sudo bundle install --without development test sqlite
前回インストールした時は
$ bundle install --without development test postgresql sqlite
ってやったけど、今回はpostgresqlのアダプタをインストールするためpostgresqlを含めない
データのダンプ
$ cd /srv/redmine-3.0.3 $ sudo RAILS_ENV=production bundle exec rake db:data:dump
これでdb/data.ymlにdata.ymlファイルが作成される
マイグレーションしてデータの書き込み
sudo RAILS_ENV=production bundle exec rake db:migrate sudo RAILS_ENV=production bundle exec rake db:data:load
後はApacheを起動してちゃんと移行できているか確認して終了。
今のとこちゃんと動いてるので上手く移行できたみたい。