2014年はやりませんでしたが、やはり振り返りって大事だと思います。大晦日につき振り返ってみます。
目次
PowerShell
2015年は「PowerShell って現実にどういう利用シーンがあるのか」をインフラ以外のレイヤで考えたりした年でした。私にとってPowerShellって、ただのツールで自動化しやすかったりするだけなので、使えないシーンならすぱっと切り捨てます。別に PowerShell 最高じゃないし、使えないなってことも多いので。言語としてとらえた時に、「ロジックが制御しやすい」「わかりやすい」なんてまだまだ言えないですし。そういう意味で、PowerShell を使うシーン、落としどころ、何で使うのかを考え続けました。
PowerShell の依存低下
結果として、会社のインフラレイヤから PowerShell の依存を格段に減らしています。特に valentia を中心とした各サーバーの接続 (PUSH型) から、APIベースのPULL型接続に移行しています。もちろん AWS や Azure などのリソースをサクッと叩く部分では PowerShell は超有用です。しかし、こと 非同期、実行しっぱなし、イベントベースでの処理が加わると無しです。現実的な落としどころは、仕組みに乗っかった中でどこまで薄くできるかです。仕組みから作るのはやり過ぎだしよくないなと。その例として PowerShell で一番使える、使うべきは DSC と PackageManagement 、そして Cmdlet です。
PowerShell DSC
PowerShell DSC が 2013年11月の PowerShell 4.0 にリリースされてから、2014年はインフラ基盤の Configuration Management の中心にすえることに取り組みました。そして2015年は、DSC につきまとうリソース不足に対して積極的にリソースを作成し公開することで解消を図りました。会社で利用していて足りないものを網羅する勢いでそれなりの数をリリースしました。全部使っているので、変なバグはあまりないはずです。*1
リソース不足は、標準リソース、コミュニティのカスタムリソースを含めて現在でも付きまとっています。
今でも作成したリソースに該当する代替品はないように見受けられますし、それなりの数のユーザーにも使ってくれる人がいるなど役に立っているようで何よりです。
2016年は、AppVeyor での CI による自動テストまでは組んでおきたいところですね。Microsoft のリソースでやり取りもしていて、それなりに知見も得たのでまぁやりたいなと。
PackageManagement
今年は、WMF5.0 つまり PowerShell 5.0 が PPリリースということもあり機能が固まったとみて、PackageMangement(OneGet) の会社での利用も展開しました。*2Comuplues セッションで紹介したように、会社(グラニ)ではUnity の最新リリースを検知して OneGet で展開したり、何かしらのPCの構成はOneGet 経由にしています。やはり apt-get ライクな利用というのは楽なもので、特に NuGetを利用している人には違和感なく利用できているようで何よりです。とはいえ、結構バグというか挙動が不完全なので信頼性が根本で足りてないのは、OneGet頑張れ感あります。Azure WebApps + AzureAD で認証組んで展開とかもやってみたのですが、OneGet からの利用ではAzureAD認証でパッケージソース登録もできなくて残念な感じ半端ないんですけど..。
Cmdlet
Cmdlet は、私のPowerShell に対する1つの結論です。今後 PowerShell は、C# *3で書くことがほとんどだと思いますし、スクリプトを書いてもクラスベース構文が中心になると思います。単純なラッパーなどサクッとした記述なら別ですが、関数で頑張る努力は捨てるほうが健全だと思っています。Cmdlet を使うにあたって最大の問題である、継続デプロイ (Continuous Deploy : CD) したいときのファイルロック問題も解決したので待ったなしです。
2016年は Nano Server の展開が待っています。*4ようやく、コンテナが Windows に来るので革新が来るでしょう。楽しみですね。数年来待っていたこともあり、さっさと本番で利用します。
CSharp
今年はこれまで以上に C# への技術移行が進みました。これまでもちょこちょこ書いてはいたのですが、一気に中心言語としています。LinqPad起動回数 > PowerShell起動回数 なのがその例です。会社のデプロイ基盤をPULL型にしたり、OneGetの自動化、その他多くの面でC# が中心に変わりました。
デプロイ基盤のPULL型化
2年ぐらい考えてたのを、C# + LightNode でようやく実現に移した年でした。グラニのデプロイは現在 1秒未満です。*5コンセプトとしては、クックパッドの mamiya による デプロイと同じです。同じコンセプトのものを先に発表されてしまったので発表する気が失せたのですが。やはりみなさん同じ考え持つんですね、もっと早くやっておけばよかったです。はい。
社内の新デプロイ基盤は Serf を使いません、LightNode のクライアントコード自動生成で密にサーバー側コードと一体化できる、かつノードの協調保証を不要にしたためです。デプロイの改善に一番大事なのは、デプロイの細分化。つまり、配置と展開の分離です。
私の中では Serf は使いたくないです。Consul のコンセプトは好みですが、これもいかに使わず全ノードが相互につながらずサービスを形成できるかを考えています。これはコンテナも含めてですね。
SignalR なども手をだしましたが、あれはないですね。使えるシーンの柔軟性がないので、正直私の中ではあまり汎用性のある技術という感触ではありません。使えるシーンでは便利ですが、どうも使いにくいですね。
仕事
集中力が問われる一年でした。多くのことを同時並行にすることが多いのはこれまでもでしたが、かなり作業が多岐に渡ってしまい進捗どうですかが不満でした。よくないです。来年の課題は集中です。一方で、BigQuery へのロギングの集約などを含めて課題としていたことの多くに一定の成果を出したので、ようやく次のステップに集中して手を出す基盤となった一年になりました。
esa.io による、必要になったときに必要な知識を自分で得られる環境整備の効果は大きいので、使ってない人には使ってほしいです。ただの集合知ではない良さがあります。
AWS を中心としていますが、GCPやAzureなどマルチクラウドしています。こうして使っていると、それぞれが得意としたり、目指している方向がてんでバラバラで面白いですね。特に アカウントのロール制御や認証方式に関しては差が大きく出ています。Aurora に関しては、日本最速レベルで本番を移行完了しており実例として使ってもらえているようで何よりです。
www.slideshare.net
記事
ブログ記事は最低数だったです、時間が取れてない様がよく出ています。その分内容を濃くする努力をしましたどうだったんでしょう。アドベントカレンダーも PowerShell5.0 の内容で書かないとですね。
Build Insider にも連載記事を更新しました。もう少し色々紹介したいですが、どうしても書く時間が問題ですね。
来年
仕事面は、ゲームを出すです。他はなしで。
個人的には、もう少しインフラやそれ以外に Unity を取り入れたりしたいですね。C# に完全に技術基盤が移行しているので、PowerShell というより、C# を中心とした動きが強くなると思います。HoloLens に胸を躍らせる日々です。
