なになれ

IT系のことを記録していきます

AWSでKubernetes環境を構築する際のIngressについて

Ingressはアプリケーションレイヤのロードバランサに当たるリソースでSSL化などが可能になります。
Ingressの実装は様々なIngress Controllerに依存します。
例えば、Nginxを利用したNginx Ingress ControllerやGKEに含まれているGKE Ingress Controllerなどがあります。
AWSKubernetesを構築する際には、EKSにおいてもIngress Controllerは存在しないため、構築者自身がIngress Controllerを設定する必要があります。

今回は、AWSで利用可能な以下のIngress Controllerを紹介します。

AWS ALB Ingress Controller

IngressリソースによってALBが作成されるIngress Controllerです。

kubernetes-sigs.github.io

メリット

  • 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です。

kubernetes.github.io

メリット

  • 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といった手法を適用できて、ユーザの体験を向上させることが可能になります。

参考資料

angular.jp

AWS IAMポリシーの作成と確認方法

複雑なIAMポリシーの作成と確認を行った時にそれなりに苦労したので情報を整理したいと思います。

概要

IAMポリシーとはAWSリソースのアクセス管理を定義するものです。
IAMポリシーを定義する際に実際にAWSリソースのアクセス管理が適切にできているか確認するのが難しいです。 そのため、どのようにして作成し、確認を行うか検討した結果をまとめます。

IAMポリシーの作成方法

IAMポリシーの作成方法にはJSONとビジュアルエディタがあります。 既にポリシーの定義が分かっている場合はJSONをそのまま貼り付けるのが簡単です。
ここではポリシーの定義が分からない前提でビジュアルエディタをオススメします。

ビジュアルエディタを使うメリットは以下の通りです。

  • JSON構文を覚えずにポリシーを作成可能
  • ポリシーにおいて選択可能な値(アクション、リソースなど)を検証可能

IAMポリシーの作成に当たっては各種警告に遭遇します。下記の情報を参考にすると良いです。
IAM ポリシーのトラブルシューティング - AWS Identity and Access Management

IAMポリシーの確認方法

まとめ

複雑なIAMポリシーを作成するのは地味に大変です。
アクションやリソースの値に応じて設定可能な値が異なるので、そういったことを理解するために各AWSAPIにひもづくポリシーの仕様を把握するのが近道です。