カテゴリー
2023年 Cron Linux LPIC コマンド コンピューター 技術一般 自動化

Linux の Cron の基本的な使い方

PVアクセスランキング にほんブログ村 にほんブログ村 ブログブログへ
にほんブログ村

こんなことしたいと思ったりしませんか?

  • 毎日、ある時間にプログラムを実行したい。
  • 一時間に一回、コマンドを実行したい。
  • 毎月一度、バックアップを取りたい。

Linuxには、定期的にコマンドを実行するために cron と呼ばれるデーモンプロセスがあります。これを使うと、決まった時間にコマンドを実行させたりすることができて便利です。

今回は、Cron(クーロン)の基本的な使い方をまとめてみます。

cron は、「crond(デーモン)」と「crontab」 で構成されます。1分ごとに crond が起動され、crontab ファイルに定義されたスケジュールを調べて、そこに実行すべきジョブがあれば実行します。

スケジューリングの編集は、以下の2つの方法で行えます。

  • crontabコマンド を利用する
  • /etc/crontab に書き込む

今回は、Crontab に定義を書き込む形で設定していきます。

Crond が動いているか確認

まず、使用しているシステムで、Cronデーモンが動作している必要があります。

「systemctl status <デーモンの名前>」コマンドを使って確認します。

kkint@ubuntu:/etc$ systemctl status cron.service
● cron.service - Regular background program processing daemon
Loaded: loaded (/lib/systemd/system/cron.service; enabled; vendor preset: enabled)
Active: active (running) since Fri 2023-10-06 12:01:47 JST; 3 days ago
Docs: man:cron(8)
Main PID: 985 (cron)
Tasks: 1 (limit: 4555)
Memory: 1.3M
CPU: 841ms
CGroup: /system.slice/cron.service
└─985 /usr/sbin/cron -f -P

Crond が動いていれば、上記のように「active(running)」の表示が出ます。

もし動いていない場合は、以下のコマンドで起動できます。

systemctl start cron.service

Crontab で設定

「/etc/crontab」ファイルに書き込む方法での設定手順です。まずは、Crontab ファイルを開いて見て見ましょう。

cat /etc/crontab

「cat」コマンドで、Crontab ファイルを指定して開いてみます。

kkint@ubuntu:/etc$ cat /etc/crontab

/etc/crontab: system-wide crontab

Unlike any other crontab you don't have to run the `crontab'

command to install the new version when you edit this file

and files in /etc/cron.d. These files also have username fields,

that none of the other crontabs do.

SHELL=/bin/sh

You can also override PATH, but by default, newer versions inherit it from the environment

PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

Example of job definition:

.---------------- minute (0 - 59)

| .------------- hour (0 - 23)

| | .---------- day of month (1 - 31)

| | | .------- month (1 - 12) OR jan,feb,mar,apr …

| | | | .---- day of week (0 - 6) (Sunday=0 or 7) OR sun,mon,tue,wed,thu,fri,sat

| | | | |

* * * * * user-name command to be executed

17 * * * * root cd / && run-parts --report /etc/cron.hourly
25 6 * * * root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
47 6 * * 7 root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly )
52 6 1 * * root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.monthly )
#
kkint@ubuntu:/etc$

下の方に、「*」が 5つ並んでいる行が見えますね。ここに定義を記入していきます。

この「*」印ですが、左から順に「分、時、日、月、曜日、実行ユーザー、 実行するコマンド」となっています。
時間は24時間で表記をします。

指定できる値は、下記のようになります。

指定対象指定範囲
0〜59
0〜23
1〜31
1〜12 または jan〜dec
曜日0〜7 または sun〜sat

「分 時 日 月 曜日 ユーザー コマンド」の順に記入していきます。

< 記述例 >

1時に実行

  • 1 * * * [ユーザー] [コマンド]

13時に実行

  • 13 * * * [ユーザー] [コマンド]

5分おきに実行

*/5 * * * * [ユーザー] [コマンド]

1時、2時、5時、6時、7時、8時に実行

  • 1,2,5-8 * * * [ユーザー] [コマンド]

もう少し例を見ていきましょう。

kkint というユーザー権限で実行し、kkint ユーザーのデスクトップに test.txt を作成する例です。

1分ごとに実行

* * * * * kkint touch /home/kkint/Desktop/test.txt

1:00 – 1:59 まで1分ごとに実行

* 1 * * * kkint touch /home/kkint/Desktop/test.txt

毎日14:00 に実行

0 14 * * * kkint touch /home/kkint/Desktop/test.txt

毎月10日から20日の 00:00 に実行

0 0 10-20 * * kkint touch /home/kkint/Desktop/test.txt

毎週月曜日から金曜日の 13:00 に実行

0 13 * * 1-5 kkint touch /home/kkint/Desktop/test.txt

Cron のログを出力する

デフォルトでは、Cron のログは出力されないようになっていますが、これを出力するようにすると、動作確認の際に便利です。

「/etc/rsyslog.d/50-default.conf」ファイルの設定を変更します。

kkint@ubuntu:/etc$ cat /etc/rsyslog.d/50-default.conf | grep cron

#cron.* /var/log/cron.log  <<<<< この部分

cron,daemon.none;\

まず、vim などのエディターを使って、上記ファイルを開きます。

$ vim /etc/rsyslog.d/50-default.conf

次に、対象の部分のコメントを外します。

#cron.* /var/log/cron.log
        |
        *
cron.* /var/log/cron.log  <<<<< コメントアウトする

最後に、rsyslogを再起動して、変更を適用します。

$ sudo service rsyslog restart

ログの確認例

2分おきに df コマンドを実行し、その結果をテキストファイルに書き込み、デスクトップに保存した時のログの出力は、以下の通りです。

Crontab ファイルには、以下のように記載しています。

*/2 * * * * kkint /usr/bin/df -h > /home/kkint/Desktop/df_results.txt

ログを見ると、指定したコマンドが実行されているのが分かりますね。

kkint@ubuntu:/etc$ cat /var/log/cron.log
Oct 9 13:45:01 ubuntu CRON[9087]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1)
Oct 9 13:55:01 ubuntu CRON[9164]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1)
Oct 9 14:01:01 ubuntu cron[985]: (system) RELOAD (/etc/crontab)

Oct 9 14:45:01 ubuntu CRON[10567]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1)
Oct 9 14:46:01 ubuntu CRON[10575]: (kkint) CMD (/usr/bin/df -h >> /home/kkint/Desktop/df_results)
Oct 9 14:46:01 ubuntu CRON[10576]: (kkint) CMD (date >> /home/kkint/Desktop/df_results)

