私はマーケティング部門にリダイレクトを自分で維持する機会を与える状況にあります。これまで、彼らはその情報をIT部門に渡し、nginx.conf
で維持していました。
これらの人の一部は、IISまたはApacheでのリダイレクトに精通していますが、nginx構成への直接アクセスを許可するオプションはありません。
私は、アクセスを許可できる.htaccess
ファイルに対するnginxサポートがないこともわかります。また、nginxに含まれるconfファイルへの書き込みアクセスを許可しないほうがよいでしょう。私のマーケティングはnginxのセットアップを数時間で壊すと思います...
ロードバランサーの心臓部へのアクセスを許可せずに安全な可能性はありますか?
そのような書き換え構成を適切に分離する組み込みの方法はありません。あなたが取ることができる3つのアプローチがあります。
map module を使用すると、別のファイルからのマッピングを含めることができます。ファイルが変更された後もNginxを再ロードする必要があり、マッピングファイルは構文的に正しい必要がありますが、実行できる内容が制限されます。
nginx.conf
:
map $uri $new {
include /etc/nginx/marketing.map;
}
server {
...
if ($new) {
rewrite ^ $new redirect;
}
...
}
marketing.map
:
/about /company/about-us;
~^/people/(?<person>.*)$ /company/people/$person;
1つは、リダイレクトを、定義したフォーマットからnginx構成に変換するスクリプトを記述することです。たとえば、スペースで区切られたリダイレクトのリストがあるとします。
/foo/(.*) /bar/$1
そしてスクリプト:
#!/bin/sh
while read SOURCE DEST; do
echo "rewrite $SOURCE $DEST permanent;"
done < redirects.txt > redirects.conf
次の構成を作成します。
rewrite /foo/(.*) /bar/$1 permanent;
次に、設定全体でnginx -t
を実行して、再読み込みする前にそれが有効であることを確認します。
2番目のオプションは、 ngx_lua 、 ngx_Perl または ngx_js を使用して、nginx自体でリダイレクト構成の読み取りと処理を実装することです。たとえば、 rewrite_by_lua
ディレクティブを使用すると、 Lua コードを実行して書き換えを作成できます。ただし、リクエストごとにコードを解釈するため、パフォーマンスに注意する必要があります。