entrypoint.sh内にスペースインデントが入ってしまう問題の対応と可読性の向上 #105
Conversation
|
コンテナ内のコマンドを一般ユーザで実行することは、 gosuは、コンテナの起動時にrootユーザで初期化処理（ldconfigの実行）をし、HTTPサーバを動作させるpython3コマンドは一般ユーザで実行する、ために導入しました。ENTRYPOINTをrootユーザで実行し、CMDを一般ユーザで実行するという形になっています（デバッグの都合で このPRでは、ldconfigの実行をDockerイメージのレイヤーにしているため、gosuが不要になっています。 個人的には、USER命令を使わず、RUN命令の中のコマンドがすべてrootユーザで実行されるという想定をもっていた方が、Dockerfileが読みやすく、書きやすくなると思っています（差分表示、処理順の自由度において）。 ちなみに、マルチステージビルドでは、USER命令の実行はレイヤーとして引き継がれます。 いまのところ、 #96 では、ホストからマウントされたディレクトリの所有者を書き換えるchownコマンドをentrypointで実行するためにgosuを使っています。 とりあえず事例を調べたところ、mysqlの公式イメージでgosuが使われているようでした。 |
|
@aoirint なるほど、詳細をありがとうございます！ 論点は「 使い回す設計なら、次のステージ？に影響が及ぶUSERの使用は控えてgosuを利用すべきだと思います。 個人的には、前者は後者を兼ねているというのもあって、gosuを使用する方が良いのかなと思いました。 |
Dockerfile
Outdated
| cat <<- EOT > /entrypoint.sh | ||
| #!/bin/bash | ||
| cat /opt/voicevox_core/README.txt > /dev/stderr | ||
| exec "\$@" | ||
| EOT | ||
| chmod +x /entrypoint.sh |
There was a problem hiding this comment.
別件なのですが、tabとspaceが混じっているとちょっと読みづらいかもしれません。
コーディング規約に入っておらず申し訳ないのですが、<<でお願いします！
|
@aoirintさんがgosuを採用したのは
が大きな理由かと読み取りました ちょっと理解が浅くて申し訳ないのですが2点確認したいのは コンテナブレイクアウトに関しては外部公開されているコンテナに関して意識するものと思っていましたがHTTP開いているので意識する必要があるということでしょうか？ ldconfigはコンテナビルド時に実行してしまえばもう不要かと思うのですがentrypoint.sh内で実行していたのは何か別の理由があったのでしょうか？ 次に@Hiroshibaさんの インデントにタブとスペースが混じると可読性が悪いという問題に対してですが ヒアドキュメントでスペースインデントを採用してファイルを作成すると作成されたファイル内にそのままスペースインデントまで残ってしまう ということで現状私が理解した範囲で意見をまとめたものをコミットしてみました タイトルとは違って |
Dockerfile
Outdated
| # if all tries are failed, `docker build` will be failed. | ||
|
|
||
| # Download openjtalk dictionary | ||
| parallel --retries 5 --delay 5 --ungroup <<- EOT |
はい、そのように考えています（あくまでセキュリティ素人の考えです）。 細工したHTTPリクエストにより、実装やライブラリの脆弱性を利用して、 通常では隔離されたコンテナの外に出ることはできませんが、 このとき、HTTPポートを開くプロセス（または脆弱性の影響を受けるプロセス）を そこで、メインのプロセス（python3 run.py）を一般ユーザで実行することで、上記の流れによる、ホスト側のroot権限獲得を予防しようとしています。 もっと本格的に対策するならば、コンテナ内一般ユーザのUID・GIDをランダムに設定する（ホスト側で権限を持つUID・GIDを使用しない）ということも考えられると思います（同じ流れにより、ホスト側の一般ユーザとしては、振る舞える可能性があるため）。 ちなみに、サンプルの実行コマンドでは、カジュアルに実行する可能性があるため、 規約的にも、例えばWebアプリケーションに組み込むという用途で、パブリックなWeb APIとして公開することも可能だと考えています（直接的には、計算資源を提供するメリットがありませんが）。 インターネットに公開されたWebアプリケーションから、プライベートネットワークのAPIにアクセスすることも仕様上可能だと考えています（これはブラウザ上で動作するWebアプリケーションからのアクセスならば、CORSを適切に設定すれば制御できるように思いますが）。
わたしも不要だなと思っていました。可能ならそのようにする方がよいと思っています。それから、/etc/ld.so.cacheの削除も実際には不要だと思います。 しかし、ldconfigをコンテナ実行時に実行している経緯はあるので、以下で説明します。
はい、 #88 の開発中に正確な原因がわかっていない問題が発生したため、念のためにentrypointでldconfigを実行している形になります。 しかし、原因が分かっていないため、entrypoint.sh内で実行しなければならない、という明確な根拠はありません。 経緯としては、 #88 の開発中に、
この現象は、entrypointでのldconfig実行の挿入で解決しましたが、検証の方法に明るくないため、正確な原因の調査をしていません。 ローカルDockerイメージキャッシュを使う限りにおいて、ローカル環境で再現していますが、キャッシュを破棄した場合に再現するかは確認していません。 当初LibTorchの いまのところ、Dockerのイメージキャッシュが影響している可能性を考えています。 あまり明るくないので憶測なのですが、ldconfigがバックグラウンドプロセスを起動していて、その実行が終わる前にldconfigが制御を返してRUN命令の実行が終わり、バックグラウンドプロセスが強制終了され、ldconfigのキャッシュが一部しか書き込まれていないという可能性も考えています。 他に、RUN命令内の処理に失敗したがRUN命令自体は成功した扱いとなった可能性を考えています。
|
|
@aoirintさん
なるほどゆくゆくは外部公開する前提で作成されていたのですね
これは恐らく COPY --from=download-libtorch-env /etc/ld.so.conf.d/libtorch.confより前にldconfigしているのが原因じゃないでしょうかこのファイルがない状態でldconfigしたので
了解です！
前回もこんなミスしてしまいましたね ここは<<だとEOTのインデント位置が見苦しくなってしまいますので\での改行に変更させていただきました 恐らくこれで問題ないかと思いますのでご確認をお願いします |
ありがとうございます！
どうなんでしょう..。以下は問題が起きたコミット de20f62 の記述なのですが、その点については問題がないように見えるんですよね.. 再発しないかがちょっと心配ではありますが、おそらくわたしの環境の一時的な問題で、問題ないと思います！ （どこかではっきりと原因がわかるといいのですが..） ちなみに、以下のような記述は、download-libcoreやdownload-libtorchを単体でイメージ化した場合に、それぞれの共有ライブラリを参照できるように、という意図で記述しています（が、需要はほぼないと思うので、冗長になるldconfig用のentrypointまでは作成しませんでした）。 |
masterをマージしてから再度修正した際にforceでpushしたため
再OPEN出来ませんでした
https://github.com/Hiroshiba/voicevox_engine/pull/102
上記PRの続きとなりややこしくなってしまい申し訳ありません
ご査収のほど宜しくおねがいします
ヒアドキュメント内のインデントに関しては
<<EOT
ではなく
<<- EOT
にすることでタブインデントが可能となりますのでそちらの方に変更させていただきました
コーディング規約的にタブインデントが禁止されているようであれば再度対応したいと思います