2022年1月29日土曜日

「Windows 11 development environment」をESXi 7.0上に展開する手順

Windows 10の次期OSとして登場したWindows 11は、OSのハードウェア要件が厳しく、古いPCへのインストールはできず、仮想環境などへの導入も困難と思われていた。

しかし、「Windows 11 development environment」を使うとESXi 7.0の仮想マシンとしてWindwos 11を動作させることができる

「Windows 11 development environment」は、Windwos 11に各種開発ツールがインストールされた開発用OSとして、期間限定ではあるが無償提供されている。

今回、「Windows 11 development environment」をESXi 7.0上に展開し、要件を満たしていない環境においてもWindows 11を動作させる手順を記載する。

環境

Windows 11を展開する環境は以下の通り。後述するが、仮想マシンのハードウェアバージョンの関係上、ESXi 7.0 Update 1以降でなければ展開できないため注意すること。

  • vCenter Server 7.0 Update 1d
  • ESXi 7.0 Update 1c

「Windows 11 development environment」展開手順

1. 「Windows 11 development environment」のダウンロード

「Windows 11 development environment」は以下URLからダウンロードできる。

注意事項としては以下となる。

  • 使用できる期間が決まっており、2022年1月時点では「2022年3月4日」が期限となる。おそらく、その期限に近づくと新たなOSイメージ提供されダウンロードできるようになると想定される。
  • OSイメージは、VMware、Hyper-V、VirtualBoxといった各種仮想環境用のファイルをダウンロードできる。
  • OSイメージは20GBもあるので注意!また、zip圧縮されているため、解凍する際も時間と容量を使うため注意。
  • 仮想マシンのハードウェアバージョンはvmx-18となり、ESXi 7.0 U1 (7.0.1) 以降でなければ展開できないので注意。

今回はESXi 7.0上にインストールするため、VMware用のファイルをダウンロードする。20GBもあるので、回線帯域が細い場合は気長にダウンロード完了を待とう。

ダウンロードが完了したzipファイルを解凍を行うと、以下内容となっていた。

  • WinDev2110Eval.mf
  • WinDev2110Eval.ovf
  • WinDev2110Eval-disk1.vmdk

試してはいないが、OVFファイル (.ovf)の中身のハードウェアバージョンを修正し、マニフェストファイル (.mf) のSHA-256のハッシュ値を更新すれば、ひょっとしたらESXi 7.0以前のバージョンにも展開できる可能性はある。

2. ESXi 7.0にOVFテンプレートのデプロイ

vSphere ClientやVMware Host Clientなどを使って、ダウンロードしたOVFファイルをESXi上に展開する。特に通常のOVFテンプレートと同様の手順にて展開すれば問題ない。

3. Windows 11の仮想マシンを起動

展開後、Windows 11の仮想マシンを起動してみると、何事もなくWindows 11のデスクトップが表示される。

vCenter Serverにて確認した仮想マシン情報は以下の通り。Windows 11ではあるが、ゲストOSの種別はWindows 10として扱っているようだ。

以上で、「Windows 11 development environment」をESXi 7.0上に展開する手順は完了となる。

2022年1月22日土曜日

Kickstartを使ってESXiを自動インストールする

自宅でNested ESXiの環境を構築し、vCenter Serverを頻繁にインストールして検証などを行っている。ESXiは設定項目が多くないので、インストール自体はそこまで時間を要するものではないが、効率よくインストールできるよう、Kickstart (キックスタート) を使ってESXiのインストールの自動化を試してみた。

なお、KickstartはRed Hat系のLinuxディストリビューションでも同様の機能を有しており、大まかな使い方としては同じとなるが、細かいところで差異があるので注意。

Red Hat系のLinuxディストリビューションのKickstartの使い方は、以下記事を参照いただきたい。

環境

Kickstartの検証はESXi 6.7上に構築したESXi 6.7 (Nested ESXi) で実施した。注意事項として、Nested ESXiを構築する場合、デフォルトで有効となっているUEFIセキュアブートを無効にすること。UEFIセキュアブートが有効の場合、初回起動後に実行する%firstbootに記載したコマンド実行に失敗するので注意。

Kickstart用のファイルの配置先はQNAP NASを用いることとし、接続プロトコルはNFSを利用する。なお、NFS v4のみ有効にすると失敗するため、必ずNFSサーバ側でNFS v3を有効にすること。

手順

1. Kickstartファイル (ks.cfg) を作成

Kickstartは、インストール情報を定義したKickstartファイルと呼ばれるファイルを読み込ませることで自動インストールを実現する。このファイルは通常ks.cfgというファイル名で作成をするのが一般的となるが、ファイル名は任意で設定して問題ない。

Kickstartファイルは、インストール時に各種設定を定義するためのコマンドやオプションが用意されている。詳細は公式マニュアルを参照いただきたいが、最低限必要となるコマンドについては、以下表にて説明する。