面白かったら、フォローしてください!

世の中には楽しいことがいっぱい - にほんブログ村

関連するブログ:

最近の人気ブログ TOP 10:

最近の記事:

カテゴリー
2022年 Apple ガジェット コンピューター バックアップ 自動化

MacOS の Time Machine がうざいので設定を変えたい

PVアクセスランキング にほんブログ村 にほんブログ村 ブログブログへ
にほんブログ村

MacOS に標準で搭載されているバックアップアプリに、「Time Machine」があります。

標準で付いてくるアプリなのですが、必要最小限の機能はちゃんと搭載されており、非常に便利なアプリです。バックアップは、ちゃんと取っておかないと、何かあった時に泣くのは自分ですからね。

でもこのアプリ、やり過ぎなんです。1時間に一度バックアップを走らせてます。昼間に仕事している時にでもバックアップが走ります。かといって、自動バックアップを止めて手動で行うと、これはこれで面倒です。

そして、自動バックアップのバックアップ間隔の変更とかができないです。

これが不便に感じて、設定変更できるツールってないのかなと思って探したら、ありました!「TimeMachineEditor」です。

ここからダウンロードできます。

TimeMachineEditor のインストール

ダウンロードしたPKGファイルを、ダブルクリックしてインストールします。

インストーラー画面が表示されますので、画面に従って進めていきます。「続け」るをクリックして進みます。

Macへのログインパスワードが求められたら、パスワードを入力します。「ソフトウェアをインストール」をクリックして進みます。

これでTimeMachineEditorのインストールは完了です。非常に簡単ですね。

TimeMachineEditor の起動と設定

早速、TimeMachineEditorを起動してみましょう。

アプリケーション一覧からTimeMachineEditorを探して、打プルクリックで起動します。

まず「Back up」のチェックボックスにチェックを入れます。

その隣のプルダウンメニューをクリックしてみると、「不使用時」「インターバル」「カレンダー」の3つが選択できることが分かります。

不使用時の設定

ここでは、Time Machine のバックアップを使用したくない時間を指定することができます。

  • Do not back up from
    • 指定した何時から何時までの間はバックアップを行わない
  • Don’t backup when an app prevents display sleep
    • アプリがディスプレーのスリープを妨げる場合、バックアップを行わない
  • Don’t backup when an app prevents system sleep
    • アプリがシステムのスリープを妨げる場合、バックアップを行わない
  • Don’t backup when not wired to the network
    • ネットワークにケーブル接続されていない場合、バックアップを行わない
  • Create local snapshots every hour
    • スナップショットを毎時、ローカルに作成する

私の場合ですと、朝の9時から夜中の12時まではパソコンを触ることが多いので、この時間を指定して、バックアップ処理が走らないようにしています。つまり、バックアップは、夜中の12時から朝の9時までの間に処理するということです。

インターバル

ここでは、バックアップの間隔を指定することができます。

具体的には、何時間ごと、何日ごと、何週間ごとと単位で指定ができ、「1」以上の整数を入力していきます。

私の場合は、1日に1回のバックアップを取得するように設定しています。

カレンダー

ここでは、カレンダーを使って、バックアップを処理する曜日をや時間を指定できます。

「+」を押していくことで、複数の設定を行うことができます。

ちなみに私の場合は、毎日バックアップは取得しておきたいので、この機能は使用していません。

最後に、「適用」を押して設定を完了させます。

設定の適用

「適用」ボタンを押すと、こんな画面が表示されます。

実は、これが非常に重要です。

肝心なところが英語でしか表示されていないので見逃しがちなのですが、

Please make sure to disable automatic backup in System Preference in order to turn off the system scheduler.

です。

つまり、標準搭載されているTime Machineの設定で、自動バックアップを停止する必要があるのです。

この画面の左側にある「Back Up Automatically」のことです。

私はこれを読んでおらず、この自動バックアップのチェックボックスにチェックを入れたままにしてましたので、TimeMachineEditor で指定した間隔でのバックアップが行われず悩んでました。

おもしろかったら、フォローしてください!

世の中には楽しいことがいっぱい - にほんブログ村

最近の人気ブログ TOP 10:

関連する記事:

最近の記事:

カテゴリー
2022年 Windows ガジェット コンピューター バックアップ 自動化

BanBackup でバックアップの自動化

PVアクセスランキング にほんブログ村 にほんブログ村 ブログブログへ
にほんブログ村

今回やりたいのは、こんな感じです。

パソコンのデスクトップに保存されているデータ全てを、NAS にバックアップでコピーします。

今回は、バックアップソフトとして、BunBackup を使用しています。

バックアップ元のフォルダとして、デスクトップを指定していますが、マイドキュメントでもなんでも指定できます。

バックアップ先のフォルダーとして NAS を指定していますが、外付けハードディスクでも USB メモリーでも指定可能です。

手動バックアップの設定

BanBackup を起動します。

「+」ボタンをクリックして、新規ジョブを追加します。

「バックアップ設定」のウィンドウが表示されるので、以下のように設定します。

  • タイトル:バックアップジョブの名前
  • バックアップ元フォルダ:バックアップしたい対象のフォルダを指定
  • バックアップ先フォルダ:バックアップ先のフォルダを指定

「OK」をクリックして次に進みます。

先ほど作成したバックアップジョブの名前と内容が表示されます。

この内容を保存しておきます。

上部メニューの「ファイル」から「名前を付けて保存」を選択します。

バクアップ定義ファイル(「.lbk」の拡張子のファイル)を任意の場所に保存しておきます。これがあれば、次からその内容でバックアップを行えます。

手動バックアップをやってみましょう。

上部メニューの「バックアップ」から「バックアップ開始」を選択します。

先ほど設定した内容で、バックアップジョブが実行されます。

バックアップの自動化

先ほどの手動バックアップを自動化させたいと思いました。

でも、BunBackup のマニュアルを見ても、いまいち内容が分かりません。以下の感じで記載があります。

AUTOって何?タスクスケジューラで具体的にどうやって設定するの?って感じです。そこで手順を調べてみました。

Windows の検索ボックスから「task」と入力して、タスクスケジューラを検索します。

タスクスケジューラをクリックして起動します。

タスクスケジューラが起動して表示されます。

左側のメニューの「タスクスケジューラーライブラリ」をクリックします。

右側の「操作」メニューに表示される「基本タスクの作成」をクリックします。

基本タスクの作成ウィザードが表示されます。

