2023年4月29日土曜日

AnsibleでWindows Updateを操作する

自宅ではAnsibleを導入してから、各種自動化を進めている。

今回は、Ansibleを使ってWindows Updateを操作するための手順を記載する。

環境

今回手順を確認した環境は以下の通り。

  • コントロールノード
    • OS : AlmaLinux 8.5
    • Ansible : ansible [core 2.13.1]
  • 操作対象サーバ
    • OS : Windows Server 2016

cronを操作するPlaybook

AnsibleにおけるWindows Updateの操作は、ansible.windows.win_updatesモジュールにて行う。

AnsibleからWindows Serverに接続するための事前作業

Ansibleを使ってWindows OSを操作する場合、事前にpywinrmのインストールや、WinRMの有効化などの準備作業が必要となる。必要な手順は、過去の記事でまとめてあるので参照いただきたい。

以下にPlaybookの内容を説明する。

Playbook説明

変数 (vars)

変数 設定値
ansible_user 操作対象サーバに接続する際に使用するユーザ名を指定。
ansible_password 操作対象サーバに接続する際に使用するユーザ名のパスワードを指定。
ansible_port WinRMの5986ポートを指定。
ansible_connection winrmを指定。
ansible_winrm_server_cert_validation ignoreを指定し、WinRM接続時の証明書検証を無視する。

タスク及びハンドラー (tasks / handlers)

今回のPlaybookのタスクは以下となる。主役はansible.windows.win_updatesとなり、Windows Update後の再起動をハンドラーで実行している。

OS再起動は、ansible.windows.win_updatesにおいても処理はさせることは可能となる(rebootreboot_timeoutのパラメータで設定できる)。もっとシンプルに作りたい場合は、そちらを利用してもよいだろう。

タスク モジュール 説明
Windowsアップデート ansible.windows.win_updates Windows Updateを行う。category_namesで対象とする更新プログラムのカテゴリを選択する。インストールする場合は、state: installedを設定し、インストールせず確認だけしたい場合は、state: searchedを指定する。
結果表示 ansible.builtin.debug Windows Updateの結果を表示する。これによって、適用されたHotfixのKB番号などを確認できる。
再起動 ansible.windows.win_reboot Windows Updateが実行された場合、OSの再起動を行う。
再起動後の待機 ansible.builtin.wait_for_connection OS再起動後に、Ansibleから接続可能となるまで待機する。

Playbook

以上をふまえ、Playbook全体は以下となる。カテゴリはSecurityUpdatesのみとした。

update_windows_server.yml

---
- name: Setup windows server
  gather_facts: true
  hosts: windows_servers

  vars:
    ansible_user: ansibleuser
    ansible_password: XXXXXXXX
    ansible_port: 5986
    ansible_connection: winrm
    ansible_winrm_server_cert_validation: ignore

  tasks:
    # Windowsアップデート
    - name: Update windows
      ansible.windows.win_updates:
        category_names:
          - SecurityUpdates
          # - CriticalUpdates
          # - UpdateRollups
        state: installed
      register: result
      notify:
        - Reboot
        - Wait for reboot

    # 結果表示
    - name: Show result
      ansible.builtin.debug:
        msg: "{{ result }}"

  handlers:
    # 再起動
    - name: Reboot
      ansible.windows.win_reboot:
      when: result.reboot_required

    # 再起動後の待機
    - name: Wait for reboot
      ansible.builtin.wait_for_connection:
        delay: 5
        timeout: 120

実行結果

Playbookの実行結果は以下の通り。結果として、「2023-04 x64 ベース システム用 Windows Server 2016 の累積更新プログラム (KB5025228)」が適用されていることがわかる。

# ansible-playbook -i hosts -l win2016 windows/update_windows_server.yml 

PLAY [Setup windows server] *************************************************************************************************************************************************************************************************

TASK [Gathering Facts] ******************************************************************************************************************************************************************************************************
ok: [win2016]

TASK [Update windows] *******************************************************************************************************************************************************************************************************
changed: [win2016]

