オンプレKubernetes(Rancher)環境でCD環境を組んでみた

CD環境を構成したい!

と、突然書いてみたわけですが、経緯を少し振り返ってみます。
経緯なんてどうでもいいという場合は読み飛ばしてください。

こちらで紹介したように、弊宅のオンプレ環境ではKubernetesのクラスタが動いています。
こちらのブログやポートフォリオが乗っている本番環境には、Rancherを使用していますが、更新のたびにデプロイ処理を行っていました。
また、コードはGithubで管理していますので、GithubへPush後、コンテナイメージを作成しローカルのコンテナレジストリにPushしたのち、Rancher側でのPodの更新が必要な状態でした。

そこで、今回は、GithubへPushした後の、コンテナイメージの作成・レジストリへのPush・デプロイまでを自動化してみます。

構成

ざっくり図にしてみると、こんな感じになりました。

Github上のmasterブランチへの変更の検知には、Webhookを使用しています。
当然、Webhookを使用していますので、Rancher自体にグローバルから到達可能である必要があります。
(Githubとの連携作業は、ローカルIPアドレスのみでも行うことが出来ますが、Webhookが機能しなくなります。その場合、Githubのリポジトリ設定からWebhookの宛先を修正してください。)
筆者は、少し変なことをしてWebhookのみグローバルからRancherに到達可能にしています。

コンテナイメージのビルドなどのフローは、Rancher自体が持つPipelineと呼ばれる仕組みを利用し、設定を行っています。
この設定は、RancherのWebGUI上から行うことが出来ます。
作成された設定ファイルは、(今回の場合はGithubに)pushされます。
なお、Pipelineの仕組み自体に、DockerRegistryをホストする機能がありますが、今回はすでにオンプレ環境でレジストリが存在するため、そちらを使用するようにしました。
もちろん、DockerHubなどのレジストリも設定可能です。
このPipelineとしての設定を記したファイルは、.rancher-pipeline.ymlとして保存されます。

デプロイでは、ワークロードの設定を記述したYAMLファイルを用意しておく必要があります。
すでにワークロードがデプロイされている場合には、Rancher上からこのYAMLファイルを取得する事が可能です。
しかし、デプロイ自体には不必要な情報が多く含まれているため、編集を行う必要があります。
内容自体は、当たり前ですが通常デプロイする際に記述するYAMLファイルと同様です。

なお、Kubernetesでは、コンテナイメージのタグが同一のまま(latestなど)configを更新しても、Podは更新されません。
そのため、 ${CICD_EXECUTION_SEQUENCE} などの変数を使用してコンテナイメージのタグを変化させる必要がある点、注意が必要です。
このタグは、クラスタにapplyされる前に置換が行われるため、クラスタにデプロイする際に使用するYAMLファイルにも記述することが出来ます。
つまり、コンテナイメージをビルドする際のタグと、クラスタへのデプロイに使用するYAMLファイル上のイメージタグに変数を使用することで、Podの更新を行うことが出来ます。

Rancher公式のサンプルをいくつか列挙しておきます。
pipeline-example-php
pipeline-example-maven
pipeline-example-go

例えば、ポートフォリオ.rancher-pipeline.ymlはこのような形になっています。
(レジストリのURLが混ざっているため、一部伏せています。)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
stages:
- name: DockerBuild
steps:
- publishImageConfig:
dockerfilePath: ./Dockerfile
buildContext: .
tag: <レジストリのアドレスやパス>/production/portfolio:${CICD_EXECUTION_SEQUENCE}
pushRemote: true
registry: <Rancher上で登録したRegistryの名称>
when:
event: {}
- name: Deploy
steps:
- applyYamlConfig:
path: ./deployment.yaml
timeout: 60
notification: {}

.rancher-pipeline.ymlにあるように、フローに失敗した場合や成功した場合に通知を行うこともできるようです。
これにより、デプロイまでのフローを自動化することが出来ました。

余談

そもそも自動化しようとしたきっかけは、業務でGithub Actionsを使用した自動化作業を行ったことでした。
そこで、手元でも本題にあるフローを自動化しようと思い立ったわけです。。
(結局Github Actionsを使用することなく構築しましたが…)

CI/CDについては今後、勉強して行きたいと思います。

リソースモニター bashtop を使ってみる

bashtop

bashtop は、CPUやメモリ・ディスク・ネットワークといったリソースの使用状況や、プロセス一覧などを確認できるCLIツールです。

同種のツールとして、 htop などが挙げられますが、 bashtop の特徴はより多くの情報を表示できる点です。

インストール方法などは、 bashtop のリポジトリをご確認ください。

実行してみる

シェルからコマンドを叩くだけです。

1
$ bashtop

調子に乗って32C64T環境で実行したからか、表示がずれていますね。

このような形で、CPU・メモリ・ディスクに加えて、プロセス一覧を見ることが出来、さらには、ネットワークの通信量も確認することが可能です。

htop の場合、CPUやメモリの使用状況を確認することは出来ますが、ネットワークの通信量を確認することが出来ませんでしたが、bashtop では、これらの情報を一括で表示できています。