設定項目 設定コマンド 説明
利用規約 (EULA) への同意 vmaccepteula 利用規約への同意を自動で行う設定。
rootパスワード rootpw 平文 (オプションなし) またはハッシュ化 (--iscrypted) した文字列でパスワードを指定できる。ハッシュ化したパスワードは、インストール済みのLinux環境の/etc/shadowから抽出すると楽。
インストール設定 install インストール対象のディスクを選択する設定。--firstdiskでローカルディスクの最初のディスクを選択し、--overwritevmfsで既存のVMFS領域を上書きする。VMFS領域を残したり、そもそも作成しないといったオプションも設定可能。
キーボードレイアウト keyboard キーボードレイアウトを指定。Japaneseを選んでおけば問題ない。
ネットワーク network ホスト名やIPアドレスなどの設定。Red Hat系のnetworkの設定方法と同様となる。
インストール後の動作 reboot インストール後に自動で再起動かける場合に指定。デフォルトで再起動時にDVDのイジェクトが行われるが、イジェクトしない場合は、--noejectを付与する。
初回起動後のコマンド実行 %firstboot ESXiインストール後の初回起動後にコマンドを実行させる。--interpreter=busyboxを付けることで、通常のESXi Shellによるコマンド実行が可能となる。

以下に私が実際に使用しているKickstartファイルを例として記載する。

# Accept the VMware End User License Agreement
vmaccepteula

# Set the root password for the DCUI and Tech Support Mode
rootpw mypassword
#rootpw --iscrypted XXXX~(省略)~XXXX

# Install on the first local disk available on machine
install --firstdisk --overwritevmfs

# Keyboard type
keyboard Japanese

# Set the network
#network --bootproto=dhcp --device=vmnic0
network --bootproto=static --ip=192.168.11.161 --netmask=255.255.255.0 --gateway=192.168.11.31 --nameserver=192.168.11.61,192.168.11.62 --device=vmnic0 --hostname=t1161esxi

# Reboot after installation
reboot

%firstboot --interpreter=busybox

# Enable ssh
vim-cmd hostsvc/enable_ssh
vim-cmd hostsvc/start_ssh

# Enable ESXi Shell
vim-cmd hostsvc/enable_esx_shell
vim-cmd hostsvc/start_esx_shell

# Suppress Shell Warning
esxcli system settings advanced set -o /UserVars/SuppressShellWarning -i 1

# Enable NTP
echo 'server 192.168.33.23 iburst' >> /etc/ntp.conf
chkconfig ntpd on
/etc/init.d/ntpd start

# Disable IPv6
esxcli system module parameters set -m tcpip4 -p ipv6=0 

reboot

2. NFSサーバにKickstartファイルを配置

作成したKickstartファイルは、OSインストール時に読み込ませる必要がある。いくつか方式はあるが、今回はNFSサーバにKickstartファイルを配置して、ネットワーク経由で読み込みさせることにする。

NFSサーバの構築は本題とは関係がないため割愛するが、今回はQNAP NASをNFSサーバとして使用することにした。前述したとおり、NFS v4では失敗するためNFS v3を有効にすること。

配置パスは以下となる。Red Hat系とパスの構文が微妙に異なるので注意。

nfs://192.168.11.13/Public2/ks/ks_esxi.cfg

3. OSインストールメディアで起動

通常通りESXiのインストールメディアにて起動し、最初の画面に「Shift + o (シフト + オー)」を押すと、インストールパラメータを指定する画面に遷移する。「Shift + 0 (シフト + ゼロ)」ではないので注意。

4. インストールパラメータでKickstartファイルを指定

インストールパラメータでは、以下の通り、ksのパラメータを追記する。くどいが、Red Hat系とパスの構文が微妙に異なるので注意。

cdromBoot runweasel ks=nfs://192.168.11.13/Public2/ks/ks_esxi.cfg

パラメータ追記後、「Enter」を押してインストールを開始する。

5. 自動インストール開始

Kickstartによる自動インストールが成功した場合は、以下画面のように「Reading installation script」といった表示がされ、自動的にインストールが進むはずだ。

インストール完了後、「ESXi 6.7.0 has been installed successfully」と表示され、少し待つと自動でESXiが再起動する。

6. 初回起動後のスクリプト実行

初回起動後は、%firstbootで指定されたコマンドが実行される。私のKickstartファイルでは、IPv6無効化の反映のために%firstbootの最後にrebootを設定しているため、自動的にESXiが再起動する。

再起動、いつものESXiのDCUIが表示されればインストール完了となる。

7. インストール後の確認

インストール完了後、SSHでログインし以下であることを確認した。Kickstartにより問題なく初期設定がされていることが確認できた。

  • SSHが有効化されていること
  • ESXi Shellが有効化されていること
  • SuppressShellWarningが1で設定されていること
  • ntpdサービスが起動し、NTPサーバと同期していること
  • IPv6が無効化されていること
[root@t1161esxi:~] chkconfig SSH
SSH                     on

[root@t1161esxi:~] chkconfig ESXShell
ESXShell                on

[root@t1161esxi:~] esxcli system settings advanced list -o /UserVars/SuppressShe
llWarning
   Path: /UserVars/SuppressShellWarning
   Type: integer
   Int Value: 1
   Default Int Value: 0
   Min Value: 0
   Max Value: 1
   String Value:
   Default String Value:
   Valid Characters:
   Description: Don't show warning for enabled local and remote shell access

