2021年2月24日水曜日

Docker Composeを作って複数のコンテナの作成・起動・停止・削除を制御する

Dockerを使っていると、コンテナの作成・起動・停止・削除をするたびに以下のコマンドを叩く必要がある。

処理 コマンド
コンテナ作成・起動 docker run
コンテナ起動 docker start
コンテナ停止 docker stop
コンテナ削除 docker rm

それぞれのコマンドには、イメージ名やオプションを指定したうえで実行する必要があり、コンテナが増加するにしたがって、毎回毎回実行することが大きな負荷となる。また、必要なオプションなどもコマンドとして別途記録しておく必要もあり、管理面でも煩雑となっていく。

そのような状況を改善するために、「Docker Compose」を使ってみることにした。Docker Composeを使うことで、以下を実現することができる。

  • 複数のコンテナの操作を1回のコマンドで実施可能
  • コンテナ作成・起動に必要な情報をYAMLファイルに定義し、構成管理を行うことが可能

本記事ではDocekr Composeのインストール方法と使用方法について記載する。先に言っておくと、Docker Composeは実行ファイルをダウンロードして実行権限を付与するだけで動作するため、導入が非常に容易である。

環境

今回のDocker Compose導入時のソフトウエアバージョンを以下に記載する。

  • DockerホストOS : CentOS 8.2
  • Docer : 19.03.14
  • Docker Compose : 1.27.4

Docker Composeのインストール

1. Docker Composeのダウンロード

Docker Composeはコマンドファイル一つだけで動作する。以下の通り、curlを使って最新版のDocker Composeの実行ファイルをダウンロードするだけでよい。

# curl -L https://github.com/docker/compose/releases/latest/download/docker-compose-Linux-x86_64 -o /usr/local/bin/docker-compose
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   152  100   152    0     0    577      0 --:--:-- --:--:-- --:--:--   575
100   651  100   651    0     0   2333      0 --:--:-- --:--:-- --:--:--  2333
100 11.6M  100 11.6M    0     0  1955k      0  0:00:06  0:00:06 --:--:-- 2839k

もし最新バージョン以外のバージョンを選択したい場合は、Releases - docker/composeにてバージョンを確認したのち、以下のようにダウンロード先URLを変更すればよい。
※以下は1.27.4をダウンロードする場合のコマンド例となる。

# curl -L https://github.com/docker/compose/releases/download/1.27.4/docker-compose-Linux-x86_64 -o /usr/local/bin/docker-compose
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   651  100   651    0     0  17131      0 --:--:-- --:--:-- --:--:-- 17131
100 11.6M  100 11.6M    0     0   773k      0  0:00:15  0:00:15 --:--:-- 2154k

2. Docker Composeのインストール

ダウンロードしたdocker-composeのファイルに対して実行権限を付与する。これだけでDocker Composeが使えるようになる

# chmod +x /usr/local/bin/docker-compose

念のため、docker-compose -vにてDocker Composeのバージョンを確認しておこう。本記事では、「1.27.4」が導入バージョンとなる。

# docker-compose -v
docker-compose version 1.27.4, build 40524192

docker-compose.ymlを作成

Docker Composeはdocker-compose.ymlというYAMLファイルを読み取り、コンテナの構築を行う。今回は例として、以下3つのコンテナに適切なポート、ボリュームの紐づけを行ったうえで同時に起動させる処理を記述することにする。

  • プロキシ用コンテナ : centos-squid
  • DNS用コンテナ : centos-unbound
  • メール用コンテナ : centos-postfix

1. 作業用ディレクトリを作成

Docker Composeの作業用ディレクトリを任意の場所に作成する。今回は、ホームディレクトリの配下にcompose-01というディレクトリを作成した。

# mkdir ~/compose-01
# cd ~/compose-01/

2. docker-compose.ymlを作成

以下の通りdocker-compose.ymlを作成した。記述イメージとしては、docker runコマンドを実行する際のオプションをYAML形式にて記載しただけ、といった内容となる。

# cat docker-compose.yml
version: "3"
services:
  squid:
    image: centos-squid:1
    container_name: "centos-squid"
    ports:
      - "8080:8080"
    volumes:
      - "/var/log/docker/centos-squid:/var/log/squid"

  unbound:
    image: centos-unbound:1
    container_name: "centos-unbound"
    ports:
      - "10053:53"
      - "10053:53/udp"
    volumes:
      - "/var/log/docker/centos-unbound:/var/log/unbound"

  postfix:
    image: centos-postfix:1
    container_name: "centos-postfix"
    ports:
      - "25:25"
    volumes:
      - "/var/log/docker/centos-postfix:/var/log/postfix"

Docker Composeを使ってコンテナを操作する

1. コンテナ作成・起動

Docker Composeにてコンテナを作成・起動させるにはdocker-compose up -dコマンドにて行う。-dオプションを付けない場合、Docker Composeがフォアグラウンドで起動してしまい、プロンプトが返ってこなくなる。この状態でCtrl + Cでプロセスを止めてしまうと、コンテナ停止・削除がされてしまうので、通常は-dオプションを付与して実行したほうがよいだろう。