以下の内容で入力します。

  • 名前:今作成しようとしているタスクの名前
  • 説明:作成しようとしているタスクの説明(オプション)

「次へ」をクリックします。

「タスクトリガー」の設定画面が表示されます。

今回は毎日バックアップを使用と思いますので、「毎日」を選択します。

「次へ」をクリックします。

「毎日」の設定画面が表示されます。

以下のように設定します。

  • 開始:タスクを実行したい日時を指定
  • 間隔:毎日なら「1」、2日に一回なら「2」を指定

「次へ」をクリックします。

「操作」の設定画面が表示されます。

ここでは、タスクの起動時に実行したいプログラムを指定します。

今回実行したいのは BunBackup のプログラムですので、「プログラムの開始」を選択します。

「次へ」をクリックします。

「プログラムの開始」の設定画面が表示されます。

以下のように設定します。

  • プログラム/スクリプト:BunBackup の実行ファイルをフルパスで指定します。

例えば、「/BACKUP:”C:\My Documents\BunBackup\Test.lbk”」という感じです。

ポイントは、バックアップ定義ファイルのフルパスを「”」で囲うことです。これをしないとエラーになって BunBackup が起動してくれません。

次のポイントが「引数」です。

BunBackup のマニュアルにも記載があるように、引数では、いろんなアクションを指定できるみたいですが、以下の二つがよく使用するものになるでしょう。

  • BACKUP
  • AUTO

BACKUP の方が、手動でバックアップしている内容をそのまま自動で実行するタイプです。バックアップの状況や結果を画面に表示します。

AUTO の方が、バックアップの状況や結果を画面には表示させないでバックアップを実行するタイプです。

今回は画面に見える形で実行させたいので、BACKUP を使ってみます。

引数に、以下のように指定します。手動バックアップの際にバックアップ定義ファイル(「.lbk」ファイル)を保存しました。そのファイルのフルパスを指定します。

例えば「/BACKUP:”C:\My Documents\BunBackup\Test.lbk”」という感じです。

「完了」をクリックして、タスクを作成します。

タスクスケジューラのタスク一覧に、作成したタスクの名前が表示されます。

タスクスケジューラからの実行確認

タスクを作成したのは良いけど、ちゃんと動くのかを見ておきたいです。そんな時は、実行したいタスクをクリックし、右側のメニューの中の「実行」をクリックします。

作成したタスクの内容を実行してくれます。

バックアップジョブが動き出しましたね。

右側のメニューの「実行中のすべてのタスクの表示」をクリックしてみます。

「実行中のすべてのタスク」のウィンドウが表示されます。

ここに作成したタスクが表示されていれば、タスクが実行されていることが確認できます。

おもしろかったら、フォローしてください!

世の中には楽しいことがいっぱい - にほんブログ村

関連する記事:

最近の記事:

カテゴリー
2022年 CCNP Enterprise Cisco コマンド コンピューター トラブルシューティング 技術一般 自動化 認定資格

Cisco EEM とは

PVアクセスランキング にほんブログ村 にほんブログ村 ブログブログへ
にほんブログ村

EEM とは

EEM (Embedded Event Manager) を使うことで、何らかのイベント発生時をトリガーとして、指定したアクションを実行することが可能となります。

IOS、IOS XR、IOS XE、NX-OS で利用ができ、EEM は IPBASE から利用できるので、安価なモデルでも使用可能となります。

利用シーンとして例えば、以下のようなケースがあります。

  • 特定のインターフェースを監視し、そのインターフェースがっダウンとなったら、管理者へメールを送信
  • CPU 使用率を監視し、事前に決めた閾値を超えたら、CPU 使用率の情報を取得してシスログで送信
  • インターフェースのエラー率を監視し、事前に決めたエラー率を超えた場合、該当インターフェースをシャットダウンさせSNMP トラップを送信

私のケースでは、IOS version 15.9 を使用して確認してます。

EEM の構成要素

以下の3つから構成されます。

  1. Event Director
  2. Policy
  3. EEMサーバ

事前に定義した Event と Action を Policy と呼びます。

Event DirectorPolicy に従ってイベントを監視し、

アクションを実行させる場合に、EEM サーバーに通知をします。

具体的には、Event Manager の中で、以下の項目を指定できます。

C892-02(config)#event manager ?
  applet       Register an Event Manager applet
  detector     Set Embedded Event Manager detector information
  directory    Set Embedded Event Manager directory information
  environment  Set an Embedded Event Manager global environment variable
  history      Set Embedded Event Manager history information
  policy       Register an Embedded Event Manager policy
  scheduler    Set Event Manager scheduler options
  session      Set Embedded Event Manager session attributes

Event Director で監視可能な対象(よく使うだろうもの)は、以下の通りとなります。

  • SNMP
    SNMP MIBオブジェクトを監視し、オブジェクトの値が任意の値とマッチするか、任意の閾値を越えた場合にイベント通知
  • Syslog
    事前に定義した文字列をトリガーにイベント通知
  • Timer
    absolute-time-of-day、countdown、watchdog、CRON の 4 タイプのタイマーをサポートし、それぞれイベントを通知
  • Interface Counter
    インタフェースカウンタが閾値を超えた際にイベントを通知
  • CLI
    CLIを正規表現で検査し、マッチした場合にイベントを通知
  • OIR
    モジュール等のOIRを検知した場合にイベント通知(Online Insertion and Removal:活性挿抜(いわゆるホットスワップ))
  • SNMP Proxy
    外部からのSNMPトラップを受けてイベントを通知
  • Routing
    ルーティングテーブルの変化を検知した際にイベントを通知
  • NetFlow
    NetFlow情報監視し、オブジェクトの値が任意の値とマッチ、あるいは任意の閾値を越えた場合にイベント通知
  • Neighbor Discovery
    CDPまたはLLDPによる情報を受けてイベントを通知
  • Mac Address Table
    MACアドレステーブルの変化を検知した際にイベントを通知

Event Director の監視対象イベントとして設定できる項目全ては、以下の通りです。

C892-02(config-applet)#event ?
  application         Application specific event
  cli                 CLI event
  config              Configuration policy event
  counter             Counter event
  env                 Environmental event
  identity            Identity event
  interface           Interface event
  ioswdsysmon         IOS WDSysMon event
  ipsla               IPSLA Event
  neighbor-discovery  Neighbor Discovery event
  nf                  NF Event
  none                Manually run policy event
  oir                 OIR event
  resource            Resource event
  rf                  Redundancy Facility event
  routing             Routing event
  rpc                 Remote Procedure Call event
  snmp                SNMP event
  snmp-notification   SNMP Notification Event
  snmp-object         SNMP object event
  syslog              Syslog event
  tag                 event tag identifier
  timer               Timer event
  track               Tracking object event