[root@t1161esxi:~] chkconfig ntpd
ntpd                    on
[root@t1161esxi:~] ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*192.168.33.23   133.243.238.164  2 u   46   64   37    0.428   -0.242   0.617

[root@t1161esxi:~] esxcli system module parameters list -m tcpip4
Name                 Type  Value  Description
-------------------  ----  -----  --------------------------------
ipportIscsiReserved  int          # of provisioned H/W iSCSI ports
ipv6                 int   0      Enable/Disable IPv6

ここからさらにvCenter Server Appliance (vCSA) もCLIベースでインストールすることで、最短でvSphereの検証環境を構築することができる。vCSAのCLIベースでのインストール手順は、以下を参照いただきたい。

参考

更新履歴

  • 2021/6/1 新規作成
  • 2022/1/22 Kickstartファイルを配置するNFSサーバーはNFS v3を有効にする必要がある旨追記

LinuxでCIFS共有フォルダをマウントする

Linuxでは通常NFSなどでネットワークファイル共有を実現するが、WindowsではCIFSが標準的に使われている。

しかし、場合によってはLinux環境からWindowsのCIFS共有フォルダにアクセスしてファイル読み書きしたい場合がある。

LinuxではCIFSであっても簡単にマウントすることができる。本記事では、Linux環境からWindowsのCIFS共有フォルダをマウントする手順を記載する

環境

  • RHEL : 8.3
  • マウント先 : /mnt
  • CIFS接続先: 192.168.11.13
  • CIFS共有名 : /mount_test

CIFS共有フォルダのマウント手順

1. cifs-utilsパッケージの導入

LinuxでCIFSマウントを行う場合、cifs-utilsパッケージの導入が必要となるのでdnfなどを用いてインストールする。

# dnf install cifs-utils -y

2. CIFS共有フォルダをマウント

CIF共有フォルダのマウントコマンドは以下の通り。

mount -t cifs -o username=[ユーザ名],password=[パスワード] //[CIFS接続先]/[CIFS共有名] [マウントポイント]

今回の環境の場合の実行例を以下に記載する。

# mount -t cifs -o username=user,password=******** //192.168.11.13/mount_test /mnt

マウント結果はmountdfコマンドで確認できる。

# mount
~(省略)~
//192.168.11.13/mount_test on /mnt type cifs (rw,relatime,vers=3.1.1,cache=strict,username=tetsu,uid=0,noforceuid,gid=0,noforcegid,addr=192.168.11.13,file_mode=0755,dir_mode=0755,soft,nounix,serverino,mapposix,rsize=4194304,wsize=4194304,bsize=1048576,echo_interval=60,actimeo=1)

# df -h
ファイルシス               サイズ  使用  残り 使用% マウント位置
~(省略)~
//192.168.11.13/mount_test   2.0T  1.4T  628G   69% /mnt

なお、cifs-utilsパッケージをインストールせずにマウントを試みた場合、以下のようなエラーが表示されマウントに失敗する。

# mount -t cifs -o username=user //192.168.11.13/mount_test /mnt
mount: /mnt: //192.168.11.13/mount_test を読み込み専用でマウントできません.

3. CIFS共有フォルダをアンマウント

CIFS共有フォルダをアンマウントする場合は、通常通りumountコマンドを用いる。

# umount /mnt/

参考

更新履歴

  • 2017/10/20 新規作成
  • 2022/1/22 全面的に書き直し
2022年1月15日土曜日

Ansible AWXをMinikube環境にインストールする

Ansible AWXは、AnsibleのPlaybookをGUIで管理・実行するためのOSS製品となる。商用版はRed Hat Ansible Towerであり、管理対象のホスト数に応じたサブスクリプションが必要となるが、AWXは無償で利用が可能となる。

AWXはいわゆるジョブマネージャーのような機能を備えており、Playbookを決められた時間にスケジュール実行することや、複数のPlaybookの前後関係を定義したうえで順番に実行させることができる。

ただし、Ansible AWXは単純にインストールして使うことができず、Kubernetes環境のコンテナとして実行させる必要があり、インストールするハードルが少し高くなっている。実際、私はKubernetes初心者ということもあり、AWXのインストール成功までの道のりは平坦ではなかった

本記事では、実際に私の環境にてAWXを導入した際の手順をもとにして、Ansible AWXをMinikubeによるKubernetes環境にインストールする手順を記載する。

環境

今回は仮想マシンでAlmaLinuxを用意した。確保したリソースは以下の通り。メモリを4GBにした場合、メモリ不足によりAWXの展開に失敗するので最低6GBは用意しよう。ディスクは10GB程度あれば問題なさそうだが、余裕をもって60GBとした。

  • CPU : 4コア
  • メモリ : 6GB
  • ディスク : 60GB

その他、導入するソフトウェアのバージョンは以下の通りとなる。

  • AlmaLinux : 8.5
  • Docker : 20.10.12
  • Minikube : 1.24.0
  • AWX Operator : 0.15.0
  • AWX : 19.5.0

また、検証目的なので、firewalldとSELinuxは停止しておく。

# systemctl stop firewalld
# systemctl disable firewalld

# sed -i "s/SELINUX=enforcing/SELINUX=disabled/g" /etc/sysconfig/selinux
# reboot

Docker CEインストール

MinikubeによるKubernetes環境を利用する際にDockerが必要となるため、まずはDockerをインストールする。Dockerのインストールは以下記事に記載している。

本記事でも簡単にインストール手順を記載する。

1. Dockerをインストール

Docker CEは、リポジトリ追加をすることでdnfコマンドを用いてインストールできる。

# dnf install yum-utils -y
# yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo
# dnf install docker-ce docker-ce-cli containerd.io -y

# systemctl start docker
# systemctl enable docker

2. (プロキシ環境の場合) Dockerのプロキシ設定

プロキシ環境の場合は、プロキシ経由でインターネットとの通信ができるよう、/usr/lib/systemd/system/docker.serviceに環境変数の設定を追加する。

以下sedによる設定例となる。プロキシサーバのIPアドレスやポート番号は環境に合わせて修正すること。

# sed -ie '/\[Service\]/a Environment="http_proxy=http://192.168.33.23:8080" "https_proxy=http://192.168.33.23:8080" "no_proxy=192.168.0.0/16"' /usr/lib/systemd/system/docker.service

上記設定後、Dockerを再起動しておこう。

# systemctl restart docker
# systemctl enable docker

Minikubeインストール

1. Minikubeのrpmパッケージのダウンロードとインストール

Minikubeのインストールはrpmをダウンロードしてインストールするだけで完了する。私の環境では特に依存関係による失敗もなくあっさりと完了した。なお、Minukubeのrpmの容量は15MB程度となる。

# curl -LO https://storage.googleapis.com/minikube/releases/latest/minikube-latest.x86_64.rpm
# rpm -Uvh minikube-latest.x86_64.rpm

2. kubectlのコマンド作成

Kubenetes環境に対する各種操作に用いられるkubectlコマンドはMinikubeではminikube kubectl --というコマンド体系となっている。

以下のようにエイリアスを組むことで、Minikube環境でもkubectlを利用することができる。

# alias kubectl="minikube kubectl --"

ただし、エイリアスだけではAWXをインストールする際にkubectlコマンドが使えないことによるエラーが発生する。そのため、以下の通りkubectlコマンドを/usr/local/binに作成することで回避する。

# cat << 'EOF' > /usr/local/bin/kubectl
#!/bin/bash
args="$@"
minikube kubectl -- $args
EOF

# chmod 755 /usr/local/bin/kubectl

3. Minikube実行用ユーザ作成

Minikubeはroot権限で起動させると以下のようなエラーが発生する。

X Exiting due to DRV_AS_ROOT: 「docker」ドライバーは root 権限で使用すべきではありません。

そこで、Minikube実行用のユーザを作成しておく。今回はansibleというユーザを作成し、Dockerを操作できるようdockerグループに所属させる。

# useradd ansible
# usermod -aG docker ansible

4. Minikube起動

それではMinikubeを起動させてみよう。起動はminikube start --driver=dockerにて行う。

# su - ansible
$ minikube start --driver=docker
* Almalinux 8.5 上の minikube v1.24.0
* ユーザーの設定に基づいて docker ドライバーを使用します
* コントロールプレーンのノード minikube を minikube 上で起動しています
* イメージを Pull しています...
* Kubernetes v1.22.3 のダウンロードの準備をしています
    > preloaded-images-k8s-v13-v1...: 501.73 MiB / 501.73 MiB  100.00% 63.56 Mi
    > gcr.io/k8s-minikube/kicbase: 355.77 MiB / 355.78 MiB  100.00% 11.13 MiB p
* docker container (CPUs=2, Memory=2200MB) を作成しています...
* ネットワーク オプションが見つかりました
  - http_proxy=http://192.168.33.23:8080
! プロキシーを使用しようとしていますが、minikube の IP (192.168.49.2) が NO_PROXY 環境変数に含まれていません。
* Please see https://minikube.sigs.k8s.io/docs/handbook/vpn_and_proxy/ for more details
  - https_proxy=http://192.168.33.23:8080
  - no_proxy=192.168.0.0/16
! この container は https://k8s.gcr.io アクセスにおける問題があります
* 外部イメージを取得するためには、プロキシーを設定する必要があるかも知れません: https://minikube.sigs.k8s.io/docs/reference/networking/proxy/
* Docker 20.10.8 で Kubernetes v1.22.3 を準備しています...
  - env HTTP_PROXY=http://192.168.33.23:8080
  - env HTTPS_PROXY=http://192.168.33.23:8080
  - env NO_PROXY=192.168.0.0/16
  - 証明書と鍵を作成しています...
  - Control Plane を起動しています...
  - RBAC のルールを設定中です...
* Kubernetes コンポーネントを検証しています...
  - イメージ gcr.io/k8s-minikube/storage-provisioner:v5 を使用しています
* 有効なアドオン: default-storageclass, storage-provisioner
* kubectl not found. If you need it, try: 'minikube kubectl -- get pods -A'
* 完了しました! kubectl が「"minikube"」クラスタと「"default"」ネームスペースを使用するよう構成されました

問題なくMinikubeが起動している場合は、以下のようにminikubeのノードが作成され、各種MinikubeのコンポーネントとなるPodがRunningステータスで起動する。

$ minikube kubectl -- get nodes
NAME       STATUS   ROLES                  AGE   VERSION
minikube   Ready    control-plane,master   8s    v1.22.3
$ minikube kubectl -- get pods -A
NAMESPACE     NAME                               READY   STATUS    RESTARTS      AGE
kube-system   coredns-78fcd69978-ldbmj           1/1     Running   0             90s
kube-system   etcd-minikube                      1/1     Running   0             102s
kube-system   kube-apiserver-minikube            1/1     Running   0             104s
kube-system   kube-controller-manager-minikube   1/1     Running   0             102s
kube-system   kube-proxy-lpxjq                   1/1     Running   0             90s
kube-system   kube-scheduler-minikube            1/1     Running   0             104s
kube-system   storage-provisioner                1/1     Running   1 (59s ago)   101s

参考情報として、Minikubeのコンポーネントは以下となる。

Pod名称 役割
coredns Minikubeで用いられるDNSサーバ。
etcd-minikube Kubernetesの構成情報を保存するキーバリューストア。
kube-apiserver-minikube APIサーバ。Kubernetes APIを外部に提供。
kube-controller-manager-minikube Kubernetesのコントローラコンポーネント。
kube-proxy-55ksb Nodeのネットワークプロキシ。
kube-scheduler-minikube スケジューラ。Podの配置状況の監視と実行。
storage-provisioner Minikubeで用いられるストレージ管理コントローラ。

AWXインストール

1. gitにてAWX Operatorのソースを入手

AWXのインストールを行う際は、AWX Operatorと呼ばれるAWXインストールツールを用いる。

AWX Operatorのソースはgitにて入手する。もしgitのパッケージがインストールされていない場合はインストールしておこう。また、後ほどmakeコマンドも必要となるため併せてインストールすること。

# dnf install make git -y

gitをインストールしたら、一般ユーザに切り替えてAWX Operatorのソース入手する。

$ su - ansible
$ git clone https://github.com/ansible/awx-operator.git

次に、git checkoutにてAWX Operatorのバージョンを切り替える。この作業を忘れるとインストールに失敗するので注意しよう。2022年1月現在、AWX Operatorの最新バージョンは0.15.0となる。

$ cd awx-operator/
$ git checkout 0.15.0
Note: switching to '0.15.0'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by switching back to a branch.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -c with the switch command. Example:

  git switch -c <new-branch-name>

Or undo this operation with:

  git switch -

Turn off this advice by setting config variable advice.detachedHead to false

HEAD is now at d74b5ba Delete RELATED_ variables from upstream deployment

2. AWXをMinikubeに展開する前の準備

AWXをMinikubeに展開する前の準備としてmake deployを行う。特にエラーがなければ問題ない。

$ export NAMESPACE=my-namespace
$ make deploy
namespace/my-namespace created
customresourcedefinition.apiextensions.k8s.io/awxbackups.awx.ansible.com created
customresourcedefinition.apiextensions.k8s.io/awxrestores.awx.ansible.com created
customresourcedefinition.apiextensions.k8s.io/awxs.awx.ansible.com created
serviceaccount/awx-operator-controller-manager created
role.rbac.authorization.k8s.io/awx-operator-awx-manager-role created
role.rbac.authorization.k8s.io/awx-operator-leader-election-role created
clusterrole.rbac.authorization.k8s.io/awx-operator-metrics-reader created
clusterrole.rbac.authorization.k8s.io/awx-operator-proxy-role created
rolebinding.rbac.authorization.k8s.io/awx-operator-awx-manager-rolebinding created
rolebinding.rbac.authorization.k8s.io/awx-operator-leader-election-rolebinding created
clusterrolebinding.rbac.authorization.k8s.io/awx-operator-proxy-rolebinding created
configmap/awx-operator-awx-manager-config created
service/awx-operator-controller-manager-metrics-service created
deployment.apps/awx-operator-controller-manager created

3. MinikubeにPodを展開

gitで入手したAWXのソースに含まれるマニフェストであるawx-demo.ymlを用いて、AWXのPodをMinikubeに展開する。

# kubectl config set-context --current --namespace=$NAMESPACE
# kubectl apply -f awx-demo.yml

展開の進行状況は以下コマンドで確認できる。大量のログが表示されるが、最終的にfailed=0と表示されていれば成功となる。環境にもよるが、AWXの展開は5分程度で完了する。

$ kubectl logs -f deployments/awx-operator-controller-manager -c awx-manager

~(中略)~

----- Ansible Task Status Event StdOut (awx.ansible.com/v1beta1, Kind=AWX, awx-demo/my-namespace) -----


PLAY RECAP *********************************************************************
localhost                  : ok=61   changed=0    unreachable=0    failed=0    skipped=44   rescued=0    ignored=0

なお、メモリが不足する場合、いつまでもAWXの展開が完了せず成功しない。私の環境では、メモリ4GBの場合は展開に失敗し、メモリ6GBであれば成功することを確認している。

4. AWXの起動確認

AWX展開後の状態を確認してみよう。以下のような状態でPodがRunningで実行状態となっており、Serviceが存在していれば問題ない。

$ kubectl get pods -l "app.kubernetes.io/managed-by=awx-operator"
NAME                        READY   STATUS    RESTARTS   AGE
awx-demo-786447d7bc-zd2w7   4/4     Running   0          16m
awx-demo-postgres-0         1/1     Running   0          16m
$ kubectl get svc -l "app.kubernetes.io/managed-by=awx-operator"
NAME                TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)        AGE
awx-demo-postgres   ClusterIP   None             <none>        5432/TCP       16m
awx-demo-service    NodePort    10.102.136.124   <none>        80:31851/TCP   16m

なお、AWXの管理者パスワードは以下コマンドで入手できる。この後、AWXの画面にログインする際に必要となるので確認しておこう。

$ kubectl get secret awx-demo-admin-password -o jsonpath="{.data.password}" | base64 --decode ; echo -ne '\n'
vPByNYYgvyOj4SpXX1qcMFRZZK61RHwK

5. AWXのServiceに対してポートフォワード設定

展開したAWXは、そのままでは別サーバのブラウザからアクセスすることができない。

本来はきちんと外部からアクセスできるようMinikubeのネットワーク設定が必要となるが、今回は検証目的なので、手っ取り早くポートフォワードすることでアクセスできるよう設定する。

ポートフォワードは以下の通り設定する。今回はMinikubeをインストールしたサーバの8000番ポートをAWXの80ポートにポートフォワードするよう設定した。

# kubectl port-forward svc/awx-demo-service --address 0.0.0.0 8000:80

なお、ポートフォワード設定はフォアグラウンドで実行され、Ctrl+Cで停止するとポートフォワードも停止する。もしバックグラウンド実行したい場合は、以下のように実行するとよいだろう。

バックグラウンド実行する場合
# kubectl port-forward svc/awx-demo-service --address 0.0.0.0 8000:80 > /dev/null 2>&1 &

ポートフォワードを停止する場合
$ fg
kubectl port-forward svc/awx-demo-service --address 0.0.0.0 8000:80

Handling connection for 8000
Handling connection for 8000
^C ←★Ctrl+C

6. ブラウザからAWXへの接続確認

それでは実際にブラウザからAWXいアクセスしてみよう。ポートフォワードしているため、http://[MinikubeをインストールしたサーバのIPアドレス]:8000でアクセス可能となっているはずだ。

ログインユーザはadmin、パスワードは事前に確認したパスワードを使うことでログインすることができる。

以上でMinukube環境にAWXをインストールする手順は完了となる。次は具体的にAWXを使ってPlaybookを実行する手順について記載したい。

参考

2022年1月8日土曜日

Workgroup環境のWindwos OSからドメインユーザのパスワードを変更する

Windowsのユーザのパスワードを変更する場合は、通常は直接対象ユーザにてOSにログインを行いパスワードを変更すればよいが、何らかの理由で直接ログインはできないがパスワードを変更を行いたい場合がある。

例として挙げると、ドメインに新しいユーザを作成した際に「ユーザーは次回ログオン時にパスワード変更が必要」にチェックをしており、リモートデスクトップ接続では以下エラーでログインができず、パスワードが変更できないような場合だ。

このような状況下であってもパスワード変更を行う方法がある。今回は、Workgroup環境のWindows OSからドメインユーザのパスワードをリモートにて変更する手順を記載する。

環境

  • パスワード変更作業OS : Windows Server 2019 (Workgroup環境)
  • ドメインコントローラ : Windows Server 2016

パスワード変更手順

1. DNS設定確認

パスワード変更時にドメインコントローラと通信できるようにするため、DNSサーバとしてドメインコントローラを指定する。
※ADとDNSが統合されていない環境の場合は、ADの名前解決ができるDNSサーバを設定すること。

2. パスワード変更画面を表示

パスワード変更画面のメニューを表示させるため、以下キーを押す。環境によって若干キーが異なるので注意。

環境 操作手順
通常 Ctrl + Alt + Del
リモートデスクトップ Ctrl + Alt + End
仮想マシンコンソール 仮想マシン管理画面から「Ctrl + Alt + Del」をキー送信

メニュー画面では「パスワードの変更」を選択すると、パスワード変更画面が表示される。

3. ユーザ名を変更しパスワード変更

パスワード変更画面では、一見ログインユーザのみパスワード変更ができそうに見えるが、実はユーザ名を変更することで任意のユーザのパスワード変更が可能となる。ドメインユーザの場合は、[ドメイン名]\[ユーザ名]で記載する。

4. パスワード変更

特に問題なければ以下画面の通り、「パスワードは変更されました」と表示される。

以上で、Workgroup環境からのドメインユーザのパスワード変更作業は完了となる。パスワード変更後のパスワードで問題なくログインできることを確認しておこう。

パスワードが変更できない場合

パスワード変更を行った際に、以下2点のエラーによりパスワード変更に失敗することがある。それぞれの原因と対処法について記載する。

その1:「コンピューターが利用できないか、またはアクセスが拒否されているため、ドメインコントローラーから構成情報を読み取れませんでした。」

原因はDNS設定が正しくできていない場合やネットワークの問題で、ドメインコントローラと通信できないことにある。正しくDNSを設定し、ドメインコントローラと通信ができれば解消するはずだ。

その2:「パスワードを更新できませんでした。新しいパスワードとして指定された値は、パスワードの長さ、複雑さ、または履歴に関するドメインの要件を満たしていません。」

原因は単純にパスワードの要件を満たしていないことによるが、パスワード長、使用文字の種類、過去使用したパスワードの条件を満たしているのにこのメッセージが表示される場合がある。

その場合は、「パスワードの変更禁止期間」の設定を疑おう。デフォルトでは「1日」となっているので、これを「0日」に変更する。

変更後グループポリシーが反映されたのちに再度パスワードの変更をすれば成功するはずだ。グループポリシー反映が待てない場合は、ドメインコントローラでgpupdate.exe -forceにてグループポリシー反映を行おう。


2022年1月2日日曜日

CentOS 8をCentOS Streamに移行する手順

2021年12月末でCentOS 8のサポートが終了した。そのため、CentOS 8を使っている場合は、以下の対応が必要となる。

  1. RHELのアップストリーム版であるCentOS Streamに移行する
  2. AlmaLinuxやRocky Linuxといった代替ディストリビューションに変更する

最も手っ取り早い方法は上記1番目のCentOS Streamへの移行となる。本記事では、Cent OS 8からCentOS Streamへの移行手順を記載する。

環境

  • 移行前環境 : CentOS 8.1
  • 移行後環境 : CentOS Stream

CentOS Streamへの移行手順

通常作業は10分もあれば完了する。ただし、万が一の際に備えて、作業前にストレージや仮想環境の機能を用いてスナップショットを取得し復旧できるようにしておこう。

1. 作業前のバージョン確認

作業前にCentOSのバージョン確認をしておこう。

# cat /etc/redhat-release
CentOS Linux release 8.1.1911 (Core)

# uname -a
Linux localhost 4.18.0-147.8.1.el8_1.x86_64 #1 SMP Thu Apr 9 13:49:54 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

2. dnfコマンドにてCentOS Streamへ移行

CentOS Streamへの移行は、以下2行のコマンドを実行するのみで完了する。このコマンドは、CentOS Streamの以下URLに記載されているものと同じとなる。

dnf swap centos-linux-repos centos-stream-repos
dnf distro-sync

dnf swapdnf distro-syncという見慣れないdnfのコマンドを使っているが、それぞれの意味は以下の通り。

コマンド 説明
dnf swap パッケージのリポジトリを切り替える。今回はCentOS 8からCentOS Streamに切り替える。1つ目の引数は削除対象のCentOS 8のリポジトリを指定し、2つ目の引数は追加するCentOS Streamのリポジトリを指定する。
dnf distro-sync すべてのパッケージに対してCentOS Streamのバージョンと一致させるため、インストール及びアップグレードを実施する。

実際に実行させた結果は以下の通りとなる。まずは、dnf swapの実行結果となる。「一致した引数がありません: centos-linux-repos」とメッセージが表示されているが、処理は成功しているようだ。

# dnf swap centos-linux-repos centos-stream-repos
メタデータの期限切れの最終確認: 0:01:20 時間前の 2022年01月01日 07時01分05秒 に 実施しました。
一致した引数がありません: centos-linux-repos
削除対象のパッケージはありません。
依存関係が解決しました。
================================================================================
 パッケージ                Arch        バージョン             Repo        サイズ
================================================================================
インストール:
 centos-stream-repos       noarch      8-3.el8                extras       19 k
アップグレード:
 centos-gpg-keys           noarch      1:8-3.el8              BaseOS       12 k
依存関係のインストール:
 centos-linux-release      noarch      8.5-1.2111.el8         BaseOS       22 k
     置き換え  centos-release.x86_64 8.1-1.1911.0.9.el8
     置き換え  centos-repos.x86_64 8.1-1.1911.0.9.el8

トランザクションの概要
================================================================================
インストール    2 パッケージ
アップグレード  1 パッケージ