# docker-compose up -d
Starting centos-squid   ... done
Starting centos-unbound ... done
Starting centos-postfix ... done

確認はdocker-compose psコマンドにて行う。

# docker-compose ps
     Name                 Command             State             Ports
--------------------------------------------------------------------------------
centos-postfix   /bin/sh -c /usr/sbin/rsysl   Up      0.0.0.0:25->25/tcp
                 ...
centos-squid     /bin/sh -c /usr/sbin/squid   Up      0.0.0.0:8080->8080/tcp
                 ...
centos-unbound   /bin/sh -c /usr/sbin/unbou   Up      0.0.0.0:10053->53/tcp,
                 ...                                  0.0.0.0:10053->53/udp

2. コンテナ停止・削除

Docker Composeにてコンテナを停止・削除するにはdocker-compose downコマンドにて行う。

# docker-compose down
Stopping centos-unbound ... done
Stopping centos-postfix ... done
Stopping centos-squid   ... done
Removing centos-unbound ... done
Removing centos-postfix ... done
Removing centos-squid   ... done
Removing network compose-01_default

docker-compose psコマンドにて確認すると、コンテナが削除されていることがわかる。

# docker-compose ps
Name   Command   State   Ports
------------------------------

3. コンテナ起動・停止のみ行う

毎回毎回コンテナの作成・削除は不要な場合は、起動・停止だけすることもできる。

  • 起動のみ : docker-compose start
  • 停止のみ : docker-compose stop

まずは、コンテナを停止してみる。コンテナを停止後、StateがExit <Exitコード>となっている。centos-squidだけExit 137になっているが、本題とは関係ないので今回は説明を割愛する。

# docker-compose stop
Stopping centos-unbound ... done
Stopping centos-squid   ... done
Stopping centos-postfix ... done

# docker-compose ps
     Name                   Command                State     Ports
------------------------------------------------------------------
centos-postfix   /bin/sh -c /usr/sbin/rsysl ...   Exit 0
centos-squid     /bin/sh -c /usr/sbin/squid ...   Exit 137
centos-unbound   /bin/sh -c /usr/sbin/unbou ...   Exit 0

次に、コンテナを起動させてみる。3台のコンテナのステータスがUpになったことが確認できる。

# docker-compose start
Starting squid   ... done
Starting unbound ... done
Starting postfix ... done

# docker-compose ps
     Name                 Command             State             Ports
--------------------------------------------------------------------------------
centos-postfix   /bin/sh -c /usr/sbin/rsysl   Up      0.0.0.0:25->25/tcp
                 ...
centos-squid     /bin/sh -c /usr/sbin/squid   Up      0.0.0.0:8080->8080/tcp
                 ...
centos-unbound   /bin/sh -c /usr/sbin/unbou   Up      0.0.0.0:10053->53/tcp,
                 ...                                  0.0.0.0:10053->53/udp

参考

▼最新ドキュメント

▼最新ではないが、日本語なのでわかりやすい。

2021年2月14日日曜日

Zabbix API入門

ZabbixにはZabbix APIと呼ばれるHTTPベースで動くAPIが存在する。こちらを利用すると、リモートからZabbixのホスト一覧取得やホストの登録など、さまざまな操作を行うことができる。

今回、実際にZabbix APIを利用して、ホスト一覧の取得とホスト登録作業を実施してみた。

Zabbix環境

利用する環境は以下の通り。
  • OS : Cent OS 7.6
  • Zabbix : MIRACLE ZBX 4.0.2
  • APIのURL : http://192.168.11.24/zabbix/api_jsonrpc.php

事前準備

Zabbix APIを使うにあたり、curljqを利用する。curlはCent OS 7であれば標準でインストールされており、HTTPプロトコルでデータの送受信ができるコマンドとなる(正確にはHTTP以外にもさまざまなプロトコルに対応している)。

jqコマンドは、Zabbix APIやREST APIなどで利用されているJSON形式のデータを整形して出力したり、必要なデータのみ抽出するのに利用するコマンドとなる。jqコマンドはOSに標準ではインストールされていないので、yumでインストールしておく。
# yum install epel-release
# yum install jq
また、Zabbix APIのURLやヘッダ情報などは、毎回同一となることから、あらかじめ変数として利用できるようにしておこう。
# header='Content-Type:application/json-rpc'
# apiurl='http://192.168.11.24/zabbix/api_jsonrpc.php'
なお、JSONでは{"キー(key)": "値(value)"}といったようにデータを表現する。本記事では、データ名称を「キー」、データの値を「値」として表現することにする。

Zabbix APIを実行する際に送信するJSON形式のデータは、以下構文となる。
{
  "jsonrpc": "2.0",
  "method": "メソッド名",
  "params": {
    "パラメータ1 Key": "パラメータ1 Value",
    "パラメータ2 Key": "パラメータ2 Value",
    ...
  },
  "auth": "Zabbix認証トークン",
  "id": 任意の数字
}
以降の手順では、上記構文の送信データを作成したのち、curlコマンドでそのデータを送信してAPIを実行する、という流れとなる。

とりあえずZabbix APIを使ってみよう

