インスタンスのライフサイクルを管理してみた！

2023年12月18日 Oracle Cloud

1 １０インスタンスのライフサイクル管理を試してみました
2 検証の流れ
- 2.1 検証の流れ
- 2.2 前提条件
3 検証開始
4 おわりに

１０インスタンスのライフサイクル管理を試してみました

みなさま、こんにちは。
Oracle Cloud Infrastructure 検証チームです。

今回は、OCIの入門チュートリアルにもある
「インスタンスのライフサイクルを管理する」を検証してみました。

いつでも簡単に起動・停止、終了・再作成ができるインスタンスの動作や状態を確認していきます。

Oracle Cloud Infrastructure 検証チームの過去記事はこちら！

検証の流れ

今回は以下のような流れで検証していきます。

ブート・ボリューム内にファイルを作成する
インスタンスを停止する
インスタンスを起動する
インスタンスを終了する
ブート・ボリュームからインスタンスを再作成する

前提条件

前提条件は以下の通りです。

コンピュート・インスタンスの作成が完了していること
ブロック・ボリュームのアタッチが完了していること

検証開始

それでは早速検証を始めていきます！

ブート・ボリューム内にファイルを作成する

まずは、インスタンスのライフサイクル操作によるブート・ボリュームの影響をわかりやすくするために、
ファイルを作成します。

Tera Term等のsshターミナルを開き、あらかじめ作成していたインスタンスにsshで接続します。

ホームディレクトリにファイルを作成します。

[opc@test-vm ~]$ pwd
/home/opc
[opc@test-vm ~]$ touch testfile
[opc@test-vm ~]$ ls -l
total 0
-rw-rw-r--. 1 opc opc 0 Sep  7 04:22 testfile

インスタンスを停止する

次にコンソールからインスタンスを停止し、リソースの挙動などを確認していきます。

Oracle Cloudのコンソールメニューから[コンピュート]-[インスタンス]を選択し、
あらかじめ作成したインスタンスをクリックします。
インスタンスの詳細画面にある[停止]ボタンをクリックします。
メッセージダイアログ内の[インスタンスの停止]ボタンをクリックします。
インスタンスのステータスが停止中になり、しばらく経つと停止済に変わります。
ステータスが停止済に変わりました。先程接続していたTera Termの接続が切断されていることも確認できます。
停止済になったインスタンスの状態をコンソールから確認します。
特に以下の点について確認していきます。
- インスタンス停止後も起動時と同じIPアドレスが確保されているか
- あらかじめアタッチしていたブロック・ボリュームが引き続きアタッチされているか
- ブート・ボリュームが引き続きアタッチされているか
下の図から、インスタンス起動時も停止時も同じIPアドレスが確保されていることが分かります。

停止後もブロック・ボリュームがアタッチされていることが分かります。

ブート・ボリュームも引き続きアタッチされていることが分かります。

インスタンスを停止すると、ssh接続は切断されますが、IPアドレスは引き続き確保され、ブロック・ボリュームやブート・ボリュームはアタッチされ続けることが分かりました。

インスタンスを起動する

次に先程停止したインスタンスを起動し、リソースの挙動などを確認していきます。

インスタンスの詳細画面にある[起動]ボタンをクリックします。
しばらく経つと、インスタンスのステータスが実行中に変わります。
sshターミナルからopcユーザーでログインし、先程作成したブート・ボリュームのファイルを確認します。
```
[opc@test-vm ~]$ [opc@test-vm ~]$ ls -l
total 0
-rw-rw-r--. 1 opc opc 0 Sep  7 04:22 testfile
[opc@test-vm ~]$ pwd
/home/opc
```
インスタンスの起動停止を行っても、ブート・ボリュームに対する変更が保持されていることが分かります。

以下のコマンドを実行し、アタッチされているボリュームの情報を確認します。

[opc@test-vm ~]$ lsblk
NAME               MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda                  8:0    0 46.6G  0 disk
tqsda1               8:1    0  100M  0 part /boot/efi
tqsda2               8:2    0    1G  0 part /boot
mqsda3               8:3    0 45.5G  0 part
tqocivolume-root 252:0    0 35.5G  0 lvm  /
mqocivolume-oled 252:1    0   10G  0 lvm  /var/oled
sdb                  8:16   0   50G  0 disk

sdbというボリュームは、追加でアタッチし、OSからiSCSIでログインしたものです。
上記の結果から、インスタンスの起動停止を行ってもブロック・ボリュームへのiSCSIのログインが継続していることが分かります。

インスタンスを終了する

次にインスタンスを終了（削除）し、リソースの挙動などを確認していきます。

インスタンスの詳細画面にある[終了]ボタンをクリックします。
メッセージダイアログ内の[インスタンスの終了]をクリックします。
チェックボックスにチェックは入れません。
インスタンスのステータスが終了中になり、アタッチしているブロック・ボリュームやブート・ボリュームなどがデタッチ・削除されます。
ブート・ボリュームは先程「アタッチされたブート・ボリュームを完全に削除」にチェックを入れていなかったため、デタッチされただけで削除されていないことが分かります。インスタンスのステータスが停止済に変わりました。
IPアドレスや仮想クラウド・ネットワークの欄から値が消えていることが分かります。
終了済のインスタンスの課金は停止されますが、残されたブート・ボリュームの課金は継続されます。

ブート・ボリュームからインスタンスを再作成する

最後に、先程残しておいたブート・ボリュームから新しいインスタンスを作成してみます。

コンソールメニューから[ストレージ]-[ブロック・ボリューム]-[ブート・ボリューム]を選択します。
先程削除したインスタンスのブート・ボリュームをクリックし、ブート・ボリュームの詳細画面の
[インスタンスの作成]ボタンをクリックします。
コンピュート・インスタンスの作成ウィザードから新しいコンピュート・インスタンスを作成します。可用性ドメインは削除したインスタンスが存在した場所と同じものを選ぶようにします。
その他の項目は任意でOKです。
入力が完了したら下にある[作成]ボタンをクリックします。
しばらく経つとインスタンス作成が完了し、ステータスがプロビジョニング中から実行中に
変わります。
インスタンスに新しく割り振られたパブリックIPアドレスをコピーします。
パブリックIPアドレスに対してsshでアクセスし、先程作成した「testfile」が存在することを
確認します。