GMOインターネットの新卒3年目エンジニアに『イベント企画』を持ちかけた謎の老人がいた。イベント企画を通じてOpenStackの管理者としてそこそこな経験が得られる魔法の企画。新卒3年目エンジニアが企画を頑張りますと言った次の瞬間、その身に絶大な力が宿るのを感じた。彼は喜んでボタンを押した――押してしまった。
概要
CloudNative Days Tokyo 2019 / OpenStack Days Tokyo 2019ではGMOインターネットがダイアモンドスポンサーにて協賛・出展することとなりました。
GMOインターネットブースではGMOインターネット新卒3年目 VS GMOペパボ プリンシパルエンジニア『OpenStack バージョンアップ対決』と題して会期の2日間をかけて、チャレンジャー2名がOcata からPikeへのアップデートをどちらがより早く多く行えるかについて競っていました。それらの振り返りブログです。
このブログには運用知見など一切含まれず、イベント完遂の為の準備と当日の様子、あと翌日の疲れからくる悪ノリで構成されています。
私について
GMOインターネット新卒3年目でインフラエンジニアをしているnwiizoです。日頃は筋力トレーニングをしておりOpenStackの運用に関しての知識は皆無です。
準備編
構築について
最初はパッケージを用いて自前で構築しようとしましたが、再現性や工数の問題で諸々の設定とかめんどうだな～という感情が強くて、DevStackとPackstackに候補を絞り、最終的にDevStackを使いましたが・・・これが当日の地獄を生み出すとはこの時には思っていませんでした。
構築について
ConoHa VPSの8GB/CPU 6Core CentOS Linux release 7.6 LTSを利用しました。
IPv6無効化
$ sysctl -w net.ipv6.conf.all.disable_ipv6=1
$ sysctl -w net.ipv6.conf.default.disable_ipv6=1ユーザーの追加及び変更
$ useradd -s /bin/bash -d /opt/stack -m stack
$ echo "stack ALL=(ALL) NOPASSWD: ALL" | tee /etc/sudoers.d/stack
$ su - stackdevstackのインストール及び実行によるOcataのインストール
リポジトリのCloneと設定ファイルの変更
$ git clone https://github.com/openstack-dev/devstack.git -b stable/ocata devstack/
$ cd devstack/設定ファイルの配置を外部IPに設定していくれい
$ cat local.conf
[[local|localrc]]
ADMIN_PASSWORD=secret
DATABASE_PASSWORD=\$ADMIN_PASSWORD
RABBIT_PASSWORD=\$ADMIN_PASSWORD
SERVICE_PASSWORD=\$ADMIN_PASSWORD
HOST_IP=<vm-external-ip>
RECLONE=yes
実行
設定ファイルを適切に設定したら実行します。
$ FORCE=yes ./stack.sh監視について
バージョンアップに疲弊していたので会場で表示させることを忘れていたのですが()、今回、監視サーバーにはPrometheusを利用しました。Prometheusは2012年に始まり、2016年7月にバージョン1.0がリリースされた、音楽共有サービスを手がけるSoundCloudが開発したもので、現在は独立したプロジェクトとしてLinux Foundationのクラウド関連オープンソースプロジェクト”Cloud Native Computing Foundation”の支援の下活発な開発が続けられており、2017年11月9日にはメジャーアップデート版となるバージョン2.0がリリースされ、2018年9月にはCloud Native Computing Foundation Announces Prometheus Graduationが発表されました。そのほかにも、ここ最近ではThanosのようなプロダクトも登場しており現在進行形で進化しているプロダクトです。世界的にはPromConが開催されていたり日本にもPrometheus Tokyoというコミュニティが存在しています。Prometheus は、 Borgmon にインスパイアされて作成されたものです。SRE 本には Borgmon の遺伝子を継いだ OSS としてこの Prometheus が紹介されています。なので、SRE 本のMonitoring Distributed SystemsやPractical Alerting from Time-Series Dataを一読すると、使い方のイメージが付くのではないかと思います。
今回はConoHa で構築している自前のKubernetes環境に、kube-prometheus及びprometheus-operatorを用いて監視サーバーを置いていました。Exporterに関しては本当はprometheus-openstack-exporter とprometheus-operator をカッコよく自動的に監視したかったのですが、諸々頑張ってみたのですがうまくいきませんでしたので、エンドポイントの監視だけでも一旦、監視としてはいいか(イベントだし)と思って、エンドポイントの監視に関してはblackbox_exporterを使いました。
最小限のインストール
$ git clone https://github.com/coreos/kube-prometheus
$ git clone https://github.com/coreos/prometheus-operator
$ kubectl create -f kube-prometheus/manifests/
$ kubectl apply -f prometheus-operator/bundle.yaml
Operator について
Kubernetes Operator
Kubernetes OperatorはCoreOSによって2016年に提唱された概念で、Kubernetes Operators やIntroducing Operators: Putting Operational Knowledge into Softwareで詳細が紹介されており、Operatorを作成するフレームワークも公開されてIntroducing the Operator Framework: Building Apps on KubernetesやThe Operator Metering project is now available で紹介されています。CNDT2019でも多くのセッションで紹介されていました。簡単に説明すると、複雑になりがちなStatefulアプリケーションの運用を自動化することがOperatorの目的です。Battle Conference Under30のインフラエンジニアの為のソフトウェア開発手法入門という発表でも一部言及いたしましたが、Statefulなアプリケーションを正しく運用するにはアプリケーション固有の運用知見が必要になり、スペシャリストによる技芸が必要になってきます。こういったアプリケーション固有の運用を人間の手によって技芸で解決し続けることは非常にコストが高い為、運用知見をコード化してKubernetes上でやっていこうというのがベースな考え方になります。OperatorHub.ioなどがあり様々な人が書いたOperatorを見ることもできます。
Kubernetes 内では宣言的な設定を実現する為に、理想の状態であるDesired Stateと現在の状態であるActual Stateを一致・更新させる処理のループを回しており、これをReconciliation loopと呼びます。詳しくはKubernetes Control PlaneやManaging Kubernetesなどで紹介されているので、読んでみてください。StatelessなアプリケーションであればKubernetesの既存のDeployments等で理想の状態を定義してあげれば、ある程度は実用レベルの運用が可能といえます。しかし、上記でも記載した通りStatefulなアプリケーションはより複雑な運用タスクが必要であり、アプリケーション毎に最適な運用方法は異なりそれらを宣言的な設定で実現するためにはOperatorは必要になります。
Operatorは Custom Resource と Costom Controller から成り立ちます。Custom ResourceをKubernetes上に作成するには CRD (CustomResourceDefinition) という機能を利用します。CRDに独自の理想の状態を定義してKubernetes上に登録することで、Custom Resourceの利用が可能になります。Custom ControllerはどのようにCurrent StateとDesired Stateを一致させるかを担います。つまり、Custom Resourceに定義されたDesired Stateを実現するのがCustom Controllerであり、これらをまとめて、Operatorと呼びます。また、
実際にOperatorを作ってみたいと思った場合には、Programming Kubernetesなどが書籍としては販売されたので一読するのもありかもしれません。
prometheus-operatorについて
prometheus-operator はKubernetesの簡単な監視定義、およびPrometheusインスタンスのSeamlessなアップグレード及び展開と管理を提供します。Issueとして挙がっている機能は、それ以外にもベータ版であるので今後に期待です。これも別途記事で紹介したいと思っているのですが、ここでも簡単に紹介しておきます。
機能
- Kubernetesの名前空間、特定のアプリケーション、チームの専用のPrometheusインスタンスをOperatorを使って簡単に起動できる。
- Kubernetesリソースからのバージョン、永続性、保存ポリシー、レプリカなどのPrometheusの基本を設定してくれる。
- Kubernetesラベルクエリに基づいて監視ターゲット設定を自動的に生成してくれるので、プロメテウス特有の設定言語を学ぶ必要がない。
Other Supported Features
- 高可用性
- 自動でのupdate
- コンテナの動的な性質を処理
Custom Resource Definitions
主にはPrometheus Prometheus Rule Service Monitor Alertmanagerなどがあり、各々が様々なことをしてくれるのですが今回は割愛。
最後に
『イベント企画を頷いた俺は、気付いたらバージョンアップでつかれていた 前日編 』 を最後まで読んでくださってありがとうございます。これらの情報がいつかの皆様の一助となればよいと思います。
当日編ではOpenStackのバージョンアップについてと、当日何をしていたのか記載していこうと思います。