イベントを受けた後に実行出来る主なアクションは、以下の通りです(よく使われるもの)。

  • コマンドの実行や結果の取得
  • SNMPへのアクセス
  • 再起動
  • EEM Policyの呼び出し
  • スイッチオーバー
  • Eメール送信
  • SNMP Trap送信
  • Syslog送信

アクションとして設定できる項目全ては、以下の通りです。

C892-02(config-applet)#action 1.0 ?
  add                Add
  append             Append to a variable
  break              Break out of a conditional loop
  cli                Execute a CLI command
  cns-event          Send a CNS event
  comment            add comment
  context            Save or retrieve context information
  continue           Continue to next loop iteration
  counter            Modify a counter value
  decrement          Decrement a variable
  divide             Divide
  else               else conditional
  elseif             elseif conditional
  end                end conditional block
  exit               Exit from applet run
  file               file operations
  force-switchover   Force a software switchover
  foreach            foreach loop
  gets               get line of input from active tty
  handle-error       On error action
  help               Read/Set parser help buffer
  if                 if conditional
  increment          Increment a variable
  info               Obtain system specific information
  mail               Send an e-mail
  multiply           Multiply
  policy             Run a pre-registered policy
  publish-event      Publish an application specific event
  puts               print data to active tty
  regexp             regular expression match
  reload             Reload system
  set                Set a variable
  snmp-object-value  Specify value for the SNMP get request
  snmp-trap          Send an SNMP trap
  string             string commands
  subtract           Subtract
  syslog             Log a syslog message
  track              Read/Set a tracking object
  wait               Wait for a specified amount of time
  while              while loop

EEM の設定例

1. インターフェースが “Administratively down” されたら、”no shutdown” コマンドを発行

インタフェースがシャットダウンされると「Interface , changed state to administratively down」というログが出力されます。このシステムログのメッセージをイベントとして検出してそれをトリガーとして、CLI コマンドで “no shutdown” を発行するアクションを定義します。

まず、VLAN113をシャットダウンした時のシスログメッセージを確認します。

C892-02(config)#int vlan 113
C892-02(config-if)#shutdown
C892-02(config-if)#
017611: Mar  3 18:51:50.925: %LINK-5-CHANGED: Interface Vlan113, changed state to administratively down

上記のメッセージが出力されるのが分かります。

event manager applet No_Shutdown_VLAN113
 description "issue no shut"
 event syslog pattern "Interface Vlan113, changed state to administratively down"
 action 1.0 cli command "enable"
 action 2.0 cli command "config t"
 action 3.0 cli command "interface vlan113"
 action 4.0 cli command "no shutdown"

アクションを定義する時のポイントは、 “enable” や “config t”, “interface xxx” など、対象となるコマンドが発行できるモードまで進むコマンドも併せて定義するところです。

実行されたEEM のログを見たい場合、デバッグコマンドを実行しておきます。

debug event manager action cli

デバッグコマンド投入後、1の例の EEM を実行すると、以下のようなログが出力されます。VLAN113 がシャットされたことを検知して、”no shut” コマンドが発行されて、再び VLAN113 が Up になってますね。

C892-02(config)#int vlan 113
C892-02(config-if)#shut
C892-02(config-if)#
017631: Mar  3 18:58:36.864: %FW-6-DROP_PKT: Dropping tcp session 116.223.132.218:443 172.16.23.4:49699  due to  RST inside current window with ip ident 64807 tcpflags 0x8014 seq.no 3652153217 ack 1529682709
017632: Mar  3 18:58:38.468: %LINK-5-CHANGED: Interface Vlan113, changed state to administratively down
017633: Mar  3 18:58:38.472: %HA_EM-6-LOG: No_Shutdown_VLAN113 : DEBUG(cli_lib) : : CTL : cli_open called.
017634: Mar  3 18:58:38.480: %HA_EM-6-LOG: No_Shutdown_VLAN113 : DEBUG(cli_lib) : : OUT : CCC
017635: Mar  3 18:58:38.480: %HA_EM-6-LOG: No_Shutdown_VLAN113 : DEBUG(cli_lib) : : OUT : Cisco 982 (Serial Number: FGL151727WV)
017636: Mar  3 18:58:38.480: %HA_EM-6-LOG: No_Shutdown_VLAN113 : DEBUG(cli_lib) : : OUT : This is Cisco 982-02 @ Living room for Internet settings.
017637: Mar  3 18:58:38.480: %HA_EM-6-LOG: No_Shutdown_VLAN113 : DEBUG(cli_lib) : : OUT : No one is allowed to login to this system except Kanta Nakashima.
017638: Mar  3 18:58:38.480: %HA_EM-6-LOG: No_Shutdown_VLAN113 : DEBUG(cli_lib) : : OUT :
017639: Mar  3 18:58:38.480: %HA_EM-6-LOG: No_Shutdown_VLAN113 : DEBUG(cli_lib) : : OUT : C892-02>
017640: Mar  3 18:58:38.480: %HA_EM-6-LOG: No_Shutdown_VLAN113 : DEBUG(cli_lib) : : IN  : C892-02>enable
017641: Mar  3 18:58:38.492: %HA_EM-6-LOG: No_Shutdown_VLAN113 : DEBUG(cli_lib) : : OUT : C892-02#
017642: Mar  3 18:58:38.492: %HA_EM-6-LOG: No_Shutdown_VLAN113 : DEBUG(cli_lib) : : IN  : C892-02#config t
017643: Mar  3 18:58:38.508: %HA_EM-6-LOG: No_Shutdown_VLAN113 : DEBUG(cli_lib) : : OUT : Enter configuration commands, one per line.  End with CNTL/Z.
017644: Mar  3 18:58:38.508: %HA_EM-6-LOG: No_Shutdown_VLAN113 : DEBUG(cli_lib) : : OUT : C892-02(config)#
017645: Mar  3 18:58:38.508: %HA_EM-6-LOG: No_Shutdown_VLAN113 : DEBUG(cli_lib) : : IN  : C892-02(config)#interface vlan113
017646: Mar  3 18:58:38.520: %HA_EM-6-LOG: No_Shutdown_VLAN113 : DEBUG(cli_lib) : : OUT : C892-02(config-if)#
017647: Mar  3 18:58:38.520: %HA_EM-6-LOG: No_Shutdown_VLAN113 : DEBUG(cli_lib) : : IN  : C892-02(config-if)#no shutdown
017648: Mar  3 18:58:38.532: %HA_EM-6-LOG: No_Shutdown_VLAN113 : DEBUG(cli_lib) : : OUT : C892-02(config-if)#
017649: Mar  3 18:58:38.532: %HA_EM-6-LOG: No_Shutdown_VLAN113 : DEBUG(cli_lib) : : CTL : cli_close called.
017650: Mar  3 18:58:38.536:
017651: Mar  3 18:58:38.536: tty is now going through its death sequence
017652: Mar  3 18:58:40.524: %LINK-3-UPDOWN: Interface Vlan113, changed state to up
C892-02(config-if)#

