目次
- コンポーネント分割への道
- 導入前の検証環境
- AzureでのkubernetesであるAKSの特徴
- Azureアプリケーションゲートウェイをどうするか？
- SSL証明書をどうするか？
◆コンポーネント分割への道
- 当初docker-composeに乗っている全種類のコンテナをまとめて１つのPodとしてスケールアウトしようとしていたが、ヒアリングミスで勘違い。
- 目的はコンテナの種類ごとにコンポーネント毎に分離して、各コンポーネント毎にスケールアウトしたいという要望だった。
- このような事情によりコンポーネント分割へ。
◆導入前の検証環境
- 当初MySQLもAKSクラスタ内部で検証しようとしていたが断念。
- 既存リソース(MySQL)のもう１つのフロントエンド的な運用でテスト環境構築に至る。
◆AzureでのkubernetesであるAKSの特徴
- azコマンドCLIとkubectlコマンドが統合されている。要するに、az login認証・権限 = kubeコマンドの権限。
- コンテナの標準出力/エラー出力を自動的にagentがLog Analyticsに転送してくれる。syslogログドライバの設定などは必要ない。
◆Azureアプリケーションゲートウェイをどうするか？
普通に構築するとAzureアプリケーションゲートウェイを通過した通信が、グローバルIPアドレスを通じてバックエンドであるAKSクラスタにアクセスするので、セキュリティ的にかなり問題が残る。
これに対処するために以下の構築方法を採用しました。
- Internal Loadbalancers with Application Gateway (AKS)
https://rinormaloku.com/prohibiting-direct-access-microservices-aks/
ちょっとわかりずらい図ですが。
- Public IPが露出するのは、Application Gatewayのみ。
- Application Gatewayのバックエンド指定はAKS(kubernetes)内のサービス(大抵はnginx)のPrivate IP。
ただ、これを実現するためには、AKSクラスタ構築時に面倒な作業が必要です。
- AKSクラスタを作成(デプロイ)すると自動で「MC_xxx_japaneast」などのリソースグループが勝手に作成される。
- AKSクラスタのネットワークはカスタムで、
172.xx.0.0/24と作成したら、ゲートウェイ用のサブネットを172.xx.1.0/26などのように手動で用意してあげないといけない。 - このMC_xxx_japaneastのリソースグループを指定して、さらに用意したサブネット
172.xx.1.0/26を指定してアプリケーションゲートウェイを新規作成しないといけない。 - あとは、ゲートウェイのバックエンドにAKSクラスタ内のService(大抵nginx)のExternal IPを指定すると通信が到達するようになります。
なんのことかさっぱり分からない人はネットワークを勉強してくださいね。
◆SSL証明書をどうするか？
- 元々docker-composeでcertbotを利用して自動更新していた。
- 今回の移行作業を機にワイルドカード証明書にしようとしたが、Lets EncriptのDNS-01チャレンジでないとだめみたいで困る。
- しかもDNS-01チャレンジはAPI連携必須。お〇〇.comでDNSレコード管理していたので無理！将来Azure DNSでドメイン管理に移行しないと無理。
- AKS側もingressを使用しているわけではなくアプリケーションゲートウェイを利用しているのでnginx-ingressなどには頼れなく非常につらい。
- このようなわけで七転八倒したあげくに今回の移行ではあきらめました。
付記：
半年以上経過した2019年末現在、いまだに完全に自動化は実現しておらず、、、まあDNSドメインが増えたりといろいろ環境の激変があったわけで。一生懸命格闘していた頃が懐かしいです。
◆次回
次回はいよいよ既存システムのリプレーズ作業なのですが、地獄をみることになります。。。