TASK [Show result] **********************************************************************************************************************************************************************************************************
ok: [win2016] => {
    "msg": {
        "changed": true,
        "failed": false,
        "failed_update_count": 0,
        "filtered_updates": {
            "481f5459-70d6-456f-82ff-670f3b1e328a": {
                "categories": [
                    "Definition Updates",
                    "Microsoft Defender Antivirus"
                ],
                "downloaded": false,
                "filtered_reason": "category_names",
                "filtered_reasons": [
                    "category_names"
                ],
                "id": "481f5459-70d6-456f-82ff-670f3b1e328a",
                "installed": false,
                "kb": [
                    "2267602"
                ],
                "title": "Microsoft Defender Antivirus のセキュリティ インテリジェンス更新プログラム - KB2267602 (バージョン 1.387.1907.0)"
            },
            "fc5ae207-e126-4617-a7a5-8e2b05f690ef": {
                "categories": [
                    "Update Rollups",
                    "Windows Server 2016",
                    "Windows Server 2019"
                ],
                "downloaded": false,
                "filtered_reason": "category_names",
                "filtered_reasons": [
                    "category_names"
                ],
                "id": "fc5ae207-e126-4617-a7a5-8e2b05f690ef",
                "installed": false,
                "kb": [
                    "890830"
                ],
                "title": "悪意のあるソフトウェアの削除ツール x64 - v5.112 (KB890830)"
            }
        },
        "found_update_count": 1,
        "installed_update_count": 1,
        "reboot_required": true,
        "updates": {
            "97ab5eba-74ba-4d85-8a5e-28db67733520": {
                "categories": [
                    "Security Updates",
                    "Windows Server 2016"
                ],
                "downloaded": true,
                "id": "97ab5eba-74ba-4d85-8a5e-28db67733520",
                "installed": true,
                "kb": [
                    "5025228"
                ],
                "title": "2023-04 x64 ベース システム用 Windows Server 2016 の累積更新プログラム (KB5025228)"
            }
        }
    }
}

RUNNING HANDLER [Reboot] ****************************************************************************************************************************************************************************************************
changed: [win2016]

RUNNING HANDLER [Wait for reboot] *******************************************************************************************************************************************************************************************
ok: [win2016]

PLAY RECAP ******************************************************************************************************************************************************************************************************************
win2016                  : ok=5    changed=2    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0   

再起動後、OS上でも正常に更新プログラムが適用されていることが確認できた。

以上で、Ansibleを使ってWindows Updateを操作するための手順は完了となる。

2023年4月16日日曜日

WindowsのSSHクライアントを使ってSSHトンネルする

SSHにはSSHトンネル(SSHポートフォワーディングとも呼ぶ)と呼ばれる機能があり、これを用いると接続先のSSHサーバを経由させて別のサーバにアクセスができるようになる。

SSHトンネルを用いることで、いわゆる踏み台サーバ(Jump Server)のみにSSH接続ができる環境において、踏み台サーバーを経由して直接背後のWindows ServerやWebアプリにアクセスができるようになる。

なお、SSHトンネルはTera Termの「SSHポート転送」からも実施することができるがGUIが操作が面倒だ。

本記事では、Windows標準のSSHクライアントを用いて、SSHトンネルするための手順を記載する。

環境

今回の手順を確認したOSは以下の通り。

  • SSHクライアント側
    • OS : Windows Server 2019
  • SSHサーバ側
    • OS : AlmaLinux 8.5

今回は以下図の通り、SSHサーバを経由して、Windows ServerへRDP接続とWebアプリへの接続ができることを確認してみる。

SSHトンネル手順

1. SSH接続時にSSHトンネルのオプションを指定

SSHトンネルを行う際は、-Lオプションを以下構文のように利用する。

ssh [ユーザ名]@[SSHサーバ] -L [ローカルポート]:[接続先サーバ]:[リモートポート]
※接続先が複数ある場合は、-Lオプションを複数指定する。

今回は以下コマンドを実行する。

PS C:\Users\winuser> ssh testuser@192.168.11.193 -L 33389:192.168.11.194:3389 -L 30443:192.168.11.161:443

2. 接続確認

SSH接続が成功すれば、SSHトンネル経由での接続ができるようになっている。SSHトンネル経由で接続する場合は、localhostまたは127.0.0.1に対して接続する。

SSHトンネル経由でRDP接続

「リモートデスクトップ接続」を起動し、localhost:33389で接続する。

以下の通り、問題なくリモートデスクトップ接続できた。

SSHトンネル経由でWebアプリ接続

ブラウザを開き、https://localhost:30443/で接続すると、以下の通り、問題なくブラウザでWebアプリ(今回はESXiのログイン画面)が表示された。

以上で、Windows標準のSSHクライアントを用いて、SSHトンネルするための手順は完了となる。

2023年4月9日日曜日

WindowsのSSHクライアントを使って公開鍵認証方式で接続する

Windows 10やWindows Server 2016以降のOSには、SSHクライアントがデフォルトでインストールされており、LinuxなどへSSH接続やSFTPなどによるファイル授受をする際に活用できる。

SSHはOpenSSHにて実装されており、パスワード認証だけでなく公開鍵認証を用いた接続もできる。