2. 定期的にコマンドを実行し、その結果を NVRAM に書き込む

例えば、毎日午前 7時に “show ip route” コマンドを実行し、その内容を NVRAM に書き込んでいきます。

event manager applet Router-02
event timer cron name _EEMinternalname0 cron-entry "0 7 * * *"
action 1.0 cli command "enable"
action 2.0 cli command "show ip route | append nvram:Router-02"

まず、毎日午前7時という cron タイマをイベントとして登録します。「毎日午前7時」なので、cron-entry のあとに ”0 7 * * *” を指定します。

ちなみに、”0 18 * * *” だと「午後の6時」になります。

そして、アクションとして ”show ip route | append nvram:Router-02” の CLI コマンドを実行します。

“show ip route” の出力先として NVRAM 上の Router-02 ファイルを追記で指定しています。

NVRAM 上のファイルを表示する場合は、 more コマンドを使って、ファイルなを指定します。

more nvram:Router-02 <<< ファイル名を指定

EEM は CLI を使った設定と、Tcl スクリプトを使ってプログラミングする方法の 2種類があります。

CLI ベースは設定が簡単である反面、細かい制御をすることは出来ません。

逆に Tcl ベースだと、細かい制御をすることが出来ますが、Tcl スクリプトを扱えないといけませんので、若干敷居が高いかもしれません。ちょっとしたことをやりたいだけなら、CLI での設定でも十分でしょう。

この EEM はちょっといろいろ使えそうです。自宅の実環境で使ってみて、具体例をまた紹介したいと思います。

おもしろかったら、フォローしてください!

世の中には楽しいことがいっぱい - にほんブログ村

関連する記事:

最近の記事:

カテゴリー
2021年 Linux Riverbed SaaS Windows キャッシュ クラウド コンピューター 技術一般 自動化 証明書

モバイル PC で SaaS の快適アクセス

Riverbed TechnologyのClient Accelerator(旧SteelHead Mobile) という製品を触ってみました。

なぜ、この製品を触ってみたかというと、バージョン 6.2.2 にSSL Agent (SSL Simplification)という機能が搭載され、最適化動作にサーバ証明書の管理が不要となったためです。これは便利!と思い、早速、評価してみました。

SteelHead Appliance とは

業界をリードする WAN 最適化装置です。WAN越し、インターネット越しのアプリケーションアクセスのパフォーマンスを向上させます。WAN やインターネットに流れるデータを、特別なキャッシュの技術を使ってデータ削減します。

リバーベッドテクノロジー社初心者向け技術トレーニング資料より抜粋

Client Acceleratorとは

SteelHead アプライアンスをソフトウェアにした製品です。Windows や Mac のラップトップにインストールして使えます。

リバーベッドテクノロジー社初心者向け技術トレーニング資料より抜粋

なぜ、SSL Agentが良いのか?

インターネットの通信の 85%以上が SSL 通信(HTTPS)であると言われています。つまり、暗号化されているのです。

こういった暗号化された通信を制御する製品では、通信を一旦終端し、暗号化を解く必要があります。

この暗号化には、サーバ証明書を使用しています。

企業内にホスティングされている Web サーバーであれば、そのサーバーの管理者に依頼すれば、サーバー証明書を入手することは可能です。

ですが、これがインターネット上のサーバーだったら、どうでしょうか。誰が管理者か分からないし、管理者が仮に分かっても、サーバ証明書は通常得られません。

インターネット上サーバーの証明書は、管理者に依頼しなくても、サーバ証明書の内容は入手することは可能です。ですが、いつそれらの証明書の内容が変更になるかは分からないという点は変わりません。その内容に合わせて代理証明書を作っても、元の証明書の内容が変更になるたびに代理証明書の方も変更する必要があり、管理が大変です。

WAN 最適化装置も、クライアント PC と Web サーバーの間の通信に入り込んで動作しますので、暗号化された通信は一度復号化する必要があります。そこに、サーバ証明書を使っています。

企業内の Web サーバーであれば、管理者に依頼してサーバー証明書を入手し、その証明書を WAN 最適化装置にもインストールしれば良いので対応できます。

しかし、これが Microsoft 365(Office 365)へのアクセスだったらどうでしょうか。マイクロソフトからサーバー証明書はもらえません。

復号化ができませんので、最適化動作(特に問題になるのはデータ削減)ができなくなります。

仮に、先ほどの方法で内容を把握し、自分で代理証明書を作成することは可能ですが、その内容が変更になったら、証明書がないのと同じです。マイクロソフトは、M365 の証明書をかなり頻繁に変更しています。

SSL Agent の登場

こういった問題を解決できるのが、SSL Agent です。この機能を使えば、サーバ証明書のインストールは不要になります。どうやったら証明書が入手できるのかとか、いつ変更になるのかを気にする必要はもうありません。

動作確認の構成

テスト構成はこんな感じです。

Client Accelerator と SteelHead の間に WAN シミュレーターを入れ、ここで疑似インターネットを作っています。WAN シミュレーターで、帯域幅や遅延、パケットロスが設定できます。今回のテストでは、100ミリ秒の遅延を入れています。

WAN シミュレーターには、WANemを使っています。

そして、アクセス先は、実際の M365 を使っています。私が個人で契約して使っているものですので、東京リージョンになります。M365 へのアクセスは、実インターネットの通信です。

データ削減の効果

OneDrive に保存してある 68MB のパワーポイントのドキュメントをダウンロードしてみました。

以下のグラフの一番上のコネクションが、OneDrive からのダウンロードのコネクションです。転送データの内、41% のデータが重複排除され削減されています。通信の宛先ポート番号がTCP/443(HTTPS)になってますね。サーバ証明書なしで、データ削減ができています。

キャッシュの無い一回目のデータ転送でも半分弱のデータが削減されてます。すごい効果ですね。40秒ほどで、ダウンロードが完了しています。

