目次

既存環境の置き換え
環境リプレース時の問題
Azureで実装待ちの要素技術
その後

◆既存環境の置き換え

十分テストしてから置き換えるべきで、そのテスト環境をどうするか？
CIとの連携で詰まる。

置き換え前の事前テスト環境

MySQLを含めてた既存環境のシミュレートは非常に困難で断念。
仕方なく既存AzureマネージドMySQLを利用してテスト環境を構築する。
Redis Cacheも既存のものを利用しようとしたが管理情報が混ざってしまうようで、PHPのセッションタグなどで環境ごとに分ける必要があることが判明。
やむなくRedis Cacheは移行テスト期間中だけAKSクラスタ内の使い捨てRedis Podで運用することに。

CIとの連携

リポジトリのソースコードを修正。
docker buildしてコンテナレジストリにpush。
CI環境でコンテナをロードして各種(セキュリティなど)チェック。
CI環境にデプロイメント。
CIのことはあまり考えていなかったので、ここが一番苦労しました。

ほとんど開発に関わっていなくてCIの仕組みを全然理解していなかった自分が悪いのですが。このリプレース作業を機にだいたい理解することができました。
インフラとかSREとか呼ばれるエンジニアはきついですね。ネットワーク/ストレージ/OS/ミドルウェアは当然のスキルとして、コンテナ運用では更にアプリの知識もなくてはならない。インフラのコード化を高度に追求している会社では更にCIの経験もなくていけない。更に運用や監視やプロジェクトマネジメントなどなど、、、そんなスーパーエンジニアはいない！！！と叫びたい気分です。

◆環境リプレース時の問題

環境置き換えた後、旧Virtual Machine上のdocker-composeが起動しているとバッティグして動作しなくなる機能あり！想定してなかったので焦りました。
しばらくCIを回していたら、 db migrate していないことが判明！
かなり後になってから、 docker-compose up 毎に機能を実行していたことに気づく。kubernetes jobで機能作って必要な時に呼ばなくてはいけない。これは今現在もまだ対処していません。

失敗ばかりでしたね、とほほ。急いでkubenrtesの機能を使って対処した記憶があります。

◆Azureで実装待ちの要素技術

Cluster Autoscaler -> preview段階
Azure Kubernetes Service Ingress Controller -> k8s IngressとAzure Application Gatewayが統合されるはず

付記：

Cluster AutoscalerはAKSに仮想ノード(AWS Fargateみたいなもの)というものができて、どちらか検討中。ノードを意識しないでクラウド業者に任せられるので仮想ノードが優勢かな。
AKSのIngress Controllerは2019年中には完全に統合しないようなので、来年の課題とします。

その後

半年以上前に既存Virtual Machine運用からほとんど無理やりKubernetes環境に移行したのですが、結果的に良かったと思います。
内容を振り返ると結構無茶苦茶なことしているのですが、スタートアップなのでいくらでもチャレンジを許してくれる雰囲気に救われました。
その後優秀な同僚がいろいろと仕組みを整えてくれて、今では見違えるようなシステムに仕上がっています。
本番環境にkubernetes導入を不安に思って二の足を踏んでいる会社がたくさんあると思いますが、苦手なストレージやDBやバッチ処理をクラウドマネージドにすることで十分運用可能だと思います。
その後のトピックはいつか記事にしたいと思います。