Happy Halloween!!
秋の夜長、いかがお過ごしでしょうか？
毎日、コンテナに溺れているインフラ担当のShimadaと申します。
今回は、エンジニア人生に終焉を迎えかけた、「コンテナ化で挫折した」お話をしたいと思います。
これまで、オンプレミスやプライベートクラウドでサービスを運用していて、どこかから聞こえてくる「どっかー」「こんてな」という単語に「テスト環境・・・」と思っていましたが、パブリッククラウドでサービス運用する環境に来て、ついに「コンテナ」に浸かる時が来てしまいました。
経緯
「どっかー」「こんてな」「くーべねてぃす」という言葉を色々なところで見かけるようになって久しい昨今、主要なクラウドベンダではコンテナ管理サービスの本格的な提供が開始されました。
弊社も、この波に乗らない手はない！！という唯一無二の決定的な判断のもとコンテナ化への漆黒の闇の中を退路無く走り始めることになりました。
社内クラウドでテスト環境の思惑
まずはDockerfile
現在、社内の個人開発環境には以下の選択肢があり個人の好みで選択する事が出来ました。
- クラウド上のVM
- 個人PC上のVM
- 個人PC上でのDocker
- 個人PC上に諸々個別にインストール（稀）
幸いなことにdocker-composeで稼働するテスト環境は整っており、あとは”kurbenetesクラスタを用意”して”乗せるだけ”の状態でした。
コンテナ化へ向けた動作検証環境
dockerとkubernetesの勉強も兼ねて個人PCを使用して環境を構築してみることにしました。
着手したころは、docker for mac、docker for windows共にホストOSとのファイル共有などに難があったため、PC上にLinuxが入ったVMを複数用意しLinux版のdockerを使用しました。
minikubeでkubernetesの動作確認
手始めにminikubeを使ってシングル構成のkubernetesを構築してみます。 kubernetes.io コンテナ環境の構築は、手順も自動化されていて、構築->削除->構築・・・と繰り返し簡単に行えるところが最大の魅力かと思います。
唯一無二のRancherを発見
主要なクラウドベンダではコンテナ管理サービスが提供されていますが、検証用に社内でkubernetesのクラスタを構築することを考えました。
kubernetesクラスタの構築は、手順化されていて難しいものではないようですが、複数クラスタが必要になったときに、手作業というのはクラウド環境に慣れてしまうとなかなかの苦痛となってしまいました。（オンプレで作業していたころは当たり前のことでしたが。。。
いろいろと調べて、Rancher を見つけました。 rancher.com
ここまでクラウドベンダなどの環境に対応したものはないでしょう。（多分。。。 rancher.com
ノード用のOSも提供されていて良さそうです。 rancher.com
ちょうどver2.0がリリースされデータ管理や管理画面の使い勝手がよくなった直後のようで、即採用を決めてしまいました。
パブリッククラウドのコスト削減
個人PCに用意したVM上でRancher環境を構築してみました。 https://rancher.com/docs/rancher/v2.x/en/installation/ha/rke-add-on/rancher.com
現在は、helm chart（パッケージ管理）によるインストールが出来るようになっています。
が、着手当時はRKE (Rancher Kubernetes Engine) というコマンドでのインストールしかできませんでした。（これが後にちょっとした問題になります）
Rancher、kubernetesなどコンテナ関連のプロジェクトは回転が速いようなのでお試しの際には、最新の手順などを確認した方が良さそうです。
PC1台にVMを使って複数ノード用意した為、快適な環境とは言えない状態でしたが、利便性はとてもよく”魔法の杖”を手に入れた気分になりました。
Rancherを触っているうちに、夢が広がっていきます。
現在、branchごとの確認環境、本番リリース前のステージング環境はクラウド上にサーバを用意して運用しています。
社内で使用していないPCをcontrol＆workerノードにして、開発者＋αの個人PCをworkerノードに入れてクラスタを大きくすれば、確認環境+ステージング環境用のリソースは確保できるのではないか。
クラウド上の確認環境+ステージング環境を停止できれば、コストも削減できメリットだらけ。
題して
”みんなオラに、ほんの少しずつだけ、元気を分けてくれ、少しでいいんだ。。。”
作戦
進まない環境構築
膨張しきった夢の元、明日にときめきつつ構築作業を進めました。
PC1台ではリソース不足
構築したクラスタに既存のコンテナを配置していきます。
検証中はRancherのクラスタ上に既存のコンテナを配置して利用していましたが、アプリケーション用にkubernetesのクラスタを用意することにしました。
予想はしていましたが、PC1台ではリソース不足で複数クラスタを稼働させることはできませんでした。
追加のPCを用意して、今まで同様にLinuxを入れたVMを配置して作業を続けることにしました。
PC2台だと不安定
2台目を投入してから状況は一変しました。
今まで問題なく進んだRancherからのkubernetesクラスタ構築の工程がエラーになってしまいます。
VMのCPUやメモリ、diskを増やしても変わりません。
何を変えても、何度やっても動きません。
最後は何も動きません。
衝撃の結末
意識が遠くなり、現実逃避を始めるころ、転機が訪れます。
インフラなのに把握しきれていなかった無線LAN事情
ある朝、ネットワークが遅いと思いながら環境を立ち上げ、いつも通り作業を始めたところ、今まで落ちていた処理よりも進んだ所で止まっていました。
原因が全く分からないまま、現実逃避中の人間が”たまたま”と流しそうになったところである言葉がよぎります。
『現象には必ず理由がある。』 『あり得ない？あり得ないなんてことはあり得ない』
『忘れるな。君は一人じゃない。』
『この道を行けばどうなるものか。～迷わずいけよ、いけばわかるさ。 ありがと～。～ ダ～～～～～～～～～』
いつも繋いでいたインフラ管理用の無線SSIDとは違う、一般社員用のSSIDにつながっていたようでした。
当初はSSIDごとにアクセス制限があるのではないかと思っていましたが、調べてみても特別な設定は見当たりません。
自分の席からアクセスできるAPが混んでいて不安定だったのではないかと。。。
無線だと不安定
接続先のSSIDを変えてみたところ、構築まではできましたがあまりにも不安定過ぎて使えるものではありませんでした。
先に使用していないPCを有線LANに繋いで構築しておけばよかったのではないかという事も今となってはよい思い出です。
無線LANに繋いだPCだけでは不安定過ぎて使えない。 という結果をもって夢破れ挫折してしまいました。
挫折の先に。。。止まない雨が降る。。。
無線LANで安定しないなら無線ではない環境のクラウド上に構築することにしました。
日本の環境に来ないマネージドkubernetes
何度も言うようですが、主要なクラウドベンダではコンテナ管理サービスが提供されていますが、一部ベンダでは日本国内の環境では、まだ利用できません。
対応済みの環境でも手順書通りに作業しても動かない
日本以外に正式リリースされた地域でも公式の手順では動かなったりもします。
やはり唯一無二のRancher
Rancherは、マルチハイブリッドクラウド対応なので、社内で検証した時と同じ構成をクラウド上に作成しました。
クラウド上だと社内での検証時期が悪夢のように思われるくらいすんなりと構築できました。
独自dockerイメージと公開dockerイメージのはざま
kubernetes環境が構築できれば、あとはアプリケーションを入れたコンテナを配置していくだけです。
しかし、実際運用に入る為にはアプリケーション以外の表には見えていなかった部分が見えてきます。
- ログ収集＆ログ可視化
- リソース監視＆可視化
- kubernetesノードのOSテンプレート化 。。。。
他にも現在の運用方法と変わらないような仕組みが必要になります。
- branch毎に確認環境を構築
- リリース内容をチャットに通知
- dockerbuild、コンテナデプロイのタイミング
- マイグレーション 。。。。
独自にdockerイメージを作るべきか、要求に近い公開されているdockerイメージを使うべきか
- 独自dockerイメージ->要求は満たせるが運用管理が必要
- 公開dockerイメージ->運用管理は必要ないがカスタマイズするために環境を熟知する必要がある
揮発性のデメリット
コンテナ環境は再起動時に古い環境が残らず、常に同じ環境が出来るというメリットがある反面、ちょっとした変更もすべて設定ファイルなどに記載して再起動する必要があります。
dockerfileを独自に作成しても公開されている物を使っても、設定変更->再起動->変更反映確認を繰り返さなくてはいけません。
特に公開イメージを使用する場合は、個別に動きを把握しておかないと
”変えたはずの設定がなんだか上書きされて元に戻っている”
という事が起こります。
既存環境の闇
以前の記事でも書きましたが、運用が長いサービスは色々な物が積み重なって動いていたりします。
コンテナ環境に移行してみると動かないもの、今までと違う動きをするもの、そんなところにまだいたのかというもの、などなど目に見えていなかったものが、牙をむいてきたりします。
コンテナ関連のバージョン管理
コンテナ関連のプロジェクトはとても動きが早いです。
バグの改修、機能追加など一週間公式サイトを見ていないとバージョンが上がっていたりします。
稀に上位互換なくリリースされたりします。バージョンが混在してしまうと全く動かなくなったりします。
Rancherについては、RKEでインストールしていた場合、v2.1.0以降には更新できません。
（アナウンスされていたんだと思いますが、見落としていました）
静かにhelm chart版に移行しました。
止まない雨・・・を抜けると
現在、プロダクション環境の移行まではたどり着けていませんが、一部のテスト環境は移行できました。
コンテナ環境最大のメリット
- トライ・アンド・エラー
- ケース・バイ・ケース
- ヒット・アンド・ラン
を繰り返し下記のような構成になっています。
- manager：Rancher構築処理実行用環境
- Rancher：kubernetesクラスタ管理
- kubernetes：用途別クラスタ管理
- builderクラスタ：運用機能用クラスタ
- ChartMuseum：helm chart管理
- Drone：CI/CD（作業時はRancherのpipelineはjava関連の問題で動きませんでした）
- Grafana：リソース可視化
- development：branch別動作確認環境
- staging：リリース前確認環境
- builderクラスタ：運用機能用クラスタ
- Prometheus：リソース収集
- fluentd：ログ収集
- logsync：ログファイル退避（独自にdockerイメージを作成）
- Docker Registry：独自dockerイメージ管理
- elasticsearch & kibana：ログ可視化
GitLab：内部用
GitHub：GitLabをミラー＆Webhook
- Docker Hub：公開dockerイメージ
これから、プロダクション環境を移行する際にどんな構成になるのか。。。
おわりに
私のように「どっかー」「こんてな」＝「テスト環境」と思われている方がいれば一度クラウド環境で提供されている、コンテナ環境に触れてみてはいかがでしょうか。
今までの時間が「夢」の様な思い出になるかもしれません。
＊ ＊ ＊ ＊ ＊
ピクスタでは、夢にときめく！！エンジニアを募集しています。