今度は、二回目の転送です。以下のグラフの上から2番目のコネクションが、OneDrive からのダウンロードのコネクションです。

同じパワーポイントのファイルを再度転送しています。91% のデータ削減です。もうほとんど、疑似インターネット上にはデータが流れてません。流れるデータの量が減れば、とうぜん体感のスピードだって上がりますよね。数秒でダウンロードは完了しています。

同じファイルなんだからデータが減って当たり前、という考え方もあります。

ですが、Riverbed 社のキャッシュは、ファイルキャッシュではなく、バイトキャッシュを使っています。

約100バイトの大きさにデータを細切れにし、その中の「0」と「1」の配列が同じであれば、1つにするという方式で、データ削減を行っています。

リバーベッドテクノロジー社初心者向け技術トレーニング資料より抜粋

つまり、この「0」 と「1」の配列が同じであれば良いだけで、パワーポイントで得たキャッシュで、エクセルでも PDF でも、データ削減が出来ちゃうという訳です。すごい技術を持ってます。

もう一つのテスト構成

Web プロキシーサーバーというものは、企業でよく使われています。これがあった場合でも、この WAN 最適化の仕組みは動くのだろうか?という疑問が湧きましたので、追加で動作も見てみました。

Web プロキシーサーバーには、 Unveil Technology 社のOpen Squidbox を使ってます。Linux でお馴染みの Squid なんですが、仮想アプライアンスみたいになってて、手軽に使えます。GUI の画面からグラフを見られて便利です。

Web プロキシー経由での、一回目のデータダウンロードです。以下のグラフの上から2番目のコネクションです。今度は、宛先ポート番号がTCP/3128(Squid)になってますね。

一回目のキャッシュなしのダウンロードで、44%のデータ削減が実現しています。

今度は二回目のダウンロードです。以下のグラフの下から4番目のコネクションです。94%のデータ削減が実現しています。Web プロキシーを経由しても、データ削減の効果は得られていますし、変わらない結果が得られました。

評価のまとめ

  • キャッシュを使ってのデータ削減と差分データ転送の効果は高い。
  • 運用すればするほどキャッシュは溜まるので、一回目のデータ転送時のデータ削減効果は高くなることが期待できる。
  • SaaS アプリケーションだけでなく、Yahoo や Facebook など、インターネット上にある Web サーバーは何でも最適化対象にできる。
  • ただし、ある程度の転送データ量があるコネクション(OneDrive や SharePoint のアクセス)を対象にしないと、投資効果が合わない。
  • ダイレクトアクセスでも、Web プロキシー経由のアクセスでも、通信を最適化することができる。

私のオーストラリアの某お客様が、シンガポールのデータセンターにある Web プロキシーを経由して Microsoft 365にアクセスしているが遅いといっていますので、早速、この SSL Agent を提案してみたいと思います!

SSL Agent の設定

最後に、設定内容もメモとして記載しておきます。

SteelHead アプライアンス側設定

SSL Main Setting のところで、SSL Optimization を有効にします。

SSL Advanced Settings のところで、TLS Blade を有効にします。

Client Accelerator Controller の自己証明書をコピーし、SteelHead アプライアンスのMobile Trust のリストに追加します。

これは、Client Accelerator ソフトウェアとSteelHead アプライアンス間(最適化通信のコネクション)を暗号化するためです。

Client Accelerator Controller 側のポリシーの設定

Port Label で、「Web」というラベルを作成し、TCP/80, 443, 3128を対象としています。Port Label とは、複数のポート番号をグループ化して名前で管理できるようにするものです。

In-Path ルールで、Webでまとめたポート番号向けの通信を全て最適化対象とするというルールを設定します。

今回使用しているルールの内容です。

Peering 証明書のところに、SteelHeadアプライアンスの自己証明書をコピーして追加します。Client Accelerator ソフトウェアとSteelHeadアプライアンス間の最適化通信を暗号化するためです。

SSL 設定のところで、SSL Optimization を有効にします。

その設定ページの下の方にあるTLS Optimization を有効にします。

Client Accelerator の評価版は、こちらから申請して試すことが可能です。

PVアクセスランキング にほんブログ村 にほんブログ村 ブログブログへ
にほんブログ村

関連する記事:

最近の記事:

カテゴリー
2020年 AWS PaaS クラウド コンピューター サーバレス 技術一般 自動化

AWS を学ぶ(23)CloudFormation を使ってみる

PVアクセスランキング にほんブログ村 にほんブログ村 IT技術ブログへ
にほんブログ村

前回の記事で、CloudFormation がどのようなものなのかを調べてみました。

今回は、実際に使ってみたいと思います。

  1. テンプレートでVPC を作成する
  2. Ref 関数でサブネットを作成する
  3. その他のネットワーク関連を作成する
  4. EC2 のひな形を作成する
  5. Parameters セクションを使って、実行時にEC2 のインスタンスタイプを選択できるようにする
  6. Parameters + AWS 固有のパラメーターを使用して、アカウントにあるキーペアを、EC2 実行時に埋め込む
  7. スタックの削除する

CloudFormation を使ってみる

テンプレートから基本環境の作成

まず最初に、VPCの状況を確認しておきます。

私の環境では、東京リージョンに、現在3つのVPCがあります。

AWS の管理コンソールの検索テキストボックスから、「CloudFormation」を検索してクリックします。

CloudFormation の管理コンソールが表示されます。

「スタックの作成」をクリックします。

スタックの作成画面が表示されます。

前回のサンプルテンプレートを使用します。サンプルスクリプトを保存し、拡張子を「.yml」にしておきます。

「ファイルの選択」をクリックし、YAMLのサンプルファイルを読み込ませます。

「デザイナーで確認」をクリックすると、YAMLファイルを読み込んで作成するスタックの状況がみられます。

VPCを作成する部分だと、こんな感じですね。

画面を戻を戻ると、作成のし直しになっちゃいますね。これって、見ない方がいいのかな?

進めると、スタックの名前の画面が表示されます。

スタックの名前を入力します。

「次へ」をクリックして進みます。

スタックのオプションの画面が表示されます。

今回は特に設定しません。

「次へ」をクリックして進みます。

レビューの画面が表示されますので、内容を確認します。

「スタックの作成」をクリックして、スタックを作成します。

スタックの作成が始まりました。

画面左側のメニューで、「CREATE_COMPLETE」の緑色の文字が表示されれば、スタックの作成は完了です。

「リソース」タブをクリックすると、リソースの一覧が表示されます。