以上、簡単にではありますが、 bashtop の紹介でした。

お家で始める仮想化環境 Proxmox VE 環境構築編

Proxmox VE とは

Proxmox VE とは、仮想化環境を提供するプラットフォームの1つです。
VM(Virtual Machine)などのホストとして使用できます。
似た目的の製品として、VMWare ESXiなどがあります。
こちらを利用されている方も多いのではないでしょうか。

Proxmox - powerful open-source server solutions
https://proxmox.com/

ちなみに、Proxmox VE は Proxmox Virtual Environment の略です。

筆者は1年以上 Proxmox VE を使用していますが、いずれも安定して動作しています。

Proxmox VE の特徴

大きな特徴として、VMWare ESXiと比較し、ライセンスフリーでほぼすべての機能を利用できる点が挙げられます。
無償版でも、VMWare ESXiのようにVMあたりのコア数の制限はありません。
また、複数のホストをクラスタリングしたり、HA環境、ライブマイグレーションといった機能も無償で利用することができます。
さらに、VMWare ESXiと同様にWebインタフェースを持っていますので、Webブラウザ経由で簡単に管理することができます。
Debianベースで開発されていますので、ホストOS上にRAIDコントローラのドライバなども簡単に導入することができるのも、利点といえるでしょう。
さらに、VMWare ESXiでは早期にCPUサポートが打ち切られるケースがありますが、Proxmox VEでは基本的にLinux Kernelが動作可能なモノであれば動かすことができます。
自宅などで古いハードウェアを利用する際には、有力な選択肢となるでしょう。

VM(Virtual Machine)やLXC(Linux Container)に対応します。

インストール準備

公式サイトより、Proxmox VE のISOイメージをダウンロードしてください。
2020年8月12日時点では、Proxmox VE 6.2 が最新でした。

容量は863MBとなっています。丁度Debianのイメージと同じぐらいですね。

イメージのダウンロードが完了したら、balenaEtcherやddコマンドを利用して、適当なUSBメモリにダウンロードしたイメージを書き込んでください。
ここでは、書き込み手順については省略します。

イメージの書き込みが完了したら、準備は完了です。

インストール

仮想化環境の役割を与えるマシンを用意します。
今回は、以下のマシンを使用しています。
(AMD CPUを使用していますが、既存環境はIntel CPU上でProxmox VEを運用しており、手順に差が無いことを確認しています。)

パーツ 詳細
CPU AMD EPYC 7452 32Core Processor
M/B Supermicro H11SSL-i (Rev2.0)
Memory DDR4 ECC Registered 128GB

なお、利用するマシンのBIOSにて、CPU Virtualizationサポートを有効化しておきます。
Intel CPUの場合はVT-dなど、AMD CPUの場合はSVM Modeなどです。

これらの準備が完了すれば、先ほど作成したUSBメモリをマシンへ接続し、USBからブートします。
以下のような Welcome to Proxmox Virtual Environment と書かれた画面が表示されます

今回は普通にインストールしますので、「Install Proxmox VE」を選択します。
ブートログが流れたのち、以下のようなライセンス同意画面が表示されますので、ライセンスを読み問題が無ければ右下の「I agree」を押します。
なお、これらの操作はキーボードでもマウスでも操作可能です。

同意すると、インストールするターゲットディスクの選択画面が現れます。

今回は /dev/sda にデフォルトの ext4 でインストールします。
ソフトウェアRAIDを構成することも可能ですので、必要に応じてオプションを変更します。

続いて、国やタイムゾーン、キーボードレイアウトなどの設定です。
ここも各自必要に応じて設定します。

続いて、パスワードとE-Mailの設定です。
パスワードは、rootユーザーのパスワードになります。E-Mailも合わせて適時設定します。

続いて、ネットワーク周りの設定です。
ここでは、管理用ネットワークについて設定を行います。
管理用ネットワークとして利用するインタフェースとHostname・IPアドレス等を適切に設定します。

最後に、確認画面が表示されますので、設定に問題が無ければ「Install」を選択し、インストールを開始します。

インストール処理が行われますので、終了するまで待ちます。

インストールが完了すると、右下に「Reboot」と表示されますので、指示に従って再起動します。
なお、再起動中に、インストールに使用したUSBメモリは外しておきます。

再起動が完了すると、Proxmoxの起動メニューが表示されますが、選択しなければ通常起動されます。

起動が完了すると、Webインターフェースへアクセスするための情報(URL)が表示されますので、指示に従ってブラウザからアクセスします。
なお、今回は https://192.168.2.133:8006/ となっています。
(インストール時に設定した管理ネットワークのIPアドレスが使用されます)

ブラウザからWebインタフェースへアクセスすると、SSLエラーが出ますが、自己証明書を使用している為に表示されているだけですので、そのままアクセスを続行します。
ログインを求められますので、インストール時に設定したパスワードなどを使用してログインします。
(ユーザー名のデフォルトは root です。)
言語なども必要に応じて変更します。

