今回利用するテスト用のnginxを構築します。

まず pod/my-nginx を構成します。 設定するのは、Deploymentオブジェクトですが、deployment → replicaset → pod の順番に自動的に pod/my-nginx が作成されます。

このコードは次のように適用できます。

次に svc/my-nginx を作成します。

この時点ではWebブラウザから、nginxに接続することはできません。 外形的にpod、service が構成されているか確認していきます。

これまで利用してきたnginxを利用して、Reverse Proxyサーバーを構成します。

Reverse Proxyサーバーと呼んでいますが、利用するイメージは my-nginx で利用しているものと同じです。

今回は次のような設定ファイルを /etc/nginx/conf.d/proxy.conf の名前で配置するPodを作成することにします。 この設定により、context_rootは /yasu-abe/ から / に変換されます。

このような設定を行なうために、次のような configmap-proxy.yaml ファイルを適用します。

このファイルを先ほどと同じように適用します。

このConfigMapに設定した設定ファイルを利用する、nginxをmy-proxyの名前で作成します。

このファイルの内容は、特別変更する箇所はないので、URLを指定して直接実行します。

次に、service/<namespace>-svc の名称で、pod/my-proxy に接続するためのServiceオブジェクトを作成します。

次のような手順で、これを適用します。

ここまでで、最初に構成したnginxサーバーに、Proxyサーバーを経由してアクセスする準備が整いました。

下記のユーザーリストから自分のURLに数回アクセスし、各サーバーのログファイルを確認してください。

'-f’オプションを追加したり、パイプ("|")とtailコマンドを組み合せるなどして出力を調整してください。

ここでは、同じ作業手順で、ユーザーIDの違いを吸収する必要があります。 BASHコマンドラインでは、$(id -un) を利用することで、ユーザーIDに変換しています。

svc-proxy.yaml 等のYAMLファイルを利用する際には、metadataなどの部分で指定している名前(s12xxxxx)を各自のユーザーIDに変更しています。

svc-proxy.yamlを例として、変換の方法を説明します。

このname:の部分は、自分のID(namespace名)に一致させる必要があります。 svc-nginx.ymalファイルは、先ほどど同様に apply します。

この作業には、次のように2つの方法が考えられます。

一般に公開・市販されているアプリケーションの中には、特定のcontext_rootでしか動作しないものがあります。 そのようなアプリケーションの多くはcontext_rootとして、"/" を使用するため、専用のホスト名を必要とする事が一般的です。

アプリケーション毎にcontext_rootを分けることで、単一のホスト名の元に複数のアプリケーションを含めることが可能となります。

技術的にはホスト名を複数準備しても、VirtualHostというHTTPヘッダのHost:行を見て挙動を変更する機能を利用すれば、物理的なサーバーは1台で対応可能で、必ずしもホスト名を割り当てなればいけない事が問題になるとは限りませんが、以下のような問題があります。

コンピュータプログラムにおいては、再配置可能(relocatable)である事は意識されますが、Webアプリケーションの場合にはJ2EEアプリケーションであっても無視されることがあります。

Proxyを利用することによって、これらの問題をある程度は解決できますが、アプリケーションが'/'とは異なるcontext-rootで動くことを想定していない場合には、特定の操作ができないといった不具合に遭遇することになります。

例えば、2018年後期に、第9回目のSCCPで取り上げたdvwaをK8sにデプロイする場合を例に説明します。

まずpodを稼動させます。これは2018年に提供したYAMLファイルをそのまま利用します。

この `pod/dvwa にアクセスするために次のようなServiceオブジェクトを作成します。

以下のように適用します。

Proxyから、このサービスにアクセスするために、次のように変更した、ConfigMapオブジェクトを登録します。

editコマンドで cm/nginx-conf を編集し、my-nginx を dvwa-svc に変更するだけでも良いのですが、次の方法でも cm/nginx-conf を変更できます。

このように設定を変更したら、反映させるために、pod/my-proxy を削除します。

ここまでの操作が完了すると、以下のURLからdvwaアプリにアクセスできるようになっています。

次のリストから自分のURLlにアクセスし、確認してください。 最初はブラウザのキャッシュ(cache)からNginxのページが見えるかもしれないので、Shiftキーを押下しながら再読み込みしてください。

無事に成功すると、次のような画面が表示されるはずです。

このアプリケーションの次の情報を利用してログインしてください。

以下の手順で、初回操作を完了します。

これで、一応アプリケーションを利用することができるようになります。

日付から自分がアクセスした際の記録を確認します。

Proxyがmy-nginx, dvwaのうち、どのアプリケーションに向いているか設定を確認しておきます。

次のような出力を確認します。

このような状況であれば、dvwa-svcに向いていることが分かるので、dvwaアプリの出力を確認します。

次のようなログが確認できると思います。

まずテンプレートとして利用したYAMLファイルの内容は次のようになっています。

ここで、"s12xxxxx"を自分のAINS-ID(namespace)に変更していて、、"dvwa-svc"というホスト名を指定することで、my-nginxのpodにアクセスさせていました。

これらの変換を行なった、実際の設定は次のようになっています。

このホスト名を含む http://dvwa-svc/ の部分を、http://my-nginx/ とすることで、当初はnginxに接続していました。

これまで利用してきたService定義を確認してみます。

例えば次のようにServiceに設定した項目が表示されるはずです。

Ingressのリクエストを処理する <your namespace>-svc (e.g. yasu-abe-svc and s13xxxxxx-svc) の定義を確認します。

出力から .spec.selector の内容を確認します。 次のように app: my-proxy となっていると、https://inovtst9.u-aizu.ac.jp/s13xxxxxx/ のようなURLでアクセスした際にReverse Proxyサーバーに接続します。

この内容が app: harbor-nginx のように他のアプリケーションを示していると、直接アプリケーションに接続している状況になります。 Reverse Proxyサーバーに接続するためには、次のコマンドを実行してください。

利用しているテンプレートファイルは次のような内容になっていて、"s12xxxxx" の部分を自分のnamespace名(AINS ID)に変更するためにsedコマンドを利用しています。

例えば、次のような cm/nginx-conf を定義すれば、両方のサービスに接続することができます。

このファイルを次のような手順で反映させます。

これで先ほど確認した cm/nginx-conf が更新されました。

DVWA用に cm/nginx-conf を設定した際のように、設定を反映するためには、pod/my-proxy を再起動します。

これによって、例えば次のようなURLで両方のサービスにアクセスすることができるようになります。

それぞれにアクセスをして挙動を確認してください。

Reverse Proxyサーバーを設定するためのcm(ConfigMap)/nginx-confオブジェクトに対する基本的な操作についてまとめます。

次のような方法で、任意のEditorを指定して configmap/nginx-conf を変更することができます。

ここで開いたEditorの中で、追加したサービス用に次のような location セクションを他と並列に配置します。

http://newapp-svc/ のように書くことができるのは、kubectl -n $(id -un) get svc で確認できるService名に "newapp-svc" が登録されている場合です。

画面に表示されたService名の中から適切な名前を選択して書き換えるか、(LoadBalancerを利用している場合は)IPアドレスを利用して、http://192.168.100.xx/ のように書き換えてください。

最後に必ず変更した後で、ProxyのPodを再起動してください。

最初に利用した configmap-proxy.yaml を利用して、BlockStorage用のWebサーバーにアクセスできるように cm/nginx-conf を編集します。

ここで設定した cm/nginx-conf の内容は次のようなコマンドで確認してください。

nginxは設定ファイルを自動的に読み込まないので、pod/my-proxy を一度削除します。

BlockStorageと同じ方法で変更が可能です。

コマンドラインの"block"の文字列を"file"に置き換えて実行してみてください。

例えば configmap-proxy.yaml を元に、次のようなYAMLファイルを準備します。

my-proxyの設定ファイルを変更したら、必ずmy-proxyのプロセス(pod)を再起動してください。

この内容を適当なファイル名のファイルに作成し、次のようなURLでアクセスできることを確認してください。

方法はいろいろありますが、ここでは自分のWebページを提供するDockerコンテナを作成します。

この他には次のような方法が考えられます。

これらの方法の利点は、コンテンツを更新する度にコンテナを再作成・再登録する必要がない点です。

以下の作業は、適当な作業用ディレクトリ内で移動(cd)せずに行います。

次のようにhtmlディレクトリを作成し、静的コンテンツを配置します。

もし始めてHarborを利用する場合には、最初に自分ID名でプロジェクトを登録してください。

この作業が完了していれば、次の要領でコンテナにタグを付けて、pushします。 なお macOS環境などで、buildxを利用している場合には既に操作は完了していますので、実施する必要はありません。

例えば次のようなYAMLファイルを配置します。

いままでは、cm/nginx-confの内容は次のようになっていました。

nginxのlocation命令は長さ優先でマッチするため、先頭に記述する必要はありません。

Proxyサーバーの設定は、Nginxに対する設定ファイルの一部です。

ファイルの内容については、次のコマンドで確認してください。

configmapオブジェクトを頻繁に変更することになりますが、その時にPodの再起動が必要です。

ここまでで問題なければ、次の中から自分のIDが含まれているURLにアクセスしてコンテンツが表示されます。