VPCとサブネットが作成されていますね。それぞれの名前を見てみると、YAMLファイルの中で指定したものになっていますね。

VPC の画面を見ていますと、先ほど3つしかなかったVPC が4つになってますね。「cfn-vpc」が、今回作成されたものです。

サブネットの画面を見てみると、サブネットも追加されてますね。「cfn-subnet」が、今回作成されたものです。

インターネットゲートウェイも見てみます。新規で作成されてますね。「cfn-igw」が今回作成されたものです。

ルートテーブルも見てみます。ルートテーブルも新規で作成されてますね。「cfn-rt」が今回作成されたものです。

設定内容を追加する

最初に作ったテンプレートに、項目を追加するということはよくあることでしょう。今度は、それを想定して、別の項目を追加して反映させてみます。

今回試してみたいのは、前回作成したサブネット上に、新規でEC2 インスタンスを起動させることです。その際に、イメージサイズを選択して起動できるようにします。

前回のテンプレートに、以下の2つを追記してみます。

起動時に、インスタンスタイプを、「t2.micro」「t2.small」「t2.medium」の3つから選べるようにします。

Parameters:
  InstanceType:
    Type: String
    Default: t2.micro
    AllowedValues:
      - t2.micro
      - t2.small
      - t2.medium
    Description: Select EC2 instance type.
  KeyPair:
    Description: Select KeyPair Name.
    Type: AWS::EC2::KeyPair::KeyName

さらに、起動するインスタンスに、Keypairも指定できるようにします。

セキュリティーグループも作成し、SSHでのアクセスのみを許可します。

cfnEC2Instance:
    Type: 'AWS::EC2::Instance'
    Properties:
      ImageId: !FindInMap [ RegionMap, !Ref "AWS::Region", hvm ]
      InstanceType: !Ref InstanceType
      SubnetId: !Ref cfnSubnet
      BlockDeviceMappings:
        - DeviceName: '/dev/xvda'
          Ebs:
            VolumeType: 'gp2'
            VolumeSize: 8
      Tags:
        - Key: 'Name'
          Value: 'cfn-ec2-instance'
      SecurityGroupIds:
        - !Ref cfnSecurityGroup
      KeyName: !Ref KeyPair
  cfnSecurityGroup:
    Type: "AWS::EC2::SecurityGroup"
    Properties:
      GroupDescription: "cfnSecurityGroup"
      VpcId: !Ref cfnVpc
      Tags:
        - Key: 'Name'
          Value: 'cfn-ssh-sg'
      SecurityGroupIngress:
      - IpProtocol: tcp
        FromPort: '22'
        ToPort: '22'
        CidrIp: 0.0.0.0/0

変更するスタック名を選択し、「変更する」をクリックします。

今回は既存のテンプレートを変更しますので、「既存テンプレートを書き換える」を選択します。

「テンプレートファイルのアップロード」を選択します。

「ファイルの選択」から、追記したテンプレートファイルをアップロードします。

「次へ」をクリックして進みます。

インスタンスを起動させる際に、インスタンスタイプとキーペアを選択できるようにしたので、選択画面が表示されました。

今回は、インスタンスタイプ「t2.micro」とキーペア「amazon-linux-test」を選択します。

キーペアで表示される内容ですが、ご使用の環境で異なります。表示荒れるのは、自分の使用しているAWSのリージョンで使用できるキーペアです。

「次へ」をクリックして進みます。

スタックのオプション画面が表示されます。

今回は、オプションは何も設定しません。

「次へ」をクリックして進みます。

レビューの画面が表示されます。

設定内容を確認します。

「スタックの変更」をクリックします。

EC2 インスタンスの作成が始まりました。

スタックの変更が完了しました。

EC2 の管理コンソールを見てみると、指定した名前でインスタンスが起動していますね。

スタックの削除

対象のスタック名を選択し、「削除」をクリックします。

確認のポップアップウィンドウが表示されます。

「スタックの削除」をクリックします。

スタックの削除が開始されました。

数分待つと、スタックが完全に削除されます。

EC2 を見てみると、先ほど起動させたインスタンスが削除されています。

VPC の方も、この動作確認向けに作成したものは消えてますね。

CloudFormationは、テンプレートを作成して必要なリソースを作成することができるので便利です。

削除も、テンプレートに記載されたリソースを個別ではなく、全てを一気に削除してくれるので便利ですね。

注意点は、CloudFormationでリソースを作成した後に、マニュアルでリソースの変更をしないことです。テンプレートの内容と不一致になりますし、後からテンプレートを編集するのも大変になります。

この教材を使って勉強してます。

AWS認定資格試験テキスト AWS認定ソリューションアーキテクト-アソシエイト

AWSに関連する記事:

関連する記事:

最近の記事:

カテゴリー
2020年 AWS PaaS クラウド コンピューター サーバレス 技術一般 自動化

AWS を学ぶ(22)CloudFormation とは何か?

PVアクセスランキング にほんブログ村 にほんブログ村 IT技術ブログへ
にほんブログ村

AWS の自動化サービスは、以下の 3つがあります。

  • AWS Elastic Beanstalk
  • AWS OpsWorks
  • CloudFormation

どのサービスにも向き不向きがあり、得意とする部分がありますので、要件に合わせて使用することが大切です。

Elastic Beanstalk

インフラ構成の自動構築とアプリ導入の自動化サービスです。こちらの記事で、以前調べています。

  • Web サーバー構成(ELB + AutoScaling + EC2)
  • バッチワーカー構成(SQS + AutoScaling + EC2)
  • OS より上も下も、標準構成の範囲内で対応(自由度は高くはない)

OpsWorks

Chef を利用した構成管理サービスです。

  • EC2 上のエージェントが OpsWorks 上の Chef レシピ(構成設計図)を参照し自動構築
  • 自前で Chef Client / Server を構築・保守する必要がない
  • Chef を既に利用している環境に最適
  • OS よりも下のレイヤーに関しては、できることが限られている

CloudFormation

AWS のリソース管理・構築を自動化するサービスです。

  • テンプレート(構築設計書)を JSON や YAML 形式で記述
  • テンプレートを元に、AWS のリソースを自動構築
  • OS より上は、Ansible や Chef を併用する必要がある
  • OS より下は、テンプレートに従って何でも可能(自由度が高い)

CloudFormation とは

CloudFormation は、以下の2つから構成されます。

  • テンプレート
  • スタック

テンプレート: AWS のリソースを JSON や YAML 形式で記載した構成設計図

スタック: テンプレートから構成された AWS のリソース群

