IaCいいですよね。
なのでこの記事ではTerraform-provider-esxiを使って、おうちESXIをTerraformで管理してVMを立ち上げ、cloud-initを活用してTeleportを自動セットアップします。 子ノードを作成して接続まで一応するのですが、Teleportはノードの接続にinviteトークンを発行する必要があり、そこだけ自動化できていません。(今後の課題)
Terraformについては過去の記事GithubActions + TerraformでAWS開発を、TeleportについてはDockerでお手軽にTeleportを試すも参考にしてください。
terraform-provider-esxi
terraformはproviderと呼ばれるいわゆるプラグインを用いて、様々なサービス等と接続できます。 今回はterraform-provider-esxiという有志の方が作ってくれているproviderを使います。 ミニマムにまとまっていて使いやすいのですが、安定性はちょっと微妙かもしれないです。趣味なら全然使えるという感じですね。
hashicorp社が公式に出しているvsphere-providerというのもあって、vsphere越しにESXIを使えて良さげなのですがそもそもvsphereはすごいお値段がするので個人で所有するのはちょっと…という感じですね。 このproviderで、vsphere抜きにしてESXIだけ触れたら超最高なのですが、そう上手くはいかないですね。
この記事ではコードの断片的な部分しか載せていないので最終形はGithubのレポジトリを参照してください。
前準備
ESXIがインストールされたマシンはもちろんとして、ホストsshが有効になっている必要があります。
とりあえずVMを起動
自分でosをインストールするのは大変すぎるのでOVAファイルをもとにセットアップします。
ubuntuのOVAファイルはUbuntu Cloud Imagesから手に入ります。ダウンロードしてmain.tfと同じディレクトリに入れておいてください。
main.tfファイルと、tfvarsファイルを作ります(一応)。
|
|
|
|
特に私がハマったのは、virthwver (仮想マシンのハードウェアバージョン)のデフォルトが、自分が使っているESXIが対応していないバージョンだった為に 変なところでterraformのapplyが失敗してしまって、tfstateとの動機が切れてしまうという問題です。きっちり指定してあげましょう。
できたら、初回のterraform initをして、その後plan, applyと進みます。
また、plan, applyでは作成したtfvarsを、--var-file vars.tfvars
と指定してあげます。
applyしてもりもり処理が走って、
|
|
と表示されれば成功です!
cloud-initでユーザー作成
前章で無事VMが作成できたのはいいのですが、まずsshはできませんし、esxiのclientのコンソールでもログインプロンプトはでてるものの何を入れたらいいかわからないかと思います。だって設定してないですし。
というわけでcloud-initを使って設定していきます。
cloud-initはyaml形式でサーバーの初期設定をする仕組みです。
ユーザーとか、インストールパッケージとか、実行するコマンドとか、様々な実行項目が「モジュール」として定義されていて、モジュール単位で設定をぐるぐる練っていく感じです。 モジュール一覧は公式ドキュメントを見てください。
まずは設定を読み込む部分をtfファイルに書きます
|
|
terraformではfile関数で外部のファイルの文字列を取り込めます。便利。
では本体のcloud-init.yamlを作ります。
|
|
先頭の#cloud-configが超重要です!!!
cloud-initはシェルスクリプトかcloud-init形式か選べて、先頭にこのコメントがあれば後者になるという仕組みです。 これをtypoしてるとうまくいきません。気をつけてください。
あと、大変申し訳無いのですが以後でてくるcloud-init.yamlは全部抜粋なのでこの行を省きます。この説明を見落とされないことを願います。
lock_passwdのデフォルト値はtrueなので、デフォルトだとパスワードログインができないところが注意ですね。
これで再度terraform applyすれば自動的にVMが 再生成 されます。((以前のは強制的に消されちゃいます) これでターミナルでパスワードログインしたり、sshで接続できたりするはずです(IPは頑張って調べてください)。
IP固定
サーバーとして使うならIPを固定したいですよね。 ネットワーク関連の設定は公式ドキュメントのここになります。
でもって、これらの設定はuserdataとは別枠で設定することになります。さっきcloud-init.yamlを追加したノリでmeta.yamlを追加します。
|
|
|
|
でもって例によってterraform applyすれば再生成されて指定したIPで新しく生まれてくるはずです。
teleportをセットアップ
ではteleportをインストールしていきましてよ。
基本的にパッケージをインストールするのは、packageモジュールにパッケージ名を列挙するだけなんですけど、teleportは独自のレポジトリを追加する必要があるのでひと手間かかります。
順を追って説明します。
レポジトリを追加
keyidにfigerprintを入力するところ以外は普通ですね
|
|
パッケージのインストール
他にもインストールしたいパッケージがあればここに追加できます。
|
|
自動起動の設定
自動起動を設定して初回起動も入れます。
|
|
類似モジュールにbootcmdというのもありますが、runcmdがセットアップ時に1度だけ、処理の最後の方で実行されるのに対し、bootcmdは処理の最初の方に、毎起動時実行されるコマンドになります。
上記3つの設定を加えてterraform applyしたらteleportが立ち上がってるはずです。
configファイルの流し込み
teleport用の設定ファイルをサーバーに入れたいですよね。 ただyamlで外部ファイルをincludeできないのでyamlに直接埋め込む形にはなります… これはなんとかしたいですね。
|
|
これで/etc/teleport.yamlにファイルを作成できます。
恒久ストレージを追加
今までの方法でteleportをセットアップできますが、いかんせんimmutable infrastructureって感じで設定を変更するとサーバーが再作成されちゃうので、永続性がないですよね(それが狙いではあるのですが)。
ここで、OSの入っているメインストレージの他にサブのストレージを入れて、永続化したい情報はそっちを向くようにします。
まずはmain.tfでストレージリソースを作成し、vmに接続します。
|
|
でもって、cloud-initでディスクの認識・フォーマット・マウントを行います。
|
|
でもってteleportのコンフィグファイルのdatadirの項目が/persistentを向くようにすれば、何度破壊されても同じ認証情報でログインできるはずです。
この状態で、tctl tokens add –type=nodeして、inviteトークンを生成してメモっておきます。(ついでにca-pinも)
子ノードとの接続(問題あり)
今までと同じ要領でリソース・cloud-initのファイルを作成してteleportの子ノードを作成します。 teleportの設定にauth_servers, auth_token, ca_pinを追記すれば自動的にクラスターに参加します。
|
|
ただinviteトークンの発行は手動でしたし、トークンにも有効期限があるのであんまりイカした方法とは呼べないですよね…
たぶんteleportにこの辺を柔軟にするAPIがないので、自分でコマンドを自動で叩いてくれるシステムを追加するか…という感じです。
記事の最初にも書きましたが見逃しちゃった人のためにもう一度… この記事ではコードの断片的な部分しか載せていないので最終形はGithubのレポジトリを参照してください。
今後
cloud-initはシンプルにまとまってて便利ではあるものの、これでサーバー全部構築できるかというとだいぶ無理がありますよね…普通にchefとか使いたい感じです。
cloud-initにはchefを呼び出す機能自体はあるのですが、ていうかchefはそもそも有料になってしまったのでCINCを使いたいですし、CINC Serverを用意して管理して…というのもちょっとめんどくさいです。
もうちょっと良げなプロビジョニング手法を探そうと思います。