本記事では、WindowsのSSHクライアントを使って、公開鍵認証で接続する手順を記載する。

環境

今回の手順を確認したOSは以下の通り。

  • SSHクライアント側
    • OS : Windows Server 2019
    • ユーザ名 : winuser
  • SSHサーバ側
    • OS : AlmaLinux 8.5
    • ユーザ名 : testuser

公開鍵認証による接続手順

1. WindowsのSSHクライアントにて秘密鍵と公開鍵のペアを作成

公開鍵認証方式では、SSHクライアント側の公開鍵をSSHサーバ側に登録することで実現する。

まずは、WindowsのSSHクライアント側で秘密鍵と公開鍵のペアを作成するため、ssh-keygenコマンドを実行する。3回確認を求められる個所があるが、そのままEnterキーを押してスキップすれば問題ない。

PS C:\Users\winuser> ssh-keygen.exe
Generating public/private rsa key pair.
Enter file in which to save the key (C:\Users\winuser/.ssh/id_rsa):
Created directory 'C:\Users\winuser/.ssh'.
Enter passphrase (empty for no passphrase): ★そのままEnter
Enter same passphrase again: ★そのままEnter
Your identification has been saved in C:\Users\winuser/.ssh/id_rsa.
Your public key has been saved in C:\Users\winuser/.ssh/id_rsa.pub.
The key fingerprint is: ★そのままEnter
SHA256:9TC0QrXmG2Jy/k/dUP5jlontTrGqMJDQfrVKZHxsO1M intrat\winuser@win-server
The key's randomart image is:
+---[RSA 3072]----+
|        ..o      |
|  . . .. . o     |
| . . + =.EB     .|
|  o + + += +   o |
|   + o.=S o.. . .|
|    + .=o. oo..o+|
|     +  . .+...*o|
|      o  .+.o o .|
|       ....+.    |
+----[SHA256]-----+

2. 作成した公開鍵を確認

ssh-keygenで作成すると、ホームディレクトリ配下に、.sshというディレクトリが作成され、以下ファイルが保存される。

  • id_rsa : 秘密鍵
  • id_rsa.pub : 公開鍵

公開鍵の情報が必要となるため以下の通り内容を表示しておく。

PS C:\Users\winuser> cat .\.ssh\id_rsa.pub
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQCiDv+Q71aFBRnrB5WrEbOgIbTpCtTJOBgSnXYQh2YuC7jog+1jvj+j2x+Cyh1zbHLdeTAh4wFNiLkEgLflfS7Vb7REY58TXhr0O/hd++luj5UUXpBbZMJuFxvlQ4COnXDv7p6PTLuy22pdj+oOY1W00cf3tcTVswL271bK+aoXmZwFZzs3NjJiUcjouv6CmoynEobDKPInCxxxtkP12K9y2vLtesytSMw5z6whI4mE6Z+XpPaAPcD1dpwNlOD+tVcocJ1JcGO86cv1Ice3fcJUZghUZ2W+DUY6DFJV578aXI5rPgLbVzIqGt62AokaK61W6R53yvzwNVpkwCvyyyjHcsaxt5NxPVHeQYFmAnkkOYqWkRz47Gt1YVsXsO6y60uDMZ4BriIkJW7SXjSVjNZanOT7QF5huHkoy+o+eJJ3ubMfveVtTVLIiaFzqHsgKUZaIGBOuURT8utcSx7dYOzzzNnz88pp+o7qB/lGqOLxSM447gnXkY3KgibRBn9TzMs= intrat\winuser@win-server

3. SSHサーバ側に公開鍵を登録

SSHサーバ側となるLinuxサーバにログインし、こちらも.sshディレクトリを作成する。なお、すでに作成がされている場合は、以下手順はスキップすること。

[testuser@linux-server ~]$ mkdir .ssh
[testuser@linux-server ~]$ chmod 700 .ssh

.sshディレクトリ内にauthorized_keysというファイルを作成し、先ほど確認したWindowsの公開鍵情報を追記する。

[testuser@linux-server ~]$ vi .ssh/authorized_keys
~(先ほど確認したWindowsの公開鍵情報を追記)~
[testuser@linux-server ~]$ chmod 600 .ssh/authorized_keys

4. 接続確認

以上で設定は完了となる。SSHクライアント側からSSH接続をして確認してみよう。初回接続時は、接続先に問題がいないか確認を求められるためyesを入力しておく。

