正直なところ気の向くまま適当にやっているだけな感じだったのですが、非常にありがたいことにMVP(Cloud and Datacenter Management)を再受賞することができました。
ありがとうございます。
これからもPowerShellを中心とした情報発信をしていきたい所存です。
いろいろ思うところがあり、つい先日独自ドメインをとってブログ名も変えました。
私、本名がしばたなんですけど、ドメイン名もブログ名もそれを晒す形にしました。
ネット上の活動とリアルの活動でキャラクターを使い分けるのがめんどうになってきたのも正直あったので。
これにより、今後の活動が特に変わるかといえばそうではないのですが、まあ、心機一転ということで宜しくお願い致します。
再来週のオープンソースカンファレンス 2017 HokkaidoでCLR/HとしてPowerShellの入門的なお話をさせていただきます。
MVPを再受賞して初のセッションとなります。
現在鋭意セッション資料作成中ですのでご都合がよろしければぜひ見に来てやってください。
元ネタはこちら。
次期Windows ServerおよびSemi-annual Channelについては山市さんがサクッとまとめてくれています。
今年の9月リリース予定の次期Nano Server(Version 1709)は元ネタに
However, starting with the new feature release of Windows Server, version 1709, Nano Server will be available only as a container base OS image.
とある様にコンテナ専用となり、Docker Hubからのみイメージの取得および更新ができる様になるそうです。
また、サーバーの用途を.NET Coreアプリケーションをホストすることに最適化し、コンテナのサイズもこれまでよりさらに減らすそうです。*1
で、ここからが本題で、
- Windows PowerShell, .NET Core, and WMI are no longer included by default, but you can run them in a separate container.
とのことで、次期Nano ServerではデフォルトでWMIやPowerShellが含まれないそうです。
by defaultとあるので追加でインストールすることはできるだろうと予想されますが、まだ確定的な情報はありません。
個人的な予想として、明確な根拠があるわけではないのですが、「今開発中のPowerShell 6.0を追加でインストールしてね。」という流れにしたいのかなと思っています。
デフォルトでWMIやPowerShellがインストールされないことに関しては、Nano Severがコンテナ専用になる以上妥当だと思います。
と言ってもPowerShellがいらない子だと言うわけではなく、コンテナの運用は基本的に作り直し・使い捨てのDisposableなモデルになるかと思います。このモデルおいては重厚な管理フレームワークであるWMIやPowerShellは不要なケースの方が多いでしょう。
単純にコンテナ内部にPowerShellが必須ではないというだけです。
ただ、PowerShellが無いことでコンテナイメージの作成はどうすべきなのかという疑問はあります。
まさかコマンドプロンプトですべてを賄うというわけにはいかないでしょうし、Nano Server専用のツールセットといったものが今後出たりするんでしょうかね？
このあたりは今後の情報を期待して追いかけていきたい感じです。
*1:サイズに関してはWindows Updateでモリモリ増えていくザマを見てどこがNanoなのかと思うことしきりだったのでうれしいですね…
【2017/06/05追記】
本現象は先日出た累積更新(KB4020102)で解消されています。
【追記ここまで】
きっかけは @masaru_b_cl さんのこのツイートから。
SQL*Plusが出力する日本語が、Windows 10の新コンソールだと文字化けする……なんだこれ？
— 白い高野さん (@masaru_b_cl) 2017年5月26日
手元の環境でこの現象が再現して回避策を見つけることができたのでここにメモっておきます。
今回、以下の環境で文字化けが起きることを確認しました。
クライアント
Instant Client Package - BasicInstant Client Package - SQL*PlusJapanese_Japan.JA16SJISTILDEサーバー
JA16SJISTILDEテスト用にTEST_TABLEテーブルを用意し、投入したデータは以下の様な感じです。
とりあえずデータベースに接続して以下のクエリを流してみます。
SELECT VALUE FROM TEST_TABLE ORDER BY KEY;
結果はこんな感じで思いっきり日本語が化けます。
よく見るとログイン時のメッセージも化けています。
ちなみにPowerShellからSQL*Plusを実行しても同じ感じになります。
原因はCreators Updateで仕込まれたバグの様です。
新コンソールはマルチバイト文字のハンドリングにBUGがあるらしく。 https://t.co/JxEBWlBOS2 Creators Update ではBUGったまま出荷されている模様。最新のIPでは直っています。マイケルに期待している
— Takekazu Omi (@takekazuomi) 2017年5月26日
@takekazuomi さん曰く最新のInsider Previewではこの現象は改善されているそうなので、しばらく我慢すればパッチも出るんじゃないかと思います。
とりあえず現状としては以下の回避策で対処することが可能です。
本エントリを公開した瞬間に@takekazuomi さんよりコメント頂きました。
これでは回避できませんか？ pic.twitter.com/pwDhI97QxU
— Takekazu Omi (@takekazuomi) 2017年5月26日
コマンドプロンプトのプロパティで従来のコンソールを使うにチェックを入れてコマンドプロンプトを再起動することで本現象を回避することができました。
この方法が一番手っ取り早く確実ですね。
私の調査は一体何だったのかという気持ちでいっぱいですが気にしないことにします....
この現象はコンソールに表示される最初の文字が日本語でなければ良いっぽく、
SELECT '', VALUE FROM TEST_TABLE ORDER BY KEY;
な感じで先頭にダミーカラムを付けて最初にスペースが表示される様にするだけでも問題は解決します。
とりあえずこれで問題は回避できますが、非常にトホホな気分になります...
真っ当な回避策としてはクライアント側の文字セットをユニコードにしてしまう方法があります。
今回はUTF8に変更することで対処してみます。
NLS_LANGの文字セットをAL32UTF8に変えればクライアント側の文字コードをUTF8にできます。
これだけだとコマンドプロンプトで文字を表示できないのでCHCPコマンドでコードページも変える必要があります。
実行するコマンドは以下の様な感じになります。
CHCP 65001 SET NLS_LANG=Japanese_Japan.AL32UTF8
この状態であれば下図の様に文字化けを回避することができます。
ちなみにPowerShellであれば、CHCPコマンドの代わりに[Console]::OutputEncodingの設定を変えることでも対応可能です。
[Console]::OutputEncoding=[Text.Encoding]::UTF8 $env:NLS_LANG='Japanese_Japan.AL32UTF8'
残念の一言につきるので早く修正パッチが提供されることを望みます。
