Kusanagi on GKEチャレンジ その5 ギブアップ
タイトルに書いた通り今回を持ってギブアップでございます。残念です。
以下に経緯と理由書きます。
Kubenetesチャレンジ その1
Kubenetesチャレンジ その2
Kubenetesチャレンジ その3
Kubenetesチャレンジ その4
そもそもの要件は何だったのか
やってるうちに自分でも何がしたかったんだか分からなくなってきたので今一度整理しますが、そもそもの要件は、「Kusanagi on Dockerのイメージそのままに、yamlちょろっと書き換えてGKEに上げたいなー」です。
こちらもKusanagi on Dockerやってらっしゃいますが、イメージは自身で作成されたものをGCRからPullする形になってます。
バージョンがコロコロ変わることを考えると、公式DockerHUBからPullしてGKEにデプロイできないかな、というのが狙いでした。
敗因
えー、簡潔にいうと、Kusanagiプロビジョニング時に利用するシェルスクリプトをGKE用にカスタマイズできない、もしくはカスタマイズにとてつもなく時間がかかる、からです。
以下の図を見て下さい。
青線はボリュームのマウント状態、緑はコマンド実行の流れです。DockerへのKusanagiプロビジョニングは「kusanagi-docker(.sh)」で実行されますが、ステップは主に以下の3つです。
- ①変数から環境設定ファイル、dockerデプロイ用yamlファイル作成。
- ②docker-compose経由でコンテナをデプロイ
- ③(たぶん)config用コンテナにゴニョゴニョして環境設定。ローカルで環境設定したWordPressをインストール。
※簡略化するために、色々すっ飛ばしてます。
①②は問題ないです。田中(゜p゜)がちょいyaml書き換えて、GKEに問題なくデプロイできてます。
問題は③です。
ちょろっとシェルスクリプト修正すりゃーkubectl化できる話じゃないのです。
ファイルが十数個にまたがってるのと、docker、docker-compose、wp-cliコマンドフル活用で、流れ追うのもやっと。
そもそもコレをkubectlに変換すんの？ つうかできんの？
立ち止まって考えてみた結果
そもそもの要件は「ちょろっとyaml書き換えてGKEに上げよう！」だったので、シェルスクリプトを重厚に書き換えるのは脱線しすぎです。
よしんばコミュニティへの貢献とかのために、頑張って田中(゜p゜)がシェルスクリプト書いたとしても、ろくでもない品質のために迷惑かけかねませんし、田中(゜p゜)もシェルスクリプトをマスターしたいわけじゃないです。
※いや、仕事で2ヶ月くれるっつうなら頑張るけど…。
よって潔くギブアップ！
残念ですけど、GCPにWordPressデプロイするとしたら以下の2パターンにしようと思います。
趣味のWordPressなら、後者のほうが圧倒的にコスパ良さそうですけどね。
仕事用にするんでも、後者はMySQLオミットしてCloudSQLに切り替え、コンテンツ領域をPersistentDiskにすれば、ロードバランサ＋オートスケーラーでブン回せそうですし。おすし。
今後の展開
なんでこのシェルスクリプトはDockerFileに置き換えないんだろなー、とか考えましたが、そもそもフツーのOSに載せていたスクリプトから派生しているようなのと、Kusanagiのロードマップやビジネスプランなどから、あまりパワーを入れたくない領域なのかもしれません。
田中(゜p゜)個人としては、Dev/Opsのインフラ領域について理解を深めたいので、それっぽいテーマ定めてKubernetesトレースしたいと思います。
skaffoldあたりやってみたいなー。
でも田中(゜p゜)プログラミング開発環境あんまりだからなー。
(終)