‫次は､ SSL証明書cをどのように扱えばよいのでしょうか｡
‫Santiagoさんのコメント： エンジンXとローカル環境のSSL証明書をどう扱えばいいのか｡
‫HTPのためのプロッドを行う開発環境は､ そうですね｡
‫ローカルで開発する場合は､ 独自の証明書を作成する必要があります｡
‫Composeファイルの中でengine
‫Xやtrafficなどを使用すると､ URLやアプリへのパーケルが正しく表示されます｡ Let's Encryptを調べると､ ローカルホスト用の証明書に関する良い記事があります｡
‫同じ証明書を常に使用する場合（私はそうしています）､ プロジェクトの外のローカルマシンのどこかに証明書を保存し､
‫ブラウザにそれを信頼するように指示することができます｡
‫だから､ 証明書と一致する名前を使っているのなら
‫ローカルマシンでlocal hostという名前の証明書を作成し､ それをプロキシ用のcomposeファイルで使用し､
‫ブラウザにその証明書を信用するように指示した場合｡
‫そうすれば､ 常に動作する優れたローカル・デプロイメント環境を手に入れることができるのです｡
‫警告が出ることもなく､ ブラウザも信頼してくれるので､ 必ずしもサードパーティの証明書を取得する必要はありません（ローカルマシンでは使えないから）｡
‫この証明書はローカルマシン用に設計されたものではありませんし､
‫簡単に共有できるものではありません｡
‫だから､ 私にとってはSS本部のようなものなんです｡
‫ローカルマシンに置いておくだけでいいんです｡
‫ドットSSHフォルダに保存したり､ ローカルマシンのプロファイルにドット証明書というものを作成し､
‫そこに嵐を起こし､ composeファイルにリンクすることで､ プロキシやローカルでSSLを使いたいウェブサーバで必要なときに常に持っていることができるかもしれないのです｡
‫もちろん､ プロダクションでは全く別物です｡
‫例えばDocker swarmの場合､ 私はLet's Encryptとtrafficを使うのが好きです｡
‫trafficはフロントエンドプロキシで､ engine Xのような働きをします｡
‫それも､ ここで投げかけておきます｡
‫このレポには､ Let's Encryptでトラフィックプロキシーを使用する方法の例があり､ 自動的に証明書を取得しに行き､ それを戻すことができるようになっています｡
‫今､ 私たちが伝統的に行ってきたように､ 自分で証明書を買いに行きたい場合｡
‫それもいい｡
‫キューバンの渦潮を利用して､ ストームやシークレットを使い､ 必要なコンテナに使えるようにするのです｡
‫お役に立てれば幸いです｡
‫そして､ いい質問ですね｡