しばたテックブログ

気分で書いている技術ブログです。

Desired State Configuration Core (DSC Core)が発表されました

PowerShell

発表されてからちょっと時間が経ってしまいましたがざっくりまとめておきます。

公式情報はコチラ

blogs.msdn.microsoft.com

以前PowerShell 6.0、PowerShell Coreのロードマップが発表された時はWindows PowerShell Desired State Configuration(以後PowerShell DSC)について言及されませんでしたが、今回はじめてPowerShell DSCの今後について言及されました。

本エントリではこの内容について説明していきます。

これまでのPowerShell DSC

PowerShell DSCとは何ぞや？といった話についてはぎたぱそ先生の記事が全てですのでそちらでご確認ください。

www.atmarkit.co.jp

adventar.org

これまでのPowerShell DSCについては、Windowsで動作するもの、Linuxで動作するものの2種類があり、それぞれ、

1. Windows PowerShell Desired State Configuration

  • WMIを基盤としている
  • Windows Management Framework (WMF)の一部として提供されており、管理にはPowerShell 4.0～5.1を必要とする
  • DSC ResourceはCまたはPowerShellで記述する

2. Desired State Configuration for Linux(DSC for Linux)

  • OMIを基盤としている
  • PowerShellがクロスプラットフォーム化する前に生まれているため、管理にPowerShellは使わずPython 2.4～3.4を必要とする
  • DSC ResourceはCまたはPythonで記述する

といった特徴があります。　　

ちなみにDSC for Linuxについてはこのブログでも試していますので以下の記事を参考にしてください。

blog.shibata.tech

Desired State Configuration Core (DSC Core)

PowerShellがPowerShell Coreとなり.NET Coreを基盤としたクロスプラットフォームなツールになることにあわせて、PowerShell DSCも.NET Core/PowerShell Coreを基盤としたDesired State Configuration Core (以後DSC Core)として発展させていくとの事です。

DSC Coreについて以下の方向性が挙げられています。

  • WMIへの依存をなくす
  • WMFへの依存をなくす
  • xcopyで配布可能なパッケージとする
  • WMIを使わないC/C++、Python、PowerShellで書かれたDSC Resourceをサポートする
  • PowerShell Core/.NET Coreを必要とする

ざっくり言ってしまえばクロスプラットフォーム化のためにPowerShell Core/.NET Coreを基盤とし、WMIやWMFへの依存(要はWindows依存)を取り除く方向になります。

DSC Coreの目指すことろ

こちらについてはPowerShell Blogの内容をそのまま引用します。

Our goals with DSC Core are to minimize dependencies on other technologies, provided a single DSC for all platforms, and position it better for cloud scale configuration while maintaining compatibility with Windows PowerShell Desired State Configuration.

DSC Coreの下位互換性

目指すところは分かりますが、これまでのPowerShell DSCとの互換性をどう取るのかは非常に重要であり、もっとも難しい問題だと思います。

この点についてPowerShell Blogでは以下の様に述べられています。

  1. DSC Resourceに関しては.NET Standard 2.0の互換性で既存のリソースはそのまま動く様にする

  2. コマンドレットに関しては従来のPowerShell DSCとの互換を取らず、新しいコマンドセットを提供する

  3. Azure DSC ExtensionはDSC Core用に新規のものを提供する

  4. Pullサーバーとの通信に関して、DSC Coreでもこれまで通りのプロトコルを使い既存のPullサーバーと通信できる様にする

  5. Configurationに関しては、これまで通り変更が無い様にし、PowerShell 6.0でコンパイルしなおすだけで使える様にする

PowerShell Blogでも注記されていますが、これらの点についてはあくまでも現時点での計画です。

私見ですが、正直これらをすべて完璧に満たすのは難しいと思っていますので、今後の状況によっていろいろ変化があると思われます。

DSC Coreのリリース時期

DSC Coreのリリース時期に関して、先ずはAzure向けに年末までに最初のリリースを出すそうです。
(流石に早すぎるのでここでの"リリース"はアルファ版とかだと思います...)

PowerShell DSCがクロスプラットフォーム化するメリットを一番享受できるのがAzureでしょうし、環境自体が日々更新され新しくなっていくAzureにフォーカスするのは妥当な判断だと思います。
(逆にWindowsを中心としたオンプレ環境だと今のPowerShell DSCを新しくするメリットがほとんどないように思われます...)

まとめ

ざっくりとですがDSC Coreについてまとめてみました。

正直なところ、DSC Coreの仕組みやPowerShell Blogで述べられている事がどこまで実現可能かについて結構疑問点があります。

ですが、今それについてあれこれ言っても仕方ないとも思っているので今後の情報で疑問を解決していきたいと思います。

Windows 10でPowerShell Remoting over SSHを試す

Windows PowerShell Linux

【2017/10/25追記】

先日リリースされた、Fall Creators Update(1709)でPowerShell Remoting over SSHができなくされていました。
これまで利用可能だったのが間違った更新なのか、単純に一時的な使用不可なのかはよくわかりません...

【追記ここまで】

公式のアナウンスなどは全く無く、いつの間にかWindows 10 Creators Update(1703)でPowerShell Remoting over SSHが使える様になっていたので試してみました。

PowerShell Remoting over SSHについて

PowerShell Remoting over SSHとは何ぞやといった話はこちらのエントリをご覧ください。

blog.shibata.tech

どのPowerShellで使えるのか？

当初PowerShell Remoting over SSHはPowerShell 6.0向けの機能として発表され、現在も絶賛開発中です。
このためPowerShell Core 6.0であればこの機能はふつうに使えます。

で、他のバージョンに関してはいまのところWindows 10 Creators Update(1703)以降のWindows PowerShell 5.1にのみ実装された様です。
確認が取れなかったのでCreators Updateが出た直後のビルドから利用可能だったのかまでは不明ですが、少なくとも2017年8月現在のビルド(PSVersion = 5.1.15063.502)では利用可能になっています。

また、Windows PowerShell 5.1でもWindows Server 2016*1やWMF 5.1として他のOSにインストールしたものに関しては利用できません。

PowerShell Remoting over SSHを試す

以前に試した時と同様にCentOSをサーバーとしてWindows 10から接続してみます。
CentOSのバージョンは7.3に上げています。

項目 Windows 10(1703) CentOS 7.3
基本設定 最新のWindows Updateを実施した状態 bento/centos7.3のBoxにyum updateを実施
IP - VirtualBoxのゲスト(localhostで接続する)
ユーザー - vagrant, root

1. CentOSの設定

CentOSの設定手順は前と同様ですが、PowerShellをyumからインストールする様に変更しています。
また/etc/ssh/sshd_configの設定をsedで行う様にしました。*2

# CentOS(Bash)
# PowerShell Core for Linuxのインストール
curl https://packages.microsoft.com/config/rhel/7/prod.repo | sudo tee /etc/yum.repos.d/microsoft.repo
sudo yum install -y powershell

# /etc/ssh/sshd_config の設定
# '# override default of no subsystems'のコメント行の下に設定を追加
# ※位置指定をかなり決め打ちにしているので注意
sudo sed -i.orig -e "/# override default of no subsystems/a Subsystem powershell /usr/bin/pwsh -sshs -NoLogo -NoProfile" /etc/ssh/sshd_config

# sshdの再起動
sudo systemctl restart sshd.service

2. Windowsの設定

PowerShell Remoting over SSHはPowerShellとOpenSSHを組み合わせた機能であるため、OpenSSHをインストールしてssh.exeのあるディレクトリに対してPATHを通しておく必要があります。

以下の手順でC:\Program Filesにインストールします。

# 要管理者権限
# OpenSSHのインストール
Invoke-WebRequest -Uri "https://github.com/PowerShell/Win32-OpenSSH/releases/download/v0.0.18.0/OpenSSH-Win64.zip" -OutFile "OpenSSH-Win64.zip"
Expand-Archive -Path ".\OpenSSH-Win64.zip" -DestinationPath "$env:ProgramFiles"

# Pathの追加
[Environment]::SetEnvironmentVariable('PATH', [Environment]::GetEnvironmentVariable('PATH') + ";$(Join-Path $env:ProgramFiles "OpenSSH-Win64")")

3. 接続確認

前と同様にNew-PSSessionおよびEnter-PSSessionを使用して接続確認をします。

PowerShell Remoting over SSHでは-HostName(-ComputerNameではない)や-UserNameパラメーターで接続先を指定します。*3

# セッション生成
# 検証環境の都合-HostNameがlocalhostになっているが実際には接続先のホスト名を指定する
$Session = New-PSSession -HostName "localhost" -UserName vagrant
# 接続
Enter-PSSession -Session $Session

下図の様にSSHのセッションが生成され問題なくCentOSのサーバーに接続できました。

f:id:stknohg:20170814171926p:plain

f:id:stknohg:20170814171940p:plain

ちなみに、OpenSSHをインストールせずに接続しようとすると以下の様なエラーになってしまいますので注意してください。

f:id:stknohg:20170814171908p:plain

制限事項

PowerShellのバージョンを問わず現時点のPowerShell Remoting over SSHの制限事項として接続先のポート指定ができません。

New-PSSessionには-Portパラメーターがあるのですが、これは通常のPSRemoting専用のパラメーターであり、PowerShell Remoting over SSHで使おうとすると不正なパラメーター扱いされエラーとなってしまいます。

この点に関しては以下のPull Requestが出ており目下対応中といったところなのでいずれ解消されると思います。

github.com

*1:先日提供されたInsider Preview版でも使えませんでした

*2:位置指定がかなり決め打ちなのであまり良いやり方ではないと思いますが楽だったのでつい...

*3:他に-KeyFilePathパラメーターもあります

Windows Serverに最小構成でRedmineをインストールする - その2

Windows PowerShell Ruby Redmine

blog.shibata.tech

前回のエントリで最後に触れたとおりWindowsのThinでHTTPSアクセスを有効にする方法について説明します。

WindowsのEventMachineでSSLを有効にする方法

Thinの内部で利用されているEventMachineでSSLを有効にする方法については以下に詳しく記載されています。

github.com

github.com

これらの内容を基にいろいろ試してみた結果、現在のバージョンVer. 1.2.5においては以下の様にすれば良いことが分かりました。

  1. OpenSSLは最新版のVer.1.1.0系ではなく、Ver.1.0.2系を使う

    • ネイティブコンパイルに必要なライブラリの構成が1.1.0系だと駄目だそうです。

  2. ネイティブコンパイルのオプションに--with-opt-libと --with-ssl-includeを付ける

    • --with-ssl-dirパラメーターではダメな様です。

  3. プラットフォームの指定をrubyにする

    • デフォルトのプラットフォームはx64-mingw32ですがこれだと上手くいきませんでした...

gem installコマンドだと以下の様な指定になります。

gem install eventmachine --platform ruby -- --with-opt-lib=[OpenSSLのインストール先\bin] --with-ssl-include=[OpenSSLのインストール先\include]

このため、Redmine(Thin)のインストールにおいてHTTPSアクセスを有効にするにはbundle installコマンドから上記と同等のインストールができれば良いのですが、私のRubyちからが低く、bundle configなどいろいろ試してみたのですが、結局どうすれば出来るのかわかりませんでした...

仕方ないので今回は一旦bundle exec install gemコマンドからEventMachineだけを別にインストールし、Redmine(Thin)で使われているものと差し替えることでHTTPSアクセスを有効にすることとしました。

0. はじめに

前提条件

今回の作業を行う前提として、前回の手順でRedmineをインストールした直後の状態からスタートします。

Windowsサービスの設定

本エントリの作業ではWindowsサービスを設定しなおす必要があるので、一旦インストールしたサービスの登録を解除しておきます。

$REDMINE_SERVICE_NAME = "Redmine"

# Windowsサービスの解除
Stop-Service $REDMINE_SERVICE_NAME
thin_service remove -N $REDMINE_SERVICE_NAME

1. OpenSSLのインストール

OpenSSLのインストール

最初に触れた様にOpenSSLのVer.1.0.2系、現時点の最新版であるVer.1.0.2Lをインストールします。
ネイティブコンパイル用にインクルードファイルなども必要なので、LightではないWin64 OpenSSL v1.0.2Lをダウンロードしてインストールします。

前回同様サイレントインストールします。
インストール先はC:\OpenSSL-Win64としています。

$OPENSSL_INSTALL_PATH = 'C:\OpenSSL-Win64'
# ダウンロード
Invoke-WebRequest -Uri "http://slproweb.com/download/Win64OpenSSL-1_0_2L.exe" -OutFile "$(Get-Location -PSProvider Filesystem)\Win64OpenSSL-1_0_2L.exe"
# インストール
Start-Process -FilePath ".\Win64OpenSSL-1_0_2L.exe" -ArgumentList @("/SILENT", "/DIR=""$OPENSSL_INSTALL_PATH""") -Wait -PassThru

サーバー証明書の作成

こちらは無くてもなんとかなるのですが一応サーバー証明書も作っておきます。
手順と証明書の内容はかなり適当です。

実環境では適宜まともな証明書を使用してください。

# 必要なPATHを追加
$env:OPENSSL_CONF = Join-Path $OPENSSL_INSTALL_PATH "bin\openssl.cfg"
$env:PATH = "$(Join-Path $OPENSSL_INSTALL_PATH "bin");" + $env:PATH

# 証明書の設定は適当(CNだけ設定)なので必要に応じて変更してください 
openssl genrsa -out server.key 4096
openssl req -new -x509 -days 3650 -key server.key -out server.crt -subj "/C=JP/ST=/L=/O=/OU=/CN=$(hostname)"

作成した証明書は任意のディレクトリに配置してください。*1

2. SSL対応したEventMachineのインストール

続けてSSL対応したEventMachineをインストールします。

2-1. SSL対応したEventMachineのインストール

bundle execコマンドを使用してRedmineで使用しているものとは別にEventMachineをインストールします。
Redmineをインストールしたディレクトリに移動して以下のコマンドを実行してください。

$REDMINE_VER = '3.4.2'
$REDMINE_INSTALL_ROOT = 'C:\'
$REDMINE_INSTALL_PATH = Join-Path $REDMINE_INSTALL_ROOT "redmine-$REDMINE_VER"

# ディレクトリ移動
cd $REDMINE_INSTALL_PATH

# bundle exec gem install で個別にeventmachineをインストール
bundle exec gem install install eventmachine --platform ruby -- --with-opt-lib="$(Join-Path $OPENSSL_INSTALL_PATH "bin")" --with-ssl-include="$(Join-Path $OPENSSL_INSTALL_PATH "include")"

ここでエラー無くGemのインストールが完了すれば、BundlerのGemフォルダには以下の様に2つのEvenetMachineがインストールされているはずです。

f:id:stknohg:20170813000646p:plain

それぞれ、

  • eventmachine-1.2.5

    • 今回の手順でインストールされたEventMachine。SSL対応。

  • eventmachine-1.2.5-x64-mingw32

    • 前回のbundle installでインストールされたEventMachine。SSL非対応。

となります。

2-2. Redmineで使用しているEventMachineと差し替える

続けて、この2つのGemの名称を差し替えて、Redmine(Thin)でSSLに対応したEventMachineを使う様にしてやります。
単純にフォルダ名をリネームして差し替えてやります。

# フォルダ名の差し替え
$BUNDLE_GEM_ROOT = Join-Path $REDMINE_INSTALL_PATH "vendor\bundle\ruby\2.3.0\gems"
Move-Item (Join-Path $BUNDLE_GEM_ROOT "eventmachine-1.2.5-x64-mingw32") (Join-Path $BUNDLE_GEM_ROOT "eventmachine-1.2.5-x64-mingw32.orig")
Move-Item (Join-Path $BUNDLE_GEM_ROOT "eventmachine-1.2.5") (Join-Path $BUNDLE_GEM_ROOT "eventmachine-1.2.5-x64-mingw32")

f:id:stknohg:20170813000700p:plain

上図の様になっていれば完了です。

2-3. 動作確認

前回同様に動作確認を必要に応じて行ってください。

今回はHTTPSアクセスを有効にするので、--ssl、--ssl-key-file、--ssl-cert-fileパラメーターを指定してやります。
サーバー証明書はRedmineをインストールしたディレクトリにおいてあるものとします。

# 動作確認のため、必要に応じて実行する
# https://localhost:3000/ にアクセスして動作を確認する
bundle exec thin start -e production -p 3000 -a 0.0.0.0 -c "$REDMINE_INSTALL_PATH" --ssl --ssl-key-file "$(Join-Path $REDMINE_INSTALL_PATH "server.key")" --ssl-cert-file "$(Join-Path $REDMINE_INSTALL_PATH "server.crt")"

3. Windowsサービスの設定

動作確認に問題がないことを確認したら、最後にthin_serviceコマンドを使い、Redmine(Thin)をWindowsサービス化します。
--ssl、--ssl-key-file、--ssl-cert-fileパラメーターを指定する点以外は前回と同じです。

# サービス登録
$REDMINE_SERVICE_NAME = "Redmine"
$REDMINE_INSTALL_PORT = 3000
thin_service install -N $REDMINE_SERVICE_NAME -c "$REDMINE_INSTALL_PATH" -p $REDMINE_INSTALL_PORT -e production --ssl --ssl-key-file "$(Join-Path $REDMINE_INSTALL_PATH "server.key")" --ssl-cert-file "$(Join-Path $REDMINE_INSTALL_PATH "server.crt")"
# サービス起動
Start-Service Redmine

以上でインストールは完了です。
https://localhost:[$REDMINE_INSTALL_PORTのポート番号]/にアクセスしてRedmineにHTTPSアクセスができることを確認してください。

f:id:stknohg:20170813000716p:plain

f:id:stknohg:20170813000726p:plain

最後に

とりあえずこんな感じです。
bundle installで上手くやる方法がありましたらぜひ教えてください。

*1:今回の手順ではRedmineをインストールしたディレクトリに配置した例を挙げています