はじめに

この記事はAmazon EKS #2 Advent Calendar 2019の3日目の記事です。
WordPress on AWS EKS 的な作業をしたんだけど、AWS ALB Ingress は時期尚早だったわ、という話をします。
2019年11月半ばくらいの話であり、この記事が表に出た後にバージョンアップしてる可能性はゼロじゃないです。

TL;DR

やってみた系ブログのやってみた、は、そりゃできる
ただし、AWS ALB として出来ることの多くが（たぶんもうしばらくは） できない
つまり、表向き動くものはできる、が、顧客が本当に必要だったもの、は（今は）できない、のがわかったという話

環境構築

terraform module を使いましょう
https://github.com/terraform-aws-modules/terraform-aws-eks/tree/master/examples/basic
ちなみに terraform advent calendar もよろしくお願いしますｗ

AWS ALB Ingress Controller

https://github.com/kubernetes-sigs/aws-alb-ingress-controller
Setup のところに導入方法があります
今回の作業では helm のインストールやらコントローラのインストールやらも terraform の k8s provider を使ったんだけど、null_resource や file 関数を乱発したし、概ねマニフェストが公開されているのをいちいちリソースに直すのも面倒だった。k8s provider も正直いらんかった
ExternalDNS とセットで使えば、作成された ALB を Route53 に登録してくれて便利。これは便利。

（現時点でも）できることリスト

ALB(Application Load Balancers) - LR(ListenerRules) - TG(TargetGroups) の基本構成
80,443 ポートリスナー
ACM 設定
パスベースのLR
Cognito を挟んでアクセス制限的なこと
複数のTGへの振り分け（今回はWP本体とWP管理画面用の２つに分けた）

うん、まぁ一通りできる雰囲気はあるよね。ところがどっこい。

（現時点では）できなかったことリスト

ポートリスナー別のLRは書けない
- 80 -> 443 へのリダイレクトルールは書ける
- 80 用、443用と分けて書くことができない（別々のLRが書けない。両方に同じLRが同じ順序で登録される。これは酷い）
- でもまぁ正直そんなに問題じゃない（80の最初で443へリダイレクトで特に困らないから）
Cognito を挟むと全てのLRに適用される
- 一部だけ外す、はできない
- WP管理画面にCognitoを残してブログ面は外す、ができない。これは辛い
パスベース以外のLRは書けない
ALBの名前が自由に付けられない
- 逆にそれさえあれば ExternalDNSなくても困らないのに
- クラスター別の数字-deploymentで付ける名前-よくわからない英数字、みたいな名前になる
- たくさんあると管理がめんどくさい
できないこと、ではないけど、裏で頻繁に書き直し？が走っていて、コンソールやCLIでALBに手を加えてもマニフェストどおりに戻る
- 手でLRを追加したり変更したりしても、元に戻ってしまう。Ingress を削除するわけにもいないので手が打てない
コスト無視なら表向き用の ALB を Ingress でもう一つ作って(ブログ用と管理画面用と分ける)、CloudFront オリジンの1つとして追加して、パスベースルーティングを CloudFront にやらせることも可能だけど、ソウジャナイ感があったのでやらなかった

対策できたこと

Cognito はなしの方向で、CloudFront + WAF でがんばった
LBの名前はどうにもならないけど、ExternalDNS で Route53 record は固定の名前で登録できるので、それをオリジンにした
CloudFront からだけ接続許可、は未だに出来ていないので、オリジンLBでアクセスされると普通のWPと同じ。セキュリティが気になるならここは致命的

最後に

遊びや勉強目的で使う分には特に問題ない
仕事で使うなら今はやめといたほうが無難
先のISSUEのコメント先のリンク先にもあるけど、今コミッタたちもどうやってマニフェストを書いて展開するか、を議論しているようなので、経過観察
一番欲しいところ、パスベース以外のルール対応なので、この辺どうにかすればワンチャン。。。