apiinfo.versionというメソッドでZabbix APIのバージョンを確認することができるので、まずはそれを実行してZabbix APIの動作を確認してみよう。

送信するデータを変数jsonに以下のように代入する。
# json='{"jsonrpc": "2.0","method": "apiinfo.version","params": [],"id": 1}'
curlコマンドを使いZabbix APIを実行する。必要な定型文はすべて変数にしているので、そこまで複雑なコマンドではない。
# curl -sS -X POST -H "${header}" -d "${json}" ${apiurl} | jq
{
  "jsonrpc": "2.0",
  "result": "4.0.2",
  "id": 1
}
resultキーが4.0.2となっている。Zabbix APIのバージョンは、Zabbixと同様4.0.2となっていることがわかる。

なお、送信するデータは、"${json}"のようにダブルクォートで囲まないとエラーとなるので注意すること。
# curl -sS -X POST -H "${header}" -d ${json} ${apiurl} | jq
curl: (6) Could not resolve host: "2.0","method"; 不明なエラー
curl: (6) Could not resolve host: "apiinfo.version","params"; 不明なエラー
curl: (3) [globbing] illegal character in range specification at pos 2
curl: (3) [globbing] unmatched close brace/bracket at pos 2

認証トークンを取得しよう

Zabbix APIの実行は、認証トークンが必要となる。認証トークンは、user.loginメソッドで取得できる。

Adminユーザーの認証トークンを取得する場合は、以下コマンドとなる。passwordキーにはAdminユーザーのパスワードを入力すること。
# json='{"jsonrpc": "2.0","method": "user.login","params": {"user": "Admin","password": "XXXXXXXX"},"id": 1,"auth": null}'
# echo $json | jq
{
  "jsonrpc": "2.0",
  "method": "user.login",
  "params": {
    "user": "Admin",
    "password": "XXXXXXXX"
  },
  "id": 1,
  "auth": null
}

# curl -sS -X POST -H "${header}" -d "${json}" ${apiurl} | jq
{
  "jsonrpc": "2.0",
  "result": "4c6e0aedc3b0ab857fdab135880b468e",
  "id": 1
}
resultキーの値(上記では4c6e0aedc3b0ab857fdab135880b468e)が認証トークンとなる。

この認証トークンは、この後のZabbix API実行で毎回必要となることから、変数に代入しておこう。
# json='{"jsonrpc": "2.0","method": "user.login","params": {"user": "Admin","password": "XXXXXXXX"},"id": 1,"auth": null}'
# zbxauth=$(curl -sS -X POST -H "${header}" -d "${json}" ${apiurl} | jq -r ".result")
# echo $zbxauth
aadba09641add6a14b7b3e95fa4920e4

ホスト一覧を取得しよう

host.getメソッドを使って、Zabbixに登録されているホスト一覧を取得できる。先ほど取得した認証情報はauthキーの値として指定する。
# json='{"jsonrpc": "2.0","method": "host.get","params": {"output": ["hostid","host"]},"id": 2,"auth": "'$zbxauth'"}'
# echo $json | jq
{
  "jsonrpc": "2.0",
  "method": "host.get",
  "params": {
    "output": [
      "hostid",
      "host"
    ]
  },
  "id": 2,
  "auth": "4c6e0aedc3b0ab857fdab135880b468e"
}

