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認証でパッケージソース登録もできなくて残念な感じ半端ないんですけど..。
https://tech.guitarrapc.com/entry/2015/09/03/045447
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に関しては、日本最速レベルで本番を移行完了しており実例として使ってもらえているようで何よりです。
https://speakerdeck.com/guitarrapc/nice-to-meet-you-aurora
https://www.slideshare.net/AmazonWebServicesJapan/amazon-aurora-56297741
記事
ブログ記事は最低数だったです、時間が取れてない様がよく出ています。その分内容を濃くする努力をしましたどうだったんでしょう。アドベントカレンダーもPowerShell5.0の内容で書かないとですね。
Build Insiderにも連載記事を更新しました。もう少し色々紹介したいですが、どうしても書く時間が問題ですね。
来年
仕事面は、ゲームを出すです。他はなしで。
個人的には、もう少しインフラやそれ以外にUnityを取り入れたりしたいです。C#に完全に技術基盤が移行しているので、PowerShellというよりC#を中心とした動きが強くなります。oloLensに胸を躍らせる日々です。