PS C:\Users\winuser> ssh testuser@192.168.11.193
The authenticity of host '192.168.11.193 (192.168.11.193)' can't be established.
ECDSA key fingerprint is SHA256:onCxxKq7/iPWLneacMTxrBHnAAx46P9dAh1YP/C0Z2Q.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes ★yesを入力
Warning: Permanently added '192.168.11.193' (ECDSA) to the list of known hosts.
Last login: Mon Apr  3 22:02:08 2023 from 192.168.11.81
[testuser@linux-server ~]$

再度接続すると、今度は何も確認を求められることなくSSH接続に成功するはずだ。

PS C:\Users\winuser> ssh testuser@192.168.11.193
Last login: Sat Apr  8 19:33:08 2023 from 192.168.11.81
[testuser@linux-server ~]$

以上で、WindowsのSSHクライアントを使って、公開鍵認証で接続する手順は完了となる。

2023年4月2日日曜日

Ansibleの設定ファイル「ansible.cfg」概要

Ansibleでいくつか実行時の動作を変更することができる。例えば、Playbookを実行する際に、標準出力だけでなくテキストファイルにもログを出力させたりすることができる。

本記事では、Ansibleの設定ファイル「ansible.cfg」について設定方法と設定内容を記載する。

ansible.cfgについて

ansible.cfgの説明は公式のマニュアルにも記載されている。

ansible.cfgは複数の配置場所を選択することができる。以下に配置されているファイルについて上から順に検索され、最初に見つかったansible.cfgの設定のみが反映され、他のファイルの設定は無視される。

  • 環境変数ANSIBLE_CONFIGで指定したパス
  • カレントディレクトリのansible.cfg
  • ホームディレクトリの~/.ansible.cfg
  • /etc配下の/etc/ansible/ansible.cfg

ansible.cfgの生成

ansible.cfgはテキストファイルなので手書きで作成してもよいが、コマンドで初期ファイルを作成することもできる。ただし、1000行以上となる長いファイルとなるため可読性は低いので、どのようなオプションがあるか一覧として表示させる際に利用するなどするとよい。

実行コマンドは以下の通り。

# ansible-config init --disabled -t all > ansible.cfg
# ls -l
合計 56
-rw-r--r-- 1 root root 54413  3月 21 11:21 ansible.cfg

ansible.cfgの設定項目

個人的によく使う設定項目

ansible.cfgの設定値は非常に多くあるが、その中でも個人的によく使う設定値を以下に記載する。

設定項目 説明
display_args_to_stdout Playbookのタスク実行時に、設定したパラメータを表示する。実際の表示例は後述する。
forks 複数のホストに対する処理の同時実行数。デフォルト5台と少なめになっているので、この値を増加させることで処理の高速化が期待できる。
host_key_checking SSH接続時の警告メッセージを無視する設定。例えば、今までSSH接続したことがないホストにSSH接続すると、本当に接続して問題ないか確認する警告メッセージが表示されてしまうが、その警告が出た場合でも接続を続行することができる。
log_path Ansibleの実行ログを出力するログのパスをファイル名まで含め指定する。
nocolor 通常、Ansibleの実行結果は、okが緑、changedが黄色、failedが赤と色付けされて表示がされる。この色付けを無効化したい場合はTrueで設定する。
vault_password_file Ansible Vaultが読み込むパスワードファイルを指定する。

display_args_to_stdout設定時の表示

display_args_to_stdoutを設定しない場合(デフォルト)と設定した場合の表示の違いを以下に記載する。設定した場合は、各タスクの行において設定しているパラメータが表示されていることがわかる。

display_args_to_stdout未設定時(デフォルト)

TASK [Install yum-utils] ****************************************************************************************************************************************************************************************************
ok: [t1051kube]

TASK [Check existence of docker-ce.repo] ************************************************************************************************************************************************************************************
ok: [t1051kube]

display_args_to_stdout設定時

TASK [Install yum-utils name=yum-utils, disablerepo=dvd*, state=present] ****************************************************************************************************************************************************
ok: [t1051kube]

TASK [Check existence of docker-ce.repo _raw_params=ls -l "/etc/yum.repos.d/docker-ce.repo"] ********************************************************************************************************************************
ok: [t1051kube]

ansible.cfg設定例

最後に、ansible.cfg設定例を記載する。display_args_to_stdoutは通常は無効で利用しており、必要な場合のみ有効にすることから、通常はコメントアウトして利用している。

[defaults]
# display_args_to_stdout = True
forks = 20
host_key_checking = False
log_path = /var/log/ansible/ansible_test.log
# nocolor = True
vault_password_file = .vault_pass

Ansibleの設定ファイル「ansible.cfg」に関する説明は以上となる。

人気の投稿