# curl -sS -X POST -H "${header}" -d "${json}" ${apiurl} | jq
{
  "jsonrpc": "2.0",
  "result": [
    {
      "hostid": "10084",
      "host": "Zabbix server"
    },
    {
      "hostid": "10261",
      "host": "t3013qnap"
    },

~(以下略)~

ホスト登録をしてみよう

今度はホストを登録するため、host.createメソッドを使ってZabbix APIを実行してみよう。今回は以下ホストを追加する。なお、以下設定項目はホスト作成時にすべて必須となる項目となる。
設定項目 Zabbix APIのパラメータ
ホスト名 Test Server "host": "Test Server"
ホストグループ Discovered hosts "groups": {"groupid": "5"}
インターフェース種別 エージェント "type": 1
標準インターフェース Yes "main": 1
接続方法 IPアドレス "useip": 1
IP 192.168.11.120 "ip": "192.168.11.120"
DNS名 なし "dns": ""
ポート 10050 "port": "10050"
ホストをホストグループに追加する場合は、ホストグループ名ではなくIDが必要となる。そのため、まずはhostgroup.getメソッドを使ってDiscovered hostsグループのIDを調べることにする。
# json='{"jsonrpc": "2.0","method": "hostgroup.get","params": {"output": ["groupid","name"],"filter": {"name": "Discovered hosts"}},"id": 2,"auth": "'$zbxauth'"}'
# echo $json | jq
{
  "jsonrpc": "2.0",
  "method": "hostgroup.get",
  "params": {
    "output": [
      "groupid",
      "name"
    ],
    "filter": {
      "name": "Discovered hosts"
    }
  },
  "id": 2,
  "auth": "4c6e0aedc3b0ab857fdab135880b468e"
}

# curl -sS -X POST -H "${header}" -d "${json}" ${apiurl} | jq
{
  "jsonrpc": "2.0",
  "result": [
    {
      "groupid": "5",
      "name": "Discovered hosts"
    }
  ],
  "id": 2
}
groupidが5であることがわかった。

次に、ホスト登録をhost.createメソッドを使って実施する。
# json='{"jsonrpc": "2.0","method": "host.create","params": {"host": "Test Server","groups": {"groupid": "5"},"interfaces": {"type": 1,"main": 1,"useip": 1,"ip": "192.168.11.120","dns": "","port": "10050"}},"id": 3,"auth": "'$zbxauth'"}'
# echo $json | jq
{
  "jsonrpc": "2.0",
  "method": "host.create",
  "params": {
    "host": "Test Server",
    "groups": {
      "groupid": "5"
    },
    "interfaces": {
      "type": 1,
      "main": 1,
      "useip": 1,
      "ip": "192.168.11.120",
      "dns": "",
      "port": "10050"
    }
  },
  "id": 3,
  "auth": "4c6e0aedc3b0ab857fdab135880b468e"
}

# curl -sS -X POST -H "${header}" -d "${json}" ${apiurl} | jq
{
  "jsonrpc": "2.0",
  "result": {
    "hostids": [
      "10269"
    ]
  },
  "id": 3
}
GUIからも正常にホストが追加されていることが確認できた。


認証トークンを削除しよう

認証トークンは利用が終わったら、きちんとログオフして利用できないようにしておこう。ログオフはuser.logoutメソッドを利用する。
# json='{"jsonrpc": "2.0","method": "user.logout","params": [],"id": 4,"auth": "'$zbxauth'"}'
# echo $json | jq
{
  "jsonrpc": "2.0",
  "method": "user.logout",
  "params": [],
  "id": 4,
  "auth": "4c6e0aedc3b0ab857fdab135880b468e"
}

# curl -sS -X POST -H "${header}" -d "${json}" ${apiurl} | jq
{
  "jsonrpc": "2.0",
  "result": true,
  "id": 4
}
resultキーがtrueとなっていれば正常にログオフできている。これで再度Zabbix APIを実行しても「Session terminated」と表示され、実行できなくなる。
# json='{"jsonrpc": "2.0","method": "host.get","params": {"output": ["hostid","host"]},"id": 2,"auth": "'$zbxauth'"}'
# curl -sS -X POST -H "${header}" -d "${json}" ${apiurl} | jq
{
  "jsonrpc": "2.0",
  "error": {
    "code": -32602,
    "message": "Invalid params.",
    "data": "Session terminated, re-login, please."
  },
  "id": 2
}

まとめ

以上でZabbix APIの使い方の説明は終了となる。今回は初歩の内容ではあったが、使いこなせるようになれば、複数台のホスト追加や設定変更作業などが効率よく実施できるようになるだろう。

なお、Zabbix APIは、公式ドキュメントに利用メソッドや利用例などがまとめられている。マニュアルを見ながら、有用な機能をどんどん使えるようにしていきたい。

更新履歴

  • 2019/2/13 新規作成
  • 2021/2/14 送信するJSON形式のデータ構文の説明と、各送信データをjqコマンドで整形した結果を追記
2021年2月8日月曜日

WSFC / MSFC入門 (Windows Serverのクラスターでファイルサーバーを構築する)


Windows Serverでクラスター構成を行う場合、OS標準の機能であるWSFC (Windows Server Failover Clustering)、別名MSFC (Microsoft Failover Clustering)を使うことが鉄板だろう。クラスターというと、とっつきにくいイメージがあるかもしれないが、一度構築をしてみればそこまで難しいものではない。

本記事では、Windows Server 2016のWSFCを使って、クラスター構成のファイルサーバーを構築する手順を記載するなお、Windows Server 2019であっても、クラスター構成の手順は本記事に記載する手順と大きく変わらないことを確認している。

WSFCの呼び方は複数ある

余談だが、WSFCはOSや時期によって名前が変わってきており、以下のようになっている。
  • MSCS : Windows Server 2003 R2以前
  • WSFC / MSFC : Windows Server 2008 以降

Windows Server 2012 R2のGUI上では、カタカナでフェールオーバークラスターと表記されていたりする。Microsoftのサイトを見る限りでは、WSFCが公式な略称として使用されているようだ。

本記事では、WSFCで記載を統一することにする。

WSFCの前提条件と今回の構成

WSFCを構成する上での前提条件を以下に記載する。
  • 同一ドメインに所属すること、すなわちActive Directoryのドメインコントローラーが必要
  • クラスター用にVIPが1つ、アプリケーション用にVIPが1つ必要
  • クラスター通信用のネットワークは2つ用意することが推奨 (必須ではないが可用性の観点からネットワークの冗長構成が推奨)
  • アプリケーション用に共有ディスクが必要 (今回はiSCSIで構築)
  • クォーラムディスク用に1GB程度の共有ディスクの用意を推奨 (今回はiSCSIで構築)

なお、Windows Server 2016以降でWSFCを構成する場合、ドメインコントローラーが必須ではなくなっている (条件・制約あり)。本記事では説明しないが、詳細は以下のURLを参照いただきたい。

条件をふまえて、今回のサーバー構成は以下の通りとした。

それでは、上記を構成する手順を順に追っていこう。

WSFC構成手順

1. 共有ディスクをマウント・フォーマット

2台のノードで共有するディスクをあらかじめ片方のノードにてマウントし、NTFSでフォーマットをしておく。今回はiSCSIのディスクをマウントしているが、マウントする手順は別記事を参照すること。

ディスクマウント後は以下のようになる。Eドライブをクラスター用の共有ディスクとし、1GBのドライブはクォーラム監視用に使用する。クォーラム用のディスクにドライブレターは不要となる(ドライブレターを付けても問題はない)。

2. フェールオーバークラスタリングの機能を追加

「サーバーマネージャー」の「役割と機能の追加」→「機能の選択」画面にて、「フェールオーバークラスタリング」を両方のノードに追加する。ここは特に難しい設定はなく、ひたすら次へを押していけばよい。
※ちなみに、Windows Serverでは「フェイルオーバー」ではなく「フェールオーバー」と表記されているので注意。

「フェールオーバークラスタリング」選択時に「リモートサーバ管理ツール」の追加確認が表示されるので、「機能の追加」を選択しておく。

フェールオーバークラスタリングの機能追加後、「再起動が保留になっています」のメッセージが表示される場合は、ノードの再起動を実施する。

3. フェールオーバークラスターマネージャーの起動

「サーバーマネージャー」の「ツール」から「フェールオーバークラスターマネージャー」を選択する。

4. クラスターの構成の検証

左ペインの「フェールオーバークラスターマネージャー」を右クリックし、「構成の検証」を選択する。「構成の検証」では、クラスターを組むにあたって、必要な前提条件の確認を一通り検証してくれる。また、「構成の検証」は、必ず一度は実施しなければ、クラスターの作成を行うことができない


「サーバーまたはクラスターの選択」では、クラスターを構成するノードのホスト名を「名前の入力」欄に記載してEnterを押すことで、構成の検証対象のノードを追加できる。今回クラスターに組み込むノードを2台追加する。

「テストオプション」では「すべてのテストを実行する (推奨)」を選択する。

「構成の検証」が始まるので、しばらく待つ。環境にもよるが10分程度で検証は完了する。

終了後に、「レポートの表示」ボタンを押すことで、ブラウザで表示可能なレポートを出力することができる。「カテゴリ別の結果」が、すべて「成功」となっていることを確認しておこう。


5. クラスターの作成

検証が終わったら、再度、左ペインの「フェールオーバークラスターマネージャー」を右クリックし、「クラスターの作成」を選択する。

「サーバーの選択」では、「構成の検証」と同様、クラスターに組み込むノードを2台追加する。

「クラスター管理用のアクセスポイント」では、WSFC管理用のVIPとなるクラスター名とIPアドレスを設定する。ここで設定したクラスター名とIPアドレスは、Active Directory及びDNSに登録される。

「確認」で表示される「使用可能な記憶域をすべてクラスターに追加する」は、チェックしたままとする。これによって、WSFCを構成するノードで共有されているディスクが自動的にクラスターディスクとして追加され、さらには最も容量が小さいディスクがクォーラムディスクとして設定される

クラスターの作成終了後に、「レポートの表示」ボタンを押すことで、ブラウザで表示可能なレポートを出力することができる。特に警告なく完了していることを確認しておこう。


6. クラスターディスクの確認

左ペインの「フェールオーバークラスターマネージャー」→「クラスター名」→「記憶域」→「ディスク」を選択し、クラスターの作成時にディスクが追加されていることを確認する。

20GBのディスクの適用先が「使用可能記憶域」、1GBのディスクの適用先が「クォーラム内のディスク監視」となっていれば想定通りとなる。

追加されたディスクは、デフォルトではディスクの名前が「クラスター ディスク X」という名前となっており判別しづらいので、右クリック→「プロパティ」から名前を変更しておくと管理が楽になる。
※今回は検証目的だったので、そのままの名前で進めることにする。

7. ファイルサーバーの役割を追加

クラスターの役割として、「ファイルサーバー」を構成することにする。まず、「サーバーマネージャー」の「役割と機能の追加」→「役割の選択」画面にて、「ファイルサーバー」を追加しておく。

その後、「フェールオーバークラスターマネージャー」→「クラスター名」→「役割」を右クリックし、「役割の構成」を選択する。

「役割の選択」では「ファイルサーバー」を選択する。

「ファイルサーバーの種類」では「汎用ファイルサーバー」を選択する。

「クライアントアクセスポイント」では、CIFSによるファイルサーバーアクセス用のVIPとなる名前とIPアドレスを設定する。ここで設定した名前とIPアドレスは、Active Directory及びDNSに登録される。

「記憶域の選択」では、ファイルサーバーとして使用する共有ディスクを選択する。

役割の構成終了後に、「レポートの表示」ボタンを押すことで、ブラウザで表示可能なレポートを出力することができる。特に警告なく完了していることを確認しておこう。


以上にて、構成された役割の「リソース」タブを選択すると、VIP (サーバー名)、共有ディスク (記憶域)、ファイルサーバーサービス (ファイルサーバー)の3つが、クラスターリソースとして構成されていることがわかる。

8. フェールオーバーの動作確認

動作確認のため、実際にフェールオーバーさせてみよう。まずは、事前に共有ディスクにアクセスできることを確認しておく。確認用に、テキストファイルを1つ作成する。作成時点のタイムスタンプは15:52となっている。


現在ファイルサーバーの役割が動作しているノード「t1121wind」のOSをシャットダウンさせ、フェールオーバーを発生させる。先ほどまで所有者ノードが「t1121wind」だったものが、「t1122wind」に自動でフェールオーバーしていることがわかる。

フェールオーバー後も、共有ディスクに問題なくアクセスすることができることを確認する。さらに、作成しておいたテキストファイルに追記を行うと問題なく書き込みも成功し、タイムスタンプが15:59に更新されることを確認できた。

まとめ

以上でクラスターの構成は終了となる。実際は細かい設定 (エラー時の再起動の試行回数や、各クラスターリソースの依存関係の設定)など、各種チューニング要素はあるものの、比較的少ない手順でクラスターを組むことができた。

更新履歴

  • 2017/6/7 新規作成
  • 2021/2/9 Windows Server 2016のWSFC構築手順に全面的に内容を更新。クラスターの役割を汎用アプリケーションからファイルサーバーに変更して手順を更新
2021年2月7日日曜日

Windowsのライセンス認証を最速で実施する方法

Windows OSをインストールした後は、インターネット経由でライセンス認証を実施する必要がある。インターネットに接続されている環境であればライセンス認証は自動で実施されるので、通常は意識する必要はないが、プロキシサーバを経由させる場合や、明示的にライセンス認証を手動で実施したい場合がある。

本記事でWindows OSのライセンス認証をコマンドを使って最速で実施する手順を紹介しよう。

プロキシを設定

インターネットを接続する際にプロキシが存在する環境の場合は、プロキシ設定を行う。「コントロールパネル」→「インターネットオプション」で選ぶものとは別の設定となるので注意。

PowerShellを「管理者として実行」で開き、現在のプロキシ設定の確認を行う。
PS C:\> netsh winhttp show proxy

現在の WinHTTP プロキシ設定:

    直接アクセス (プロキシ サーバーなし)。


以下コマンドで、プロキシを設定する。今回はプロキシサーバのIPアドレスが「192.168.33.23」、ポート番号が「8080」でプロキシを設定する。
PS C:\> netsh winhttp set proxy 192.168.33.23:8080

現在の WinHTTP プロキシ設定:

    プロキシ サーバー:  192.168.33.23:8080
    バイパス一覧     : (なし)


ライセンス認証

引き続き、PowerShellにてライセンス認証を行う。

まずライセンスキー登録を行う。Windowsを評価版として動作させる場合は、ライセンスキーは不要となるので、本手順はスキップすること。
PS C:\> cscript.exe C:\Windows\System32\slmgr.vbs -ipk *****-*****-*****-*****-*****

以下コマンドでライセンス認証を行う。数秒待機し、「製品は正常にライセンス認証されました。」と表示されればOK。
PS C:\> cscript.exe C:\Windows\System32\slmgr.vbs -ato
Microsoft (R) Windows Script Host Version 5.812
Copyright (C) Microsoft Corporation. All rights reserved.

Windows(R), ServerStandardEval edition (9dfa8ec0-7665-4b9d-b2cb-bfc2dc37c9f4) のライセンス認証を実行中...
製品は正常にライセンス認証されました。

なお、直接slmgr.vbs -atoを実行すると、出力結果がGUIで表示される。

以下コマンドでライセンス認証後の認証状況を確認してみよう。「ライセンスの状態: ライセンスされています」と表示されており、正常にライセンス認証されていることがわかる。また、今回は評価版としてライセンス認証を行ったため、「時間単位のライセンス認証の有効期限」が設定されている。
PS C:\> cscript.exe C:\Windows\System32\slmgr.vbs -dlv
Microsoft (R) Windows Script Host Version 5.812
Copyright (C) Microsoft Corporation. All rights reserved.

ソフトウェア ライセンス サービス バージョン: 10.0.14393.351

名前: Windows(R), ServerStandardEval edition
説明: Windows(R) Operating System, TIMEBASED_EVAL channel
ライセンス認証 ID: 9dfa8ec0-7665-4b9d-b2cb-bfc2dc37c9f4
アプリケーション ID: 55c92734-d682-4d71-983e-d6ec3f16059f
拡張 PID: 03612-03780-000-000000-00-1041-14393.0000-0372021
プロダクト キー チャネル: Retail:TB:Eval
インストール ID: 073312088314754653800143923379112311537421525494406374512623523
使用ライセンス URL: https://activation-v2.sls.microsoft.com/SLActivateProduct/SLActivateProduct.asmx?configextension=Ret
ail
検証 URL: https://validation-v2.sls.microsoft.com/SLWGA/slwga.asmx
プロダクト キーの一部: TVKQ6
ライセンスの状態: ライセンスされています ★
時間単位のライセンス認証の有効期限: 259200 分 (180 日) ★
残りの Windows 猶予期限リセット可能回数: 6
残りの SKU 猶予期限リセット可能回数: 6
信頼された時間: 2021/02/07 6:16:22

なお、直接slmgr.vbs -dlvを実行すると、出力結果がGUIで表示される。

最後に設定したプロキシを解除すれば、作業は完了となる。
PS C:\> netsh winhttp reset proxy

現在の WinHTTP プロキシ設定:

    直接アクセス (プロキシ サーバーなし)。

まとめ

最後に、今回実施したライセンス認証に必要なコマンドを以下にまとめておく。
netsh winhttp show proxy
netsh winhttp set proxy [プロキシサーバのIPアドレス]:[プロキシサーバのポート番号]
cscript.exe C:\Windows\System32\slmgr.vbs -ipk *****-*****-*****-*****-*****
cscript.exe C:\Windows\System32\slmgr.vbs -ato
cscript.exe C:\Windows\System32\slmgr.vbs -dlv
netsh winhttp reset proxy

更新履歴

  • 2019/2/6 新規作成
  • 2021/2/7 ライセンス認証時にCLIの出力結果を得られるようコマンド修正。また、プロキシをリセットする手順を追加
2021年2月4日木曜日

Red Hat Developer Subscriptionを取得して、RHELをサブスクリプション登録・登録解除する方法

Red Hat Enterprise Linux (以下、RHEL) は、商用使用する場合はサブスクリプションの購入が必要となるが、開発目的であれば「Red Hat Developer Subscription」と呼ばれるサブスクリプションを取得することで、無償利用することができた。

2020年12月に、このRed Hat Developer Subscriptionの利用規約に改正があり、開発環境だけでなく本番環境であっても、最大16台までRHELを使えるようになった

最近、CentOSを使っていたためRHELを積極的に使うことはなかったのだが、16台を無償で使えるようになったことは魅力的ではあるので、再度「Red Hat Developer Subscription」を取得する手順を確認した。また、RHEL 8にてsubscription-managerを使ってサブスクリプションの登録・登録解除の手順も確認した

以下に確認した手順を記載する。

環境

  • OS : RHEL 8.3

Red Hat Developer Subscription取得手順

1. Red Hat Developerのサイトにアクセス

まずは、以下のRed Hat Developerのサイトにアクセスする。

2. Red Hatアカウントの登録

ページ下部にある「Join Red Hat Developer」のボタンを選択して、アカウント登録を行う。

Red Hatアカウント作成時は、以下が必須項目となるので、入力後「アカウントを作成します。」のボタンを選択する。

  • ユーザー名 : 任意の名前を指定。メールアドレスと同一でも可
  • メールアドレス : メール確認が可能なアドレスを登録
  • 職務内容 : 自身の職務に近い内容を選択。私はEngineerを選択した
  • パスワード : 任意で設定
  • 契約条件への同意チェック (2箇所)

登録したメールアドレスに確認用のメールが届いているはずなので、確認用リンクをクリックして、登録を完了させる。

3. Customer Portalのサイトにアクセス

サブスクリプションの確認は以下Customer Portalのサイトで確認できる。

ただし、初回は登録したアカウントの詳細情報を設定する必要があるため、「Update Your Account」の画面に遷移する。ここでは以下必須項目を入力する。

  • Account Type : Personal
  • Password : 再度パスワードを入力
  • Confirm Password : 再度パスワードを入力
  • Contact Information : 氏名や住所を入力


問題なく登録が終わると、以下のCustomer Portalが表示されるようになる。

4. サブスクリプションの確認

Customer Portalの「サブスクリプション」タブを選択すると、「Red Hat Developer Subscription」が表示され、「エンタイトルメントの使用率」を見ると「Available 16」と表示されており、本サブスクリプションで16台分の利用が可能であることを確認できる。

subscription-managerを使ったサブスクリプション割り当て手順

1. 事前確認

サブスクリプション登録前後での動作確認をするため、まずはサブスクリプション登録前にdnfが使えないことを確認する。

以下の通り、「This system is not registered to Red Hat Subscription Management. You can use subscription-manager to register.」のメッセージが表示されdnfコマンドが失敗する。

# dnf check-update
Updating Subscription Management repositories.
Unable to read consumer identity

This system is not registered to Red Hat Subscription Management. You can use subscription-manager to register.

エラー: "/etc/yum.repos.d", "/etc/yum/repos.d", "/etc/distro.repos.d" には有効化されたリポジトリーがありません。

サブスクリプションの登録・確認・登録解除は、subscription-managerコマンドで実施する。まずはsubscription-manager listで登録前の状態を確認すると、状態が「不明」となっている。

# subscription-manager list
+-------------------------------------------+
    インストール済み製品のステータス
+-------------------------------------------+
製品名:           Red Hat Enterprise Linux for x86_64
製品 ID:          479
バージョン:       8.3
アーキテクチャー: x86_64
状態:             不明
状態の詳細:
開始:
終了:

2. Red Hatアカウントを登録

サブスクリプション登録の前に、対象のRed Hatアカウントの登録を行う必要がある。subscription-manager registerで以下の通りユーザ名、パスワードを入力して登録を行う。

# subscription-manager register --username='USERNAME' --password='PASSWORD'
登録中: subscription.rhsm.redhat.com:443/subscription
このシステムは、次の ID で登録されました: 12345678-XXXXXXXXXXXX
登録したシステム名: localhost.localdomain

subscription-manager listで確認すると、状態が「サブスクライブなし」と変化する。

# subscription-manager list
+-------------------------------------------+
    インストール済み製品のステータス
+-------------------------------------------+
製品名:           Red Hat Enterprise Linux for x86_64
製品 ID:          479
バージョン:       8.3
アーキテクチャー: x86_64
状態:             サブスクライブなし
状態の詳細:       Not supported by a valid subscription.
開始:
終了:

3. プールIDを確認

次に登録対象のサブスクリプションを確認する。subscription-manager list --availableにてすべての利用可能なサブスクリプションが表示される。ここでは、「Red Hat Developer Subscription」が表示されることと、そのサブスクリプションのプールIDを確認しておく (★箇所)。

# subscription-manager list --available
+-------------------------------------------+
    利用可能なサブスクリプション
+-------------------------------------------+
サブスクリプション名:     Red Hat Developer Subscription ★
提供:                     dotNET on RHEL Beta (for RHEL Server)
                          Red Hat CodeReady Linux Builder for x86_64

~(中略)~

契約:
プール ID:                XXXXXXXX ★
管理の提供:               いいえ
数量:                     16
推奨:                     1
サービスタイプ:
ロール:
サービスレベル:           Self-Support
使用方法:
アドオン:
サブスクリプションタイプ: Standard
開始:                     2021年01月24日
終了:                     2022年01月24日
エンタイトルメントタイプ: 物理

登録に必要な情報はプールIDとなるので、--pool-onlyオプションを付与することで、表示を簡略化することもできる。

# subscription-manager list --available --pool-only
XXXXXXXX

4. サブスクリプションを登録

先ほど確認したプールIDを指定して、subscription-manager attachにてサブスクリプションの登録を行う。
subscription-manager subscribeでもサブスクリプションの登録が可能だが、subscribeは廃止予定のコマンドとなっているので、必ずattachにて実施すること。

# subscription-manager attach --pool XXXXXXXX
サブスクリプションが正しく割り当てられました: Red Hat Developer Subscription

subscription-manager listで確認すると、状態が「サブスクライブ済み」となっていれば問題ない。

# subscription-manager list
+-------------------------------------------+
    インストール済み製品のステータス
+-------------------------------------------+
製品名:           Red Hat Enterprise Linux for x86_64
製品 ID:          479
バージョン:       8.3
アーキテクチャー: x86_64
状態:             サブスクライブ済み
状態の詳細:
開始:             2021年01月24日
終了:             2022年01月24日

5. 事後確認

この状態でRed HatのCustomer Portalのサイトの状態を確認すると、登録されていたシステムが表示されるようになる。

最後にdnfによるパッケージの確認ができることを確認する。先ほどのエラーは表示されず、アップデート可能なパッケージ一覧が表示されていることがわかる。

# dnf check-update
Updating Subscription Management repositories.
Red Hat Enterprise Linux 8 for x86_64 - BaseOS   28 MB/s |  27 MB     00:00
Red Hat Enterprise Linux 8 for x86_64 - AppStre  20 MB/s |  25 MB     00:01

NetworkManager.x86_64     1:1.26.0-12.el8_3        rhel-8-for-x86_64-baseos-rpms
NetworkManager-libnm.x86_64
                          1:1.26.0-12.el8_3        rhel-8-for-x86_64-baseos-rpms
NetworkManager-team.x86_64
                          1:1.26.0-12.el8_3        rhel-8-for-x86_64-baseos-rpms

~(以下略)~

subscription-managerを使ったサブスクリプション登録解除手順

1. サブスクリプションを登録解除

サブスクリプションの登録解除は、subscription-manager removeにて実施する。
subscription-manager unsubscribeでもサブスクリプションの登録解除が可能だが、unsubscribeは廃止予定のコマンドとなっているので、必ずremoveにて実施すること。

# subscription-manager remove --all
1 件のローカル証明書が削除されました。
サーバーで 1 件のサブスクリプションが削除されました。

2. Red Hatアカウントを登録解除

Red Hatアカウントの登録解除は、subscription-manager unregisterにて実施する。

# subscription-manager unregister
登録の解除中: subscription.rhsm.redhat.com:443/subscription
システムの登録は解除されました。

subscription-manager listで確認すると、状態が「不明」の状態に戻っているはずだ。

# subscription-manager list
+-------------------------------------------+
    インストール済み製品のステータス
+-------------------------------------------+
製品名:           Red Hat Enterprise Linux for x86_64
製品 ID:          479
バージョン:       8.3
アーキテクチャー: x86_64
状態:             不明
状態の詳細:
開始:
終了:

3. 事後確認

この状態でRed HatのCustomer Portalのサイトの状態を確認すると、登録されていたシステムが削除され表示されなくなる。

参考

人気の投稿