問題タブ [isapi-wsgi]

For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.

0 投票する
3 に答える
4953 参照

python - Windows用のdjangoアプリケーションをどのように展開しますか?

isapi_wsgidjango-pyodbcを使用して Web アプリケーションに取り組んでいます。すべての依存関係をインストールして、ファイルを Web サーバーにプッシュする方法が必要です。残念ながら、これらのいくつかは、言うは易く行うは難しです。特に、一部の依存関係は setuptools の下でも正しくインストールされないため、依存関係の処理は面倒です (pywin32 は特に困難です)。

この種のものを自動化するために私が目にするほとんどのツール ( fabriccapistrano ) は、unix-y システムで使用するために作られています。継続的インテグレーション システムをセットアップしたいのですが、それでは問題の一部しか解決できません。Windows/IIS の使用を余儀なくされている Pythonista の生活を楽にする方法はありますか?

0 投票する
1 に答える
1799 参照

python - IISおよびISAPI-WSGI=非常に遅い

isapi-wsgiを使用してIISに2つのDjangoアプリをロードしました。


これらは両方ともサーバー設定です。

  • Windows Server 2003、IIS6、およびSQL Server 2005

  • Windows Server 2008 R2、IIS7.5、およびSQL Server 2008

Djangoアプリは完全に異なります。


どちらも、リクエストごとに1〜10秒のランダムな期間を要します。

これは、Apache + mod_wsgiセットアップの100ms〜500msに比べて非常に遅いため、何か問題があるはずです。


何か案は?私がこれを修正できれば本当に素晴らしいでしょう。:)


解決しました!

django-mssqlを使用しないでください。代わりにdjango-pyodbcを使用してください。

0 投票する
3 に答える
45832 参照

python - IISにFlaskアプリケーションを展開するにはどうすればよいですか?

誰かがIIS6でFlaskアプリケーションを実行するのを手伝ってもらえますか?isapi-wsgiを使用しようとしましたが、仮想ディレクトリアドレスにアクセスすると、「指定されたモジュールが見つかりませんでした」というページが表示されます。これには他のオプションがありますか?

以下は、isapi-wsgi用に作成したPythonスクリプトです。仮想ディレクトリが作成され、IISマネージャーですべてが正常に見えましたが、サイトは機能しませんでした。

0 投票する
2 に答える
3736 参照

python - IIS for Python2.7にisapi_wsgiを正しくインストールする方法は?

私はWindows7のIISにCGIアプリケーションとしてPythonをインストールする作業を行いました。これは非常に簡単ですが、柔軟性を高めるためにWSGIのものを使用したいと思います。

isapi_wsgiのアーカイブをダウンロードし、解凍してから、次のように手順に従ってインストールを実行しました。

これは成功しました:

ここに画像の説明を入力してください

次に、wsgi接着剤が含まれている.pyモジュールをコーディングし、インストールしてみました。これは次のように失敗しました:

ここに画像の説明を入力してください

これはCOMMonikerエラーであり、IIS6互換の管理機能はCOM Monikersに基づいていることを知っています。これにより、IIS6互換の管理機能のisapi_wsgiに前提条件があることを思い出しました。それを実行\windows\system32\OptionalFeatures.exeしてインストールしてから、.pyモジュールを再実行すると、正しくインストールされました。

わかりました、素晴らしいです。現在のディレクトリを見ると、_app1_wsgi.dllという名前の新しいDLLが表示され、IIS Managerを見ると、新しいIIS vdirと、そのvdir内の「*」のスクリプトマップが表示されます。 _app1_wsgi.DLL。すべて良い。だが!をリクエストするとhttp://localhost/wsgi、500エラーが発生します。

試行錯誤の結果、ハンドラーを定義する.pyモジュールはsite-packagesディレクトリにある必要があることがわかりました。私はこれに非常に驚いています。

これを回避できますか?生成された.dllファイルと同じディレクトリに.pyモジュールを配置するだけでいいですか?または、WSGIメカニズムから実行するために、すべてのPythonロジックをサイトパッケージにデプロイする必要がありますか?

0 投票する
1 に答える
634 参照

python - pythonisapi-wsgiモジュールをiis7.5Webサブアプリケーションに割り当てる

isapi-wsgiモジュールを使用してPythonWebサイトを実行するIIS7.5Webサーバーがあります。Webサイトはポート80にバインドされているので、PythonWebサイトをこのWebサイトに追加されたアプリケーションで実行したいと思います。

対応するisapiモジュールを生成するコードは次のようになります

残念ながら、モジュールは対応するdllを登録できず、エラーが発生します

アプリケーション「dsh」をWebサイトに追加しましたが。'Website/dsh'のようなものも機能しません。

誰かが同じ問題に遭遇し、その解決策を持っていますか?

0 投票する
2 に答える
1773 参照

iis - アプリケーション プール ID としてのアプリケーション プールのリサイクル

サーバー上にある中央の git リポジトリへのプッシュが、Windows Server 2012 上の IIS 8 を介して実行されているサイト フォルダーに変更を自動的にプッシュするセットアップを作成しています。

これは簡単です。以下は機能しています。IIS上で独自に実行されているサイトであるBonobo Git Serverがあります。Bonobo によって管理されている中央リポジトリに post-receive フックがあります。次に、このフックは、変更をサイトのフォルダーのリポジトリにプルするバッチ ファイルを実行します。これが可能になったのは、当然のことながら、受信後フックが Bonobo のアプリ プール、つまり「IIS AppPool\GitServerAppPool」に割り当てられた ID として実行され、その ID にサイトのフォルダーに対する変更権限を与えたためです。

したがって、コードはうまくプッシュおよびプルされます。問題は、プロジェクトが Python でコーディングされており、ISAPI_WSGI を使用して IIS に統合されているため、アプリケーション プールをリサイクルせずにコードをリロードするメカニズムがないことです。

受信後スクリプトにアプリケーション プールをリサイクルする権限を与えることは困難であることがわかっています。

というわけで、問題はこれです。-受信後スクリプトは「IIS AppPool\GitServerAppPool」として実行されているため、管理者アカウントが必要なため、他のアプリ プールを再起動できません。- appcmd またはスケジュールされたタスクを実行するための RunAs の使用は、UAC を渡すためにパスワードの入力が必要になるため、機能しません。- 最初にパスワードを入力するために AppPoolIdentity としてログインできないため、runas で /savecreds を使用しても機能しません。

そして、私は立ち往生しています。次のいずれかが何らかの形で可能な場合、それらは機能するはずですが、それらを実行する方法が見つかりません.

  1. アプリ プールをリサイクルするために必要なアクセス許可を下げる何らかの方法。
  2. runas コマンドにパスワードを含める何らかの方法 (スクリプトは外部からアクセスできないため、これで問題ありません)
  3. コマンドを GitServerAppPool として手動で実行して、/savecreds を使用してバッチ ファイルを 1 回実行し、パスワードを再度入力する必要がないようにする方法

a、b、またはcの方法を知っている人、または別の解決策がある人はいますか?

機能する解決策の 1 つは、管理者アカウントとして実行されているアプリ プールで git サーバーを実行することです。ただし、IIS セキュリティに関する 1 つのルールを回避するために完全な管理者アクセス権を与え始めるのは、UAC の要点に反しているように思えます。もちろん、必要ならそうします。

助けや提案をありがとうございました。

ところで、これを行う理由は、世界中に散らばっている他の開発者に、私の干渉やサーバーへの実際のアクセスなしに、変更をステージング サーバーに直接プッシュできるようにするためです。そのため、アプリ プールを手動で再起動すると、目的が無効になります。