エンジン福岡の物流系エンジニアの雑記ブログ。英語の学習法を試行錯誤中。2023.01.03開発が一旦完了し、保守やメンテナンスのフェーズに入ったアプリケーションの仕事をしていて、こんな事を思った。理由としては、サービスが稼働した後、本番環境のデータをローカル環境に落として実験しやすいようにするため。本番稼働後にエラー報告があって調査するも、ローカル環境では再現できず、その内容が特定の条件が揃った時にしか発生しない可能性が高い場合、本番環境と同内容のデータを用意して実験したい場合も多いと思う。そんな時、本番環境のデータをエクスポートするなり、定期エクスポートしているファイルをローカルにインポートする事になる。このインポート作業は意外と面倒な事になるケースがある。等、個人の好きなOSを使ってもらう事も多いと思う。筆頭とした仮想化技術が、それを容易に実現できている。コンテナ)で実行する時、インポート対象ファイルをコンテナ内部から参照できる場所に保存しておく必要がある。(もしかしたらホスト側のファイルを指定する方法があるかもしれないけど、見つけることができませんでした)その場合、ホストとコンテナの間にファイル交換プロトコルを用意したり、双方で参照できるストレージを仲介してファイルを受け渡したりする方法が考えられるが、正直面倒くさい。他には、インポートコマンドをホスト側から実行する方法があるが、この場合はホスト側のシェルの都合に振り回される事になる。インポートコマンド実行に必要な「<」の文字が予約語のために使用不可のため迂回路を探すハメになったりと、何かと余計な調査を強いられる。(ちなみにその問題を解決しても、ファイルはコンテナ内部から参照できる場所に保持しておく必要があったりと、結局無駄に時間を溶かしただけだった。アプリケーションを使用するという方法だが、OSごとに使えるアプリケーションに違いがあるし、同じアプリケーションでも操作方法やできる事に差があったりと、チーム内で共有する情報としては、ちょっと重たい内容となる。ごとに異なる操作方法が必要になってしまうというのはいかがなものか。その点でも、OSごとに個別の方法を用意するのが適切とは思えない。ちなみにインポートが成功する状態まで持って行ったとしても、今度は文字コードによるエラーに悩まされたりと、何かと障害が多い。ちなみに、この辺の調査内容をまとめたエントリがこちらです。dumpファイルをインポートする方法これらの問題を綺麗に解決してくれる方法が、冒頭で紹介した「データベースのコンテナとホスト間に共有フォルダを設定しておく」という方法。「DBコンテナとホスト間の共有フォルダにファイルを置いて、コンテナ内部からインポートコマンドを実行してね」これだけの説明で完結する。シェルの違いにも、ホストOSの都合にも一切引っ張られる事がない、最適な解決方法だと思うのだが、どうだろう。編集しようとも、影響があるのはローカルの開発環境のみで、本番環境やステージング環境には一切悪影響を及ぼさずに解決できる。上記のような設定を入れると、「これはなんのための設定なの?」と突っ込まれる事必死なので、その有益性とその設定を入れない場合の課題を説明したいと思ってブログにておく事にした。コンテナにログインした時の、デフォルトユーザを設定する。ユーザでのログインになる事があるかと思います。コンテナにログインした時のデフォルトユーザを設定可能です。停止し、『問題が起きたためコンピュータを再起動しました。このまま起動する場合は、いずれかのキーを押すか、数秒間そのままお待ちください。』という現象が頻発するようになったので、調査してもらった。前ぶりもなしに不吉なエラーメッセージを吐き出して停止する現象が発生し始めました。発生頻度は、大体1日1回。エラーメッセージはこんな感じ。部分的に導入すると、あとで後悔するほどカオスになりがちなのでは?タイトルそのまんま。キメラ生物となってしまったシステムの仕事をしていて、そう思ってしまった。開発する場合、タイムゾーンを色々な場所に設定する事ができます。コメントをキャンセルメールアドレスが公開されることはありません。*サイト次回のコメントで使用するためブラウザーに自分の名前、メールアドレス、サイトを保存する。上に表示された文字を入力してください。フリーでやってるエンジニア。