複数のリソースを集合として管理しているため、削除する時も、個別でなく、全体で削除が可能となります。

テンプレートの構成

今回は、YAML 形式を使ってみます。サンプルのテンプレートは、こんな感じです。

テンプレートの内容ですが、

「VPC を作成し、そこにサブネットを 1つ作成し、IGW を作成して、デフォルトルートを向ける」

になっています。

AWSTemplateFormatVersion: '2010-09-09'
Description: Test CloudFormation Template

Resources:
  cfnVpc:
    Type: 'AWS::EC2::VPC'
    Properties:
      CidrBlock: '192.168.0.0/16'
      Tags:
        - Key: 'Name'
          Value: 'cfn-vpc'
  cfnSubnet:
    Type: 'AWS::EC2::Subnet'
    Properties:
      CidrBlock: '192.168.1.0/24'
      MapPublicIpOnLaunch: true
      Tags:
        - Key: 'Name'
          Value: 'cfn-subnet'
      VpcId: !Ref cfnVpc
  cfnInternetGateway:
    Type: AWS::EC2::InternetGateway
    Properties:
      Tags:
      - Key: 'Name'
        Value: 'cfn-igw'
  cfnAttachGateway:
    Type: AWS::EC2::VPCGatewayAttachment
    Properties:
      VpcId: !Ref cfnVpc
      InternetGatewayId: !Ref cfnInternetGateway
  cfnRouteTable:
    Type: AWS::EC2::RouteTable
    Properties:
      Tags:
        - Key: 'Name'
          Value: 'cfn-rt'
      VpcId: !Ref cfnVpc
  cfnRoute:
    Type: AWS::EC2::Route
    DependsOn: cfnInternetGateway
    Properties:
      RouteTableId: !Ref cfnRouteTable
      DestinationCidrBlock: 0.0.0.0/0
      GatewayId: !Ref cfnInternetGateway
  cfnSubnetRouteTableAssociation:
    Type: AWS::EC2::SubnetRouteTableAssociation
    Properties:
      SubnetId: !Ref cfnSubnet
      RouteTableId: !Ref cfnRouteTable

各項目を、1つずつ見ていきましょう。

「AWSTemplateFormatVersion: ‘2010-09-09’」ですが、バージョンの日付は、このまま使う必要があります。変更すると、エラーになります。

現在はこれを使うようにと、AWSのページにも記載がありました。

「Resources:」で、VPC、サブネット、IGW、ルートテーブルなどを指定して、設定をしていきます。

ここで指定できる項目や指定の仕方は、AWS のこちらのページに詳しく記載があります。

まず、VPC を作成します。

VPC で使用するアドレスブロックは、ここでは、「192.168.0.0 /16」 とします。

Tags の「Value:」 で、VPC の名前をタグ付けします。

  cfnVpc:
    Type: 'AWS::EC2::VPC'
    Properties:
      CidrBlock: '192.168.0.0/16'
      Tags:
        - Key: 'Name'
          Value: 'cfn-vpc'

次に、VPC 内に、サブネットを作成します。

サブネットで使用するアドレス範囲は、ここでは、「192.168.1.0 /24」 とします。

Tags の「Value:」で、サブネットの名前をタグ付けします。

「VpcId:」 で、どこの VPC 上にサブネットを作成するのかを指定するのですが、「!Ref」関数で、上で作成した VPC の名前を参照させます。

 cfnSubnet:
    Type: 'AWS::EC2::Subnet'
    Properties:
      CidrBlock: '192.168.1.0/24'
      MapPublicIpOnLaunch: true
      Tags:
        - Key: 'Name'
          Value: 'cfn-subnet'
      VpcId: !Ref cfnVpc

次に、Internet Gateway を作成します。

Tags の「Value:」で、Internet Gateway の名前をタグ付けします。

  cfnInternetGateway:
    Type: AWS::EC2::InternetGateway
    Properties:
      Tags:
      - Key: 'Name'
        Value: 'cfn-igw'

次に、作成したInternet Gateway を VPC にアタッチします。

「VpcId:」で、どこの VPC にアタッチするするのかを指定するのですが、「!Ref」関数で、上で作成した VPC の名前を参照させます。

cfnAttachGateway:
    Type: AWS::EC2::VPCGatewayAttachment
    Properties:
      VpcId: !Ref cfnVpc
      InternetGatewayId: !Ref cfnInternetGateway

次に、ルートテーブルを作成します。

Tags の「Value:」で、Internet Gateway の名前をタグ付けします。

「VpcId:」で、どこの VPC にアタッチするするのかを指定するのですが、「!Ref」関数で、上で作成した VPC の名前を参照させます。

cfnRouteTable:
    Type: AWS::EC2::RouteTable
    Properties:
      Tags:
        - Key: 'Name'
          Value: 'cfn-rt'
      VpcId: !Ref cfnVpc

次に、デフォルトルートを作成します。

「RouteTableId:」で、どのルートテーブルに作成するのかを指定するのですが、「 !Ref cfnRouteTable」関数で、上で作成したルートテーブルの名前を参照させます。

cfnRoute:
    Type: AWS::EC2::Route
    DependsOn: cfnInternetGateway
    Properties:
      RouteTableId: !Ref cfnRouteTable
      DestinationCidrBlock: 0.0.0.0/0
      GatewayId: !Ref cfnInternetGateway

最後に、ルートテーブルをサブネットに関連づけます。

「SubnetId:」 で、どのサブネットに関連づけるのかを指定するのですが、「!Ref cfnSubnet」関数で、上で作成したサブネットの名前を参照させます。

「RouteTableId:」で、どのルートテーブルに作成するのかを指定するのですが、「 !Ref cfnRouteTable」関数で、上で作成したルートテーブルの名前を参照させます。

cfnSubnetRouteTableAssociation:
    Type: AWS::EC2::SubnetRouteTableAssociation
    Properties:
      SubnetId: !Ref cfnSubnet
      RouteTableId: !Ref cfnRouteTable

「VPC を作成し、そこにサブネットを1つ作成し、IGW を作成して、デフォルトルートを向ける」

これくらいの作業であれば、GUI から行っても良いのですが、サブネットの数が多かったりすると大変です。自動化サービスを使うと便利ですね。

長くなってしまったので、実際にCloudFormation を使ってみるのは、次の記事にしたいと思います。

この教材を使って勉強してます。

AWS認定資格試験テキスト AWS認定ソリューションアーキテクト-アソシエイト

AWSに関連する記事:

関連する記事:

最近の記事: