しばたテックブログ

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

Azure Cloud Shell内のPowerShellの今後について

元ネタはこちら。

azure.microsoft.com

Azure Cloud Shell内のPowerShell

Azureポータル内で使えるCloud Shellですが、現在は

  • Bash
  • PowerShell (プレビュー)

の二種類選択することができます。
それぞれの実行基盤は

  • Bash : Linux Container (Ubuntu)
  • PowerShell : Windows Server Container (Server Core)

とコンテナになっており、各コンテナにおいてPowerShellは次の様に利用できます。
本エントリでは便宜上これらのコンテナを、Bashコンテナ、PowerShellコンテナと呼称します。(正式な名称ではありませんのでご注意ください)

Bashコンテナ内のPowerShell

コンテナ起動時のシェルはBash(現時点では4.3.48)。
BashからPowerShell Core 6.0(現時点では6.0.2)を呼び出し可能。

PowerShellコンテナ内のPowerShell

コンテナ起動時のシェルはWindows PowerShell 5.1
PowerShellコンソールから新たにPowerShell Core 6.0(現時点では6.0.2)を呼び出し可能。

Azure Cloud Shell内のPowerShellの今後

現状を踏まえた上で、先述のAzure BlogではAzure Cloud Shell内のPowerShellを以下の様に変更するとしています。

  • Faster startup time
  • PowerShell Core 6 as the default experience
  • Running on a Linux container
  • Persistent Tool Settings

この中で重要なのは

  • PowerShell Core 6 as the default experience
  • Running on a Linux container

の2点です。

Linux Container(Bashコンテナ)への統合

一度でもCloud Shellを利用したことがある方はわかると思いますが、ブログ内で

We are well-aware that the startup time of PowerShell in Azure Cloud Shell is well below the user’s expectation.

と触れられている様にPowerShellコンテナの起動速度ははっきり言って遅いです。

For past couple of months, the team has been working hard to make significant improvements in this area

と起動時間の改善をしている様ですが、後述の

To ensure the best command-line tools experience while using Azure Cloud Shell, the PowerShell experience will be switching to a Linux container running PowerShell Core 6.

にある様にBashコンテナに統合することで根本的な解決を図る見込みです。
(文章としては一貫性のあるツールエクスペリエンスのためとされていますが、パフォーマンスの問題が根底にあることは行間を読めば自ずと見えてくるかと思います...)

ただし、明確に「PowerShellコンテナを廃止する」とは言っていないので、今後どの様にCloud Shellが変わっていくのかは注視していきたいです。

この統合に対して、Clould Shellでの操作はAzureの管理が基本であり、PowerShell上であればOSの違いは意識する必要が無くコンテナ統合による影響は軽微かと思います。

ちなみに、Cloud Shell内のユーザーデータの保存先であるCloud Driveは両方のコンテナで共用なので、仮にPowerShellコンテナが廃止されてもユーザーデータがロストすることは無いと明記されています。

PowerShell 6.0をデフォルトに

前項のコンテナ統合もあり、クロスプラットフォームであるPowerShell Core 6.0がデフォルトになるのは自明であり、そして真っ当でしょう。
PowerShell Coreは半期リリースで随時更新されますのでCloud Shellの様なプラットフォームには最適です。

ただ、現状AzureRM.Netcoreモジュールはプレビューバージョンです。
いつGAするかに関してはまるで情報が無く今後を見守るしかない感じです。

最後に

とりあえずこんな感じです。
多くはいないと思いますが、現時点でPowerShellコンテナを使ってAzureを管理している方はPoweShell Coreへの移行を視野に入れておくと良いでしょう。

IISにMDwikiをホストする

小規模でお手軽な、できれば「Markdownで文章書いてアップして終わり」くらいお手軽なWikiサーバーが欲しくなり、いろいろ探してみたところMDwikiが良さそうだったので導入して試してみました。

github.com

IISにMDwikiをホストする

このMDwikiは基本的にはローカル環境での利用が想定されている様ですが、IISでホストする手順も公式に用意されています。

環境構築はこの手順に従うだけですが、本エントリでは私自身の備忘も兼ねて少し補足を入れながら説明していきます。
また本エントリの手順をまとめたものをGistに上げています。

導入環境

最新のWindows Updateを適用したWindows Server 2016で行います。
手順自体は簡単ですので、Windows Server 2012 R2など他のバージョンでも問題なく導入できるでしょう。

サイトはデフォルトのDefault Web Siteを使う想定です。

IISのインストール

Install-WindowsFeatureでIISの機能を追加します。
MDwikiは静的なサイトですのでASP.NETなどの機能は無くても構いません。

本エントリではWEBサーバーの機能とIIS 管理コンソールを追加しておきます。

# IISのインストール
Install-WindowsFeature Web-WebServer, Web-Mgmt-Console

IISの設定変更

MDwikiをIISでホストするにはMarkdownファイル(拡張子.md)に対するMIMEの設定を変更する必要があります。
公式の手順にある様に管理コンソールからGUIで行っても構いませんが、ここではAdd-WebConfigurationで設定します。

$SITE_PATH = 'MACHINE/WEBROOT/APPHOST/Default Web Site'

# MIME設定の変更
$mime = Get-WebConfiguration -PSPath $SITE_PATH -Filter system.webServer/staticContent/mimeMap | Where-Object { $_.fileExtension -eq '.md' }
if($null -eq $mime) {
    Add-WebConfiguration -PSPath $SITE_PATH -Filter system.webServer/staticContent -Value @{fileExtension='.md'; mimeType='text/x-markdown'}
}

MDwikiのダウンロードとインストール

MDwikiは公開しているサイトのルートにmdwiki-latest.html(mdwiki-latest-debug.html)に配置するだけでインストールできます。
ここではInvoke-WebRequestを使ってindex.htmlという名前で保存します。

$SITE_ROOT = 'C:\inetpub\wwwroot'

# なぜかVer.0.6.2だとデバッグ版でしか動かない
#Invoke-WebRequest -Uri http://dynalon.github.io/mdwiki/mdwiki-latest.html -OutFile (Join-Path $SITE_ROOT 'index.html')
Invoke-WebRequest -Uri http://dynalon.github.io/mdwiki/mdwiki-latest-debug.html -OutFile (Join-Path $SITE_ROOT 'index.html')

上記コメントにも記載していますが、現在の最新版であるVer.0.6.2ではリリース版であるmdwiki-latest.htmlだと上手く動作しなかったため、デバッグ版であるmdwiki-latest-debug.htmlをダウンロードする様にしています。

初期ファイル

MDwikiのインストール自体はこれで完了ですが、最低限Wikiを動作させるには以下のファイルを作っておく必要があります。

  • index.md : ルートとなるMarkdownファイル
  • navigation.md : Wikiのページ上部にあるメニューを定義するファイル
  • config.json : MDwiki本体の設定ファイル

設定の詳細はドキュメントを参照してください。

今回は以下のスクリプトで各ファイルを生成します。

# その他最低限の初期ファイルを追加
@"
My MDwiki Website
----------------
### Hello World!
"@ | Set-Content -LiteralPath (Join-Path $SITE_ROOT 'index.md') -Encoding UTF8
@"
# My MDwiki
[gimmick:theme](flatly)
[Top](index.md)
[gimmick:themechooser](Choose theme)
"@ | Set-Content -LiteralPath (Join-Path $SITE_ROOT 'navigation.md')  -Encoding UTF8
@"
{
  "title": "My MDwiki"
}
"@ | Set-Content -LiteralPath (Join-Path $SITE_ROOT 'config.json')  -Encoding UTF8

なお各ファイルのエンコーディングは必ずUTF-8にしてください。

ここまで実行すると下図の様にWikiが動作するはずです。

f:id:stknohg:20180517183210p:plain

MDwikiの運用について

導入したMDwikiの運用について気になった点や、現在こんな運用をしているという点を紹介します。

IE対応

今回イントラネットにWikiを公開したのですが、IEでアクセスする場合、イントラネット内だとIEの互換モードでレンダリングを行おうとして表示に失敗してしまいました。
このためindex.htmlのヘッダに以下の記述を追記して互換モードをオフにする様にカスタマイズすることで対処しています。

<meta http-equiv="X-UA-Compatible" content="IE=edge" >

ギミック

MDwiki独自の機能としてギミックと呼ばれる機能があり、このうちAlertsギミックは便利でよく使っています。

シンタックスハイライト

現在のバージョンではコードのシンタックスハイライト機能にバグがあり、特定の言語に対するシンタックスハイライトを使うとブラウザがフリーズしてしまいます。

私もいろいろ試してみましたが、コードのシンタックスハイライト機能は一切使わないのが良いと判断して運用しています。
(とても残念ですが仕方ない...)

コンテンツの更新

コンテンツであるMarkdownの更新はいろいろな方法で可能ですが、私はサイトのルートディレクトリを共有フォルダにしてMarkdownファイルを直接メンテナンスする方式を採りました。
かなりの暴挙なのですが、小規模であることとお手軽さを考慮してこうしました。実際めちゃくちゃ楽です。

バックアップ

MDwikiのバックアップはコンテンツを丸ごとコピーするだけで良いので非常に楽です。
環境依存な部分が多いのでスクリプトは公開しませんが、サイトのルートディレクトリをCompress-ArchiveでまるっとZip圧縮してバックアップ先に保存する運用をしています。

MDwikiの今後について

ちょっと理由は不明なのですが、去年の年末よりMDwikiのGitHubの更新が途絶えておりプロジェクトの今後に不安がよぎります。

ツール自体は現状でも便利に利用できますが長期の運用を検討しているのであれば少し様子を見た方が良いかもしれません。
いっそのことフォークして完全に自前で更新していくのもアリでしょう。

最後に

ざっとMDwikiの導入と運用について説明しました。
プロジェクトの今後に少し不安がよぎるものの、お手軽に導入、運用できるのでとりあえず試してみると良いでしょう。

Windows 10で利用可能なSSHサーバー、クライアントまとめ

Windows 10ではSSHサーバー、クライアントの機能が使える様になっているのですが、バージョンによって色々違いがあり自分でも混乱してきたのでわかる範囲でまとめました。
必要があれば随時更新します。

Microsoft SSH Server

Windows 10 Anniversary Update(1607)より、開発者機能の一部としてMicrosoft独自のSSHサーバーが利用可能になっています。
サーバーのみの提供でクライアント機能はありません。

この機能の実体は次の2つのサービスになります。*1

  • SSH Server Broker
  • SSH Server Proxy

機能に関する細かい話はこちらの記事を見ると良いでしょう。

こちらの記事では「Server Broker版SSH」と呼ばれ、具体的な用途についても触れられていませんが、Win32-OpenSSHのこちらのIssueにこのSSHサーバーについての質問があり、そこで中の人であるJoeyさんがこう答えています。

github.com

The "Microsoft SSH Server" is installed when you enable developer mode but is unrelated to the Windows Subsystem for Linux. As @jdunn0 said, it's used for the very specific scenario of deploying and testing UWP apps. You can read more about the server and scenario here: https://msdn.microsoft.com/en-us/windows/uwp/get-started/enable-your-device-for-development#ssh

コメントによるとこのサーバは「Microsoft SSH Server」と呼称され、特定のUWPアプリケーションのテスト(Device discovery系の機能っぽい)に使うためのものだそうです。

機能の詳細については、

msdn.microsoft.com

を見ると良いでしょう。

組み込みWin32-OpenSSH

Windows 10 Fall Creators Update(1709)よりMicrosoftによるOpenSSHのポートであるWin32-OpenSSHがOSに組み込まれました。

こちらはMicrosoft SSH Serverと異なりサーバー、クライアント両方の機能が提供されています。

Windows 10 Fall Creators Update(1709)

Fall Creators Updateの時点ではOpenSSHの機能はベータ版です。

GUIからだと「設定→アプリと機能→オプション機能の追加」で機能を追加できます。

f:id:stknohg:20180514172902p:plain

またコマンドではGet-WindowsCapabilityで機能がインストールされているか確認でき、Add-WindowsCapabilityで機能をインストールすることができます。

機能の確認

# 要管理者権限
Get-WindowsCapability -Online | ? { $_.Name -like 'OpenSSH*' }

結果

PS C:\> Get-WindowsCapability -Online | ? { $_.Name -like 'OpenSSH*' }


Name  : OpenSSH.Client~~~~0.0.1.0
State : NotPresent

Name  : OpenSSH.Server~~~~0.0.1.0
State : NotPresent

機能のインストール

# 要管理者権限
# OpenSSHクライアントをインストール
Add-WindowsCapability -Online -Name 'OpenSSH.Client~~~~0.0.1.0'

# OpenSSHサーバーをインストール
Add-WindowsCapability -Online -Name 'OpenSSH.Server~~~~0.0.1.0'

インストールされたOpenSSHはC:\Windows\System32\OpenSSH配下にあり、バージョンはv0.0.18*2になります。

# バージョン確認 (Ver.7.5とコマンドからはバージョンが上手く確認できない...)
PS C:\> ssh -V
OpenSSH_7.5p1, without OpenSSL

サーバー機能は以下のサービスとしてインストールされます。

  • ssh-agent : C:\Windows\System32\OpenSSH\ssh-agent.exe
  • sshd : C:\Windows\System32\openssh\sshd.exe

ちなみにベータ版のためssh-keygenなどの初期設定をしないとsshdサービスが動作しません。
設定方法の詳細は以下のPowerShell Teamのブログにありますので参考にしてください。

blogs.msdn.microsoft.com

なお、このバージョンではsshd_configsshd.exeと同じディレクトリに置く必要があります。

Windows 10 Spring Creators Update(1803)

Spring Creators UpdateでOpenSSHの機能は正式版となり、デフォルトでOpenSSHクライアントが導入済みの状態になっています。
すなわち、何もせずともはじめからssh.exeが使えるということです。

f:id:stknohg:20180514192602p:plain

# 要管理者権限
# SSHクライアントは最初からインストール済み
PS C:\> Get-WindowsCapability -Online | ? { $_.Name -like 'OpenSSH*' }


Name  : OpenSSH.Client~~~~0.0.1.0
State : Installed

Name  : OpenSSH.Server~~~~0.0.1.0
State : NotPresent

ちなみに現時点でインストールされているバージョンは、v7.6.0.0p1-Betaです。

PS C:\> ssh -V
OpenSSH_for_Windows_7.6p1, LibreSSL 2.6.4

サーバー機能に関してはFall Creators Updateと同様にAdd-WindowsCapabilityでインストールする必要があります。

# 要管理者権限

# OpenSSHサーバーをインストール
Add-WindowsCapability -Online -Name 'OpenSSH.Server~~~~0.0.1.0'

実体のサービスはFall Creators Updateの時から変わりませんが、こちらは正式版とあってサービスの表示名がきちんとした形になっています。

  • ssh-agent(OpenSSH Authentication Agent) : C:\Windows\System32\OpenSSH\ssh-agent.exe
  • sshd(OpenSSH SSH Server) : C:\Windows\System32\OpenSSH\sshd.exe

また、Spring Creators Updateでは、機能のインストール後にいきなりsshdサービスを起動して構いません。
初期処理を自動で行いC:\ProgramData\ssh\sshd_configなどの各種設定ファイルを作成します。*3

このバージョンではC:\ProgramData\ssh\sshd_configを設定する必要があります。

【2018/10/08追記】Windows 10 October 2018 Update(1809)

特に目新しい機能追加は無く、インストールされているバージョンがv7.7.2.0p1-Betaに更新されただけの様です。

PS C:\> ssh -V
OpenSSH_for_Windows_7.7p1, LibreSSL 2.6.5

【2019/05/22追記】Windows 10 May 2019 Update (1903)

Windows 10 October 2018 Updateから更新されずバージョンはv7.7.2.0p1-Betaのままでした。

PS C:\> ssh -V
OpenSSH_for_Windows_7.7p1, LibreSSL 2.6.5

【補足】Win32-OpenSSHの開発方針について

最後に補足としてWin32-OpenSSHの開発方針の変更について触れておきます。

もともとWin32-OpenSSHの開発は

github.com

で行われていました。
ちょっと事の経緯は把握できていないのですが、今後はopenssh-portableのWindows対応に舵を取り、openssh-portableのWindows対応が完了した時点でWin32-OpenSSHの方を終息させ、openssh-portable本体を主流としていく方針となった様です。

github.com

もとのWin32-OpenSSHはIssueリリース管理のためだけに残されています。
現在のプロジェクトステータスがWin32-OpenSSHのWikiに載っていますので参照してください。

このため今後OpenSSHの情報を追う際は両方のリポジトリを見ておくと良いでしょう。

*1:なお、一度も開発者モードにしていない場合はサービスはありません

*2:ファイルバージョンから確認できます

*3:この挙動はOpenSSH v1.0.0.0-betaからの変更になります。