ログインすると、「No valid subscription」といったダイアログが表示されますが、そのまま「OK」を押して続行します。
無償版を使用していると表示されますが、無償版のデメリットはこのダイアログが表示されるぐらいなので、我慢しましょう。

以上で基本的な手順でのインストールは完了です。

無償版リポジトリを設定する

インストール直後の初期状態では、有償版のリポジトリが設定されているため、アップデートなどを行うことができません。
そこで、無償版のリポジトリを設定する必要があります。

Webインターフェースから Proxmox 自体のシェルへアクセス可能なので、そちらから設定を行います。
(もちろん、SSHでのアクセスも可能ですので、お好みの方法で設定を行ってください。)
左側のサイドバーからホストを選択します。今回は「test」となっています。
その後、右上のShellからお好きな方法で接続してください。
今回はコピー&ペーストが使用可能な「xterm.js」を使用します。

起動が完了したら、こちらを参考にリポジトリの設定を変更します。

/etc/apt/sources.list に無償版のリポジトリを追加

1
2
# PVE pve-no-subscription repository provided by proxmox.com, NOT recommended for production use
deb http://download.proxmox.com/debian stretch pve-no-subscription

/etc/apt/sources.list.d/pve-enterprise.list から有償版リポジトリを無効化
(ここではコメントアウトしています)

1
# deb https://enterprise.proxmox.com/debian stretch pve-enterprise

以上の変更操作が完了したら、アップデートを行います。
アップデートを行うには、2つの方法があります
1、このままシェルからアップデートを行う。
2、Webインタフェースから行う。

1、このままシェルからアップデートを行う。
Proxmox VE はDebianをベースにしていますので、パッケージマネージャとして apt が使用されています。

1
apt update && apt upgrade -y && apt dist-upgrade -y

2、Webインタフェースから行う。
Webインタフェースで、ホストを選択して「Updates」を開きます。
(画像の赤線部)

更新があるか確認する必要があるので、左上の「Refresh」を押し、パッケージの更新有無を確認します。
「No valid ・・・」ダイアログが出たのち、ログが出ますので、「Task OK」と表示されたら閉じます。
先ほどの画面に、更新のあるパッケージリストが表示されているはずです。

続いて、先ほどのボタンの右側「Upgrade」を押します。
シェルが開いて、Do you want to continue? [Y/n]と聞いてきますので、問題がなければyを入力して続行します。
こちらも、処理が完了したら閉じてOKです。

以上で、パッケージのアップデートが出来るようになりました。

Summary

ネットワークの設定は、ホストを選択した状態で、「Network」から行うことができます。
ストレージの設定は左側のツリートップの「Datacenter」を選択した状態で「Storage」から行うことができます。
ホストごとに設定すると思ってホストを選択した状態でストレージ設定を探してしまうので、注意が必要です。

ISOイメージをアップロードする

VMの作成などに使用するISOイメージのアップロードを行います。
Webインタフェース左側のツリーから「local」を選択します。(対象のストレージを選択しています。)
「Content」から「Upload」を押し、アップロードしたいイメージを選択して「Upload」を押します。

簡単にISOイメージなどをアップロードすることができます。

VMを作成してみる

試してにVM(Virtual Machine)を作成してみます。
Webインタフェース右上から「Create VM」を選択します。

VMを作成するホスト(Node)やID、名前を設定します。

続いて、インストールに使用するISOイメージや、GuestOSの選択を行います。
今回はUbuntu20.04.1を使用するので、以下のように設定しています。

「System」タブは、VMを作成してみるだけなら特に設定する必要はありません。

「Hard Disk」タブでは、ゲストOSが使用するストレージの設定を行います。
保存先やサイズなどを設定します。

「CPU」「Memory」では、ゲストOSに割くリソース量を設定することができます。
ホストOSの持つリソース量を超えないように設定します。

「Network」では、VMに割り当てるbridgeインタフェースの設定をします。初期設定のままだと「vmbr0」しか存在しないので、今回はそれを選択しておきます。
必要に応じて変更してください。

「Confirm」では確認画面が表示されますので、問題が無ければダイアログ右下の「Finish」を押します。

VMの作成が完了すると、Webインタフェース左側のツリーに作成したVMが表示されます。

作成したVMを選択し、右上の「Start」を押すとVMが立ち上がります。
「Console」を押すことでコンソールにアクセス可能です。

コンソールにアクセスすると、VMが立ち上がっているはずです。
(今回はVM上でのOSインストールは行いません)

まとめ

今回は、Proxmox VEの初期セットアップ方法について書いて見ました。
多くの人がVMWare ESXiを使用する中で、Proxmox VEは無償版での機能制限がほぼないのが魅力です。
さらに、VMWare ESXiは早期にCPUサポートをやめますが、Proxmox VEでは基本的にLinux Kernelが動作するCPUであれば利用できます。
自宅などで古いハードウェア上で利用したい場合には大きなメリットとなるでしょう。

今回は初期セットアップ方法のみの解説でした。
ストレージやネットワーク周りの設定、クラスタリングなどについても、需要がありそうであれば書いてみたいと思います。