ダウンロードサイズの合計: 54 k
これでよろしいですか? [y/N]: y
パッケージのダウンロード:
(1/3): centos-gpg-keys-8-3.el8.noarch.rpm       311 kB/s |  12 kB     00:00
(2/3): centos-linux-release-8.5-1.2111.el8.noar 389 kB/s |  22 kB     00:00
(3/3): centos-stream-repos-8-3.el8.noarch.rpm   311 kB/s |  19 kB     00:00
--------------------------------------------------------------------------------
合計                                             47 kB/s |  54 kB     00:01
トランザクションの確認を実行中
トランザクションの確認に成功しました。
トランザクションのテストを実行中
トランザクションのテストに成功しました。
トランザクションを実行中
  準備             :                                                        1/1
  scriptletの実行中: centos-gpg-keys-1:8-3.el8.noarch                       1/1
  アップグレード中 : centos-gpg-keys-1:8-3.el8.noarch                       1/6
  インストール中   : centos-stream-repos-8-3.el8.noarch                     2/6
  インストール中   : centos-linux-release-8.5-1.2111.el8.noarch             3/6
  廃止             : centos-release-8.1-1.1911.0.9.el8.x86_64               4/6
  廃止             : centos-repos-8.1-1.1911.0.9.el8.x86_64                 5/6
  整理             : centos-gpg-keys-8.1-1.1911.0.9.el8.noarch              6/6
  scriptletの実行中: centos-gpg-keys-8.1-1.1911.0.9.el8.noarch              6/6
  検証             : centos-linux-release-8.5-1.2111.el8.noarch             1/6
  検証             : centos-release-8.1-1.1911.0.9.el8.x86_64               2/6
  検証             : centos-repos-8.1-1.1911.0.9.el8.x86_64                 3/6
  検証             : centos-stream-repos-8-3.el8.noarch                     4/6
  検証             : centos-gpg-keys-1:8-3.el8.noarch                       5/6
  検証             : centos-gpg-keys-8.1-1.1911.0.9.el8.noarch              6/6

アップグレード済み:
  centos-gpg-keys-1:8-3.el8.noarch

インストール済み:
  centos-stream-repos-8-3.el8.noarch centos-linux-release-8.5-1.2111.el8.noarch

完了しました!

次にdnf distro-syncを実行する。なお、本処理を実行するとCentOSに含まれないパッケージを含めたすべてのパッケージが最新化される (例えばZabbixを導入している場合はZabbixもアップデートされる) ため注意すること。私の環境では、480個のパッケージ更新が実行された。

# dnf distro-sync
CentOS Stream 8 - AppStream                     4.2 MB/s |  18 MB     00:04
CentOS Stream 8 - BaseOS                         16 MB/s |  16 MB     00:00
CentOS Stream 8 - Extras                         52 kB/s |  16 kB     00:00
依存関係が解決しました。
================================================================================
 パッケージ                    Arch   バージョン                Repo      サイズ
================================================================================
インストール:
 centos-stream-release         noarch 8.6-1.el8                 baseos     22 k
     置き換え  centos-linux-release.noarch 8.5-1.2111.el8
 fwupd                         x86_64 1.5.9-1.el8_4             baseos    2.8 M
     置き換え  dbxtool.x86_64 8-5.el8
 kernel                        x86_64 4.18.0-348.2.1.el8_5      baseos    7.0 M
 kernel-core                   x86_64 4.18.0-348.2.1.el8_5      baseos     38 M
 kernel-modules                x86_64 4.18.0-348.2.1.el8_5      baseos     30 M
アップグレード:
 apr                           x86_64 1.6.3-12.el8              appstream 129 k
 bind-libs                     x86_64 32:9.11.26-6.el8          appstream 174 k
 bind-libs-lite                x86_64 32:9.11.26-6.el8          appstream 1.2 M
 bind-license                  noarch 32:9.11.26-6.el8          appstream 102 k
 bind-utils                    x86_64 32:9.11.26-6.el8          appstream 451 k

~(中略)~

弱い依存関係のインストール:
 udisks2                       x86_64 2.9.0-7.el8               appstream 474 k
 crypto-policies-scripts       noarch 20211116-1.gitae470d6.el8 baseos     83 k
 elfutils-debuginfod-client    x86_64 0.186-1.el8               baseos     71 k
 memstrack                     x86_64 0.1.11-1.el8              baseos     48 k
 epel-next-release             noarch 8-13.el8                  epel       10 k
モジュールストリームの有効化:
 perl-IO-Socket-SSL                   2.066
 perl-libwww-perl                     6.34

トランザクションの概要
================================================================================
インストール     48 パッケージ
アップグレード  420 パッケージ

ダウンロードサイズの合計: 551 M
これでよろしいですか? [y/N]: y

~(中略)~

  lmdb-libs-0.9.24-1.el8.x86_64
  mdadm-4.2-rc2.el8.x86_64
  python3-nftables-1:0.9.3-24.el8.x86_64
  tpm2-tss-2.3.2-4.el8.x86_64

完了しました!

3. 再起動

Linuxカーネルのバージョンアップも実施されていることから、一度再起動を実施しておく。

# reboot

4. 作業後のバージョン確認

作業後にCentOSのバージョン確認する。CentOS 8からCentOS Streamに変更されていることがわかる。

# cat /etc/redhat-release
CentOS Stream release 8

# uname -a
Linux localhost 4.18.0-348.2.1.el8_5.x86_64 #1 SMP Tue Nov 16 14:42:35 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

以上でCentOS 8からCentOS Streamへの移行は完了となる。

参考

人気の投稿