AWSでKubernetes環境を構築する際のIngressについて
Ingressはアプリケーションレイヤのロードバランサに当たるリソースでSSL化などが可能になります。
Ingressの実装は様々なIngress Controllerに依存します。
例えば、Nginxを利用したNginx Ingress ControllerやGKEに含まれているGKE Ingress Controllerなどがあります。
AWSでKubernetesを構築する際には、EKSにおいてもIngress Controllerは存在しないため、構築者自身がIngress Controllerを設定する必要があります。
今回は、AWSで利用可能な以下のIngress Controllerを紹介します。
AWS ALB Ingress Controller
IngressリソースによってALBが作成されるIngress Controllerです。
メリット
- ALBによる高機能なロードバランサ機能を扱うことができる
デメリット
- Ingressリソース毎にALBリソースが作成される
ALB Ingress ControllerはALBの機能を利用することができるので、可能な限り利用するのが良いと思います。
但し、Ingressリソース毎にALBが作成されてしまいます。
複数のサービスがある場合に、1つのサービスに1つのIngressリソースを作る構成だとリソース過多になってしまいます。
ALBの設定を変えて、1つのURLで複数のサービスを公開する方法も取れますが、場合によってはサービスの内部的なURLと公開されるURLが異なることで404エラーになる可能性があります。
NGINX Ingress Controller
IngressリソースによってNginxが作成されるIngress Controllerです。
メリット
- URLのrewrite機能によって複数のサービスに向き先を設定できる
デメリット
- SSL化にはSecretリソースを用意するといった準備が多い
- ALBが使用できない
NGINX Ingress ControllerにはURLのrewrite機能によって複数のサービスに向き先を設定することができます。
但し、ALBを利用することができないのが気になります。
オススメ構成
AWS ALB Ingress Controller → NGINX Ingress Controller
各Ingress Controllerのデメリットを補える構成です。
AWS ALB Ingress ControllerでALBを利用するのと、複数のサービスを1つのALBで参照するためにNGINX Ingress Controllerを利用し、nginxのrewrite機能を利用します。
設定のポイントは以下の通りです。
- NGINX Ingress Controllerをインストールする際にNodePortを利用する
- ALB Ingress ControllerのIngressの向き先をNGINX Ingress ControllerのNodePortに向ける
設定例
NGINX Ingress ControllerをNodePortでインストール
apiVersion: v1 kind: Service metadata: name: ingress-nginx namespace: ingress-nginx labels: app.kubernetes.io/name: ingress-nginx app.kubernetes.io/part-of: ingress-nginx spec: type: NodePort ports: - name: http port: 80 targetPort: 80 protocol: TCP - name: https port: 443 targetPort: 443 protocol: TCP selector: app.kubernetes.io/name: ingress-nginx app.kubernetes.io/part-of: ingress-nginx
ALB Ingress
apiVersion: extensions/v1beta1 kind: Ingress metadata: name: ingress-alb namespace: ingress-nginx annotations: kubernetes.io/ingress.class: alb spec: rules: - host: example.com http: paths: - path: / backend: serviceName: ingress-nginx servicePort: 80
NGINX Ingress
apiVersion: extensions/v1beta1 kind: Ingress metadata: name: ingress-http-svc namespace: default annotations: kubernetes.io/ingress.class: "nginx" nginx.ingress.kubernetes.io/rewrite-target: / spec: rules: - host: example.com http: paths: - backend: serviceName: http-svc servicePort: 80 path: /http-svc --- apiVersion: extensions/v1beta1 kind: Ingress metadata: name: ingress-http-svc2 namespace: default annotations: kubernetes.io/ingress.class: "nginx" nginx.ingress.kubernetes.io/rewrite-target: / spec: rules: - host: example.com http: paths: - backend: serviceName: http-svc2 servicePort: 80 path: /http-svc2
まとめ
NGINX Ingress Controllerを活用することで、AWS ALB Ingress Controllerの欠点を補うことができるようになります。
参考
AngularにおけるLazyLoadingの実現方法
前提条件
- Angular8
LazyLoadingとは
通常のSingle Page ApplicationだとJavaScriptファイルなどのアセットを初回ロード時に全て読み込みます。
初回ロード時の読み込み時間を軽減するために、モジュール毎に分割して必要な時に読み込むのがLazyLoadingと呼ばれる手法になります。
JavaScriptのDynamic Importという機能を使って実現します。
初回ロードの時間が短くなるのでユーザ体験がよくなります。
実現方法
app-routing.module.ts
const routes: Routes = [ ... { path: 'page', loadChildren: () => import('./page/page.module').then(mod => mod.PageModule) }, ... ];
import
を使って動的にモジュールを読み込んでいます。
PreLoadingとは
LazyLoadingの応用として、PreLoadingという方法が使えます。
これは初回表示の裏側で分割したモジュールを読み込むようにする方法です。
これにより、ページを切り替えた時に発生するLoading時の遅延を抑止することが可能になります。
実現方法
app-routing.module.ts
... RouterModule.forRoot( routes, { preloadingStrategy: PreloadAllModules, } ) ...
PreloadAllModules
によりLazyLoading対象のモジュールがPreLoadingの対象として扱われます。
まとめ
Angularでは簡単にLazyLoadingやPreLoadingといった手法を適用できて、ユーザの体験を向上させることが可能になります。
参考資料
AWS IAMポリシーの作成と確認方法
複雑なIAMポリシーの作成と確認を行った時にそれなりに苦労したので情報を整理したいと思います。
概要
IAMポリシーとはAWSリソースのアクセス管理を定義するものです。
IAMポリシーを定義する際に実際にAWSリソースのアクセス管理が適切にできているか確認するのが難しいです。
そのため、どのようにして作成し、確認を行うか検討した結果をまとめます。
IAMポリシーの作成方法
IAMポリシーの作成方法にはJSONとビジュアルエディタがあります。
既にポリシーの定義が分かっている場合はJSONをそのまま貼り付けるのが簡単です。
ここではポリシーの定義が分からない前提でビジュアルエディタをオススメします。
ビジュアルエディタを使うメリットは以下の通りです。
- JSON構文を覚えずにポリシーを作成可能
- ポリシーにおいて選択可能な値(アクション、リソースなど)を検証可能
IAMポリシーの作成に当たっては各種警告に遭遇します。下記の情報を参考にすると良いです。
IAM ポリシーのトラブルシューティング - AWS Identity and Access Management
IAMポリシーの確認方法
- IAMPolicy Simulatorを使う
- 簡易に確認するのに有用
- 実際にAWSのリソースを操作してみないとどうなるかは分からないのであくまで参考程度
- ポリシー確認用のIAMロールを用意する
- AWSコンソールで確認する
- 該当のIAMロールに切り替える
- コンソール上でAWSリソースを操作してアクセスできるかを確認する
- AWS CLIで確認する
- IAMロールへの切り替え
- dry-runオプションを付与してコマンドを実行する
- 全てのコマンドにdry-runオプションがあるわけではないのであれば利用する
- AWSコンソールで確認する
まとめ
複雑なIAMポリシーを作成するのは地味に大変です。
アクションやリソースの値に応じて設定可能な値が異なるので、そういったことを理解するために各AWSのAPIにひもづくポリシーの仕様を把握するのが近道です。