tech.guitarrapc.cóm

Technical updates

「PowerShell実践ガイドブック」という本を書きました!

このたび、PowerShell実践ガイドブックという本を執筆・刊行する運びとなりました。

本日から予約開始、2018/5/30日に発売です。

※ Amazonの紹介文がおかしいのは修正予定です。 修正されました。

Amazonなどのオンライン書店で予約が始まってます。 Kindle版もありますが、まだAmazonでは発売情報が出ていませんのでお待ちください。 5/22 Kindle版も予約開始しています。

また、マイナビ出版でもPDFを販売しています。

book.mynavi.jp

PowerShell Coreを扱った本は、世界では2017年に発売された6.0リリース前の本のみで、国内でも初めてになります。

こんな人におすすめです

  • ふだんのちょっとしたPC作業を自動化をしてみたい方
  • システム管理者としてPowerShell使っていく、使いこなしたい方
  • 開発者からみてPowerShellをどう使うか気になる方

テーマは、PowerShell Core (PowerShell 6.0) をメインに据えた、PowerShellを実際に使っていくときのガイドとなる本です。 この本は過去の「PowerShellを触り始めた直後の自分」がほしかった本でもあり、今の自分が幅広い利用者を想定して書き出せる限界ギリギリを絞りました。 コードパズルに近いマニアックな内容にならず、プログラマーでないとわからないということがないように気を使っています。

Twitterアンケートでも本当に幅広い方がPowerShellを使っていて嬉しい反面、最新の情報や実践を見据え体系的にまとまった情報を得にくいと感じていました。

私自身がPowerShellを学び始めたときに困ったのが「情報がない」です。 PowerShell 6.0になって、Windowsだけでなく、macOSやLinuxでも動かせるようになりました。 とはいえ、PowerShell 6.0をどうやって導入するのか、何に使えるのか、どうやって動かすのか、スクリプトってなに、関数? 高度な関数?実際に使ってみてハマることは?という、基本的なことすらも分かりにくいと感じていました。 PowerShellに関する記事を数多く書いて来ましたが、「本によるまとまった情報の取り込み力」が必要と考えての一冊です。

本書が、そんな悩みを解決できる一助になれば、幸いです。

Windows PowerShell In Action や Windows PowerShell Cookbook との違い

当初案のタイトルは、PowerShell In Action でした。 まさにテーマが In Action「実際に使う」ということだったので被ってることにしょんぼりすることになるとは思いませんでした。

Windows PowerShell イン アクション も Windows PowerShell クックブックも何度か推薦するぐらい素晴らしい良著で私の大好きな本です。

PowerShell実践ガイドブックは、この2冊と明確に立ち位置が違います。

  • PowerShell Core (現時点の最新である PowerShell 6.0) をメインとした内容になっている
  • 体系的な基本機能も網羅しているが、常に実践を意識した内容になっている
  • 実際にPowerShellを使うにあたっての操作や直面する課題を対象にしている

これまで学んできたことを含めて全ページ書き下ろしているので、お気に入りの一冊に加えていただけると嬉しいです。

章構成と立ち読み

大まかな構成は、まずは触ってみる(1章)→コンソール操作と基本機能(2章)→管理操作(3章)→スクリプティングと自動化(4章)→実践とTips(5章)となっています。

本書の前書き「はじめに」のセクションをテキストで出すことを編集者さんに許可もらったので、ブログで一部を公開します。 「はじめに」の全文はマイナビ出版様より立ち読みとして公開予定もあるそうです。

本書の想定する読者

本書は、これからPowerShellを触ってみたい方、システム管理者、開発者の三者を想定しています。 これから触る方には、日常の中で繰り返し手作業で行っていることを自動化する足がかりになるでしょう。 特に、筆者自身が今までコマンドプロンプトやPowerShellをちょっとだけ起動したことはあったけれども「さらに習得したい」と考えたときに手に取りたかったものとして本書を執筆しました。

システム管理に求められる問題領域は、コンピューターシステムの構成や運用に始まり、ネットワーク、コンピューターセキュリティなど多くのリソースに及びます。さらに、クラウド管理、データベース管理、Webシステム管理などが求められることも少なくありません。開発者としても、多くのビルド、デプロイ、Application Programming Interface(API)を通した各種サービス操作を日常的に行います。

両者に共通するのは、多岐にわたる知識と解決です。限られた時間の中で解決するために、多くの操作を自動化する必要に迫られます。操作自体はシンプルな処理の連続であることが多く、コマンド1つ、あるいはパイプラインでつないで、はたまたスクリプトで自動化されます。

PowerShellは自動化に際して大きな力を発揮します。特に構造化データの取り扱いの容易さが大きな力になるでしょう。経験の有無にかかわらず、繰り返し作業やうんざりする作業をPowerShellを使って自動化したい方にとって本書が力になると考えています。

本書で得られること

本書を通して、PowerShellを使うことに対して「知らない」に起因する心理的なハードルの軽減すること、そして、PowerShellの網羅的な内容を知ることができるように気を配りました。本書は詳細機能の説明を無理に詰め込むことはせず、本書を読み進めることによってPowerShell 6.0の概要の把握から、C#コマンドレットの作成の入り口までの導入を目指しています。

本書は5章に分かれています。各章はテーマを持ち、実践的なTipsを交えつつ紹介しています。

第1章では、起動するのも初めて、これからまさに触ろうと思ったときに知りたかった「何ができるか」を平易に伝えることを念頭に置きました。Visual Studio Codeを使ったPowerShellのデバッグにも触れています。他言語の経験者の方やすでに慣れ親しんでいる方からすると、すでに知っていること、普段から行っていることの繰り返しに近いため、第2章から読み進めてもいいでしょう。

第2章では、PowerShellのコンソール操作に触れつつ、しっかりと基礎を学ぶことを目標に置いています。 PowerShellは、操作することを自動化に結び付けやすいため、多くの方にとってはこのコンソール操作をどうするかが知りたいことだと思います。

第3章では、クロスプラットフォームなシステム管理操作がテーマです。操作ログやリモート操作を始めとして、PowerShellでどのようにシステム管理を行うかを主題にしています。

第4章では、スクリプティングを網羅しつつ、理解できるようにしました。スクリプト、関数、クラス構文を始めとした機能の利用から、実際にモジュールを作って公開することまで、手を動かしながら学べます。

第5章では、さらに一歩進んだPowerShellの利用に触れています。実際にPowerShellを使って気付く悩みがちなこと、より実践的なTipsに踏み込んでいます。

PowerShellは画面がテキストだけということもあり、コマンド操作経験がない方がいきなり触るには難しいと考えています。そこで、第1章は、平易な言葉と例を用いて、可能な限りわかりやすい表現を心がけました。第2章以降は、オブジェクトなどの概念を順に追いかけつつ、手を動かしながら理解していく内容になっています。初めてPowerShellを触る場合でも、C#や.NETランタイムの知識や経験は必要ないように配慮して書きましたが、第2章以降ではそれを知っていることが理解を助けるでしょう。

本書で得られないこと

PowerShellは、管理や自動化といったタスクを達成しようと思ったときに使うであろうツールです。本書が目指すのは、ツールの扱い方であり使い方ではありません。したがって、標準だけでも500を越えるコマンドの1つひとつの説明はしないので、どんなときにどのような管理をするのかというユースケース、Acrive Directoryのアカウントの操作方法などは本書で説明しません。

また、本書をもってプログラマーになることは目的としていません。スクリプト環境としてVisualStudio Code(以降、VS Code)を使って説明しますが、PowerShell ISEやVS Codeの使い方やスニペット、GUIアプリケーションの作成などは触れません。

線引き

「PowerShellは何でもできるわけではない」といってしまうのは簡単です。やりたいことを探していて、要件をまったく満たしておらず使えないということもあります。コマンド1つで実行できて極めて便利なこともあるでしょう。しかし、可能ではあるものの、PowerShellで行うには複雑になってしまって難しいこともあります。

本書では、こういったPowerShellだけでは扱いにくいことをどのように扱うか、あなた自身が学んでいけるようにガイドを示します。

Windows PowerShell と PowerShell Core

2018年現在、PowerShellには、2006年に発表されたWindows PowerShellと2018年に正式版を迎えたPowerShell Coreが存在しています。

PowerShell 6.0は、PowerShell Coreの最新リリースバージョンです。Windows PowerShellのコードを元に.NET Coreをベースとしてさまざまな改善が図られており、Windows PowerShellを置き換えることを視野に開発されています。パフォーマンスや使い勝手の大幅な改善を目的に後方互換性をなくした機能もあり、.NET Frameworkには存在するものの.NET Coreにない機能は削られてもいます。

本書はPowerShell Coreの最新リリースである「PowerShell 6.0」を前提として紹介していますが、Windows PowerShellからみた変更点にも極力触れています。Windows PowerShellについて知識をお持ちの方は、PowerShell Coreでどのように変化したのかにも注目してください。

東プレ REALFORCE TKL S / R2TLS-JP4-BKにメインキーボードを変更した

ここ最近色々と活動していましたが、タイプ量が相当多く、キーボードを自分で持ち込むことがありました。

そこでメインキーボードを REALFORCE 91UDK-G からREALFORCE TKL S / R2TLS-JP4-BK に変えてみたのでレビューを。

目次

これまで使っていたキーボード

アマゾンの購入履歴から2013年4月18日にREALFORCE 91UDK-Gを購入して愛用していたので、ちょうど5年使っていました。

tech.guitarrapc.com

購入ページ | ダイヤテック株式会社

Realforce 91UDK-G テンキーレス・ALL45g

もともとノートPCでの作業との一貫性からテンキーレスに慣れていたので十分満足しています。 会社の静音モデルと比べても何の不自由もなく、カタカタ毎日入力する日々です。

静音モデルのREALFORCE 91UBK-Sが2018年6月生産終了になっており、REALFORCE 91UDK-Gがリストにないのでそろそろ世代が変わった感があります。

第二世代REALFORCE

長年使っていると安定していて心地いい反面で、新製品がなく物足りなさを覚えます。 特に、テンキーレスで横幅はいいのですが、縦方向のサイズは邪魔に感じます。 静かにタイピングする方ですが、タイプ音ももっと静かにできるならしたいなぁと感じます。 そんな折に第二世代が発売されると聞いて、自分で買う理由を探していました。*1

www.4gamer.net

ちょうど家でなくても自分のキーボードを持ち込めることがあったのでこれ幸いと購入することにしました。

キーボードの選択

まずは一覧を確認しましょう。

今回の購入条件は次の通りです。

  • テンキーレス
  • 日本語キーボード*2
  • 変荷重は不要
  • 色は黒

この条件に当てはまるのは2つ、REALFORCE TKL S / R2TLS-JP4-BKとREALFORCE TKL SA / R2TLSA-JP3-BKです。

違いはAPCの有無と荷重が45gか30gかのみです。

APC気になるものの、あまり必要と思っていないのと触ってみてあんまり感動しなかったのでなし。 残りは荷重ですが、Realforce 91UDK-Gと同じ45gかなという選択と思いきや、APC要らないという時点でREALFORCE TKL S / R2TLS-JP4-BKで確定です。

荷重に関しては購入後も良かったかわかりません。 私は1日18時間ぐらいタイプするわけですが、寝る理由がタイプが重くて疲れてもう打てないから、というのが1月ほど続いたのでもっと軽いともっとタイプできていい感じな気もします。 軽さは正義に直結しませんが、疲れには直結するので悩ましいです。

購入は早く使いたかったのでAmazon Primeです。 2018年4月16日購入価格が\22,014で、2018年4月28日現在\19,293なので今の方が格段に安いです。なんなの

REALFORCE TKL SA / R2TLSA-JP3-BKが\21,225なのでAPCと荷重30gに価値を感じるか次第でしょう。

感想

明らかにすべてが改善しているので満足しています。 特に気になったのが次のポイントです。

サイズ

横方向のサイズはあまり変わりませんが、無駄に感じていた丸め加工ではなくまっすぐになっているのがうれしいです。

縦方向の余白も大幅に減ってサイズがコンパクトになっています。地味ですがものすごく体感が変わっていて最高にうれしいです。

スペースキーの大型化

長年使っていて困っていないのでどちらでもいいのですが、スペースキーが大きくなると打ちやすくなったと感じます。

静音性

圧倒的に違います。 REALFORCE 91UDK-G とだけでなく、REALFORCE 91UBK-Sと比べても明らかに静かになっています。

打鍵感

以前のREALFORCE 91UDK-G ではカタカタという感じでしたが、スコスコと音以外にもスムーズな打鍵感があります。 個人的にとても打ちやすく、メカニカルだけどメカニカルのタイプにある微妙に苦手な感じがないバランスの良さを感じています。

Fn機能

使いません。普段MacBook も使うのですが、Windowsと共通のキーボード配列にはこだわっていません。 Caps Lock KEY ⇔ Ctrl KEY の入れ替えもしない方なので使わないです。 インジケータの色も普段インジケータすべて消えているのでいらないという。

印字

REALFORCE TKL S / R2TLS-JP4-BKは、レーザー印刷のため、キートップの文字をなでると少し凹凸があるのが分かります。 REALFORCE TKL SA / R2TLSA-JP3-BK やREALFORCE 91UDK-Gは昇華印刷だったので少し変わった感じはします。 気にならないかというと、少し吸い付く感じがあるので意識すると気になります。 が、さすがにそこに意識は向けてないのでこの記事を書いていてわざわざ違いに気を払わないと気づきませんでした。

レーザーは、昇華と違い印字が消えるので消えたタイミングを変える言い訳になりそうです。

安定性

実は裏面のラバーフィートが、REALFORCE 91UDK-Gと全然違います。 REALFORCE TKL S / R2TLS-JP4-BKは、四隅にラバーフィートがあり全くずれません。 REALFORCE 91UDK-Gでは、キーボード下部のみだったためにずれることがありストレスだったのから大きく良くなっています。 キーボードが安定しているのスゴク大事。

まとめ

プログラミングしている以上、タイピングがここまで感じ変わると嬉しいですね。 もし、今キーボードでREALFORCEどうなの?と思っていらっしゃるなら、第二世代REALFORCEを使ってみると感想が変わると思います。 ぜひ試す機会があればオススメです。

このキーボードにしてから、一日20時間まで疲れを感じなくなったのは成果としてあります。 お仕事募集しているので、どこかで話しながらキーボード試したい時は声かけてください!

*1:使えるものがあるうちは余り買い替える衝動がないのです

*2:私はASCII配列でもなんでもokですが、日頃触る機会の多い配列に合わせます

VSTSの YAML Build Preview でビルド

Visual Studio Team Service (以降 VSTS) は、プロジェクト管理、Gitリポジトリ、CI (リリース含む) などソフトウェア開発を支援する結構大掛かりなサービスです。

私自身は CI の環境としては結構好き*1な一方他の機能はちょっと大掛かりと感じます。本記事では言及しませんが、パッケージ管理も便利です。*2

今回は VSTS でずっとほしかった YAML 定義からのビルドパイプラインについてです。ようやくYAML来たので少しは楽できそうです。

YAMLといっても、この VSTS 拡張じゃないので悪しからず。

https://marketplace.visualstudio.com/items?itemName=adamvoss.yamlmarketplace.visualstudio.com

目次

参考資料

ある程度概要をつかみつつ詳細を見通すのには、このあたりを見ておけばいいと思います。英語記事も含めて触ってみた、こんな感じという内容が多いのは利用者の絶対数と、他CIに比べて Yamlでの調整がしにくいのが大きい感じがします。(GUI でのパイプライン構築が強いのもありますが)

kkamegawa.hatenablog.jp

docs.microsoft.com

azure-pipelines-agent/yamlgettingstarted.md at master · microsoft/azure-pipelines-agent · GitHub

概要

従来 VSTS ではWebポータルからGUIでビルドパイプラインを構築していました。このあたりは、CircleCI や Travis、AppVayor に慣れてると不思議な感覚です。

VSTS の YAML Build とは、簡単にいうと Circle CI のような yaml 定義でのビルドパイプライン構築ができるというものです。慣れた手法ですね。なお、ビルドパイプラインだけなので、Push連動などビルドタイミングやオプション設定はできません。

さて、ではGUI での構築はどうなんでしょうか? YAML を使いたいだけの理由があるのでしょうか?私にとっては、ものによる、と思います。ビルドの95%はシンプルなので YAML がベターです。一方でその場でインスタントに組むにはGUIも悪くないでしょう。

今がPreview だからこそ、感覚として他のビルドで慣れた肌感との違いをメモしておきます。

GUI のメリット

  • リポジトリにコミットがいらないので CI ビルドのためにコミットを重ねる必要がないのはあるあるでしょう。*3
  • パイプラインを作っていてある程度複雑になっても意外とやりやすいと感じます
    • yaml ですこし細かいことをしたときに読み解かなくてもパッとみたいことに目線のスコープを絞れるのは GUIの良さでしょう

GUI で困ること

  • GUIで1つずつのパイプラインを組むので、どんな構成なのかをざっと把握するには不便です。全体の普遍的な把握にはだるいです
  • ビルド構成のクローンからの作成が可能ですが、まとめて直したいときには1つずつ直す必要があって容易に刺身タンポポになります
    • ビルド職人さんはほぼ発生しないのですが、刺身タンポポさんが発生しやすいのは由々しき欠点です
  • リポジトリごとに決まったパターンでのビルドを、ビルド構成/デプロイ先の些細な差異で構築したときに面倒さが爆発します
    • ビルドパイプラインは単純を維持するのがいいので、Parallel にパラメータ変更で回すなどは避けるべきです
    • 一方で、似たビルドが多数できても違いを把握するのは大変でしょう

YAML ビルドの利用開始前作業

YAML ビルドを試す前にちょっとだけ準備です。

アカウントをとる

VSTS にアクセスして適当にアカウントをとっておきます。無料です。Hosted Agent でマネージドビルドができるので、まぁあってもいいかなぐらいです。

www.visualstudio.com

YAMLビルドの有効化

まだ YAML Build は Preview 機能なので有効化が必要です。

  • アカウントのアイコンから Preview features を開く

  • ユーザーアカウントではなく 作成した VSTS アカウント全体の設定に切り替えます for this account
  • Build YAML definitions を on に変更

これで準備できました。

YAML でビルドパイプラインを書いてみる

では本筋です。ドキュメントは本家を見ておけば大丈夫だと思います。

azure-pipelines-agent/yamlgettingstarted.md at master · microsoft/azure-pipelines-agent · GitHub

YAML 定義をする前にどんな定義なのか見る

適当にビルドをWebポータルからポチポチ組むと YAML でどう定義するのか見られます。便利。

View YAML からYAML をプレビューしてみました。

なるほどいい感じです。

gist.github.com

リポジトリに YAML 定義を置いてみる

ではプレビューした YAML使ってビルドプイプラインを定義してみましょう。コピペです。

github.com

ビルドパイプラインをYAMLで作る

書いたYAML からビルドパイプラインを作ります。

VSTS で作業しましょう。

YAML によるビルド定義を作る

VSTS の Build and Release > Build からビルドを新規作成します。

新規ビルドジョブを作ってみると YAML が選択できるようになっています。

Agent Queue の選択

適当に名前を付けたら、Agent Queue を選択します。2018/1/24 現在は、YAML ビルドは マネージドビルドであるのみサポートされています。

  • Hosted VS 2017
  • Hosted Linux Preview
  • Hosted macOS Preview

https://docs.microsoft.com/en-us/vsts/build-release/actions/build-yaml

今回は C# プロジェクトなので Hosted VS2017 を選択します。

YAML パスの指定

YAML ビルドは、Git ソースパスとして Github か VSTS がサポートされています。YAML はリポジトリ内の任意のパスを指定できます。ルートが一番楽で、.vsts-ci.yml がドキュメントで記述されている名前ですが他でもok です。

今回は、v2 フォルダ配下に置いたので、v2/.vsts-ci.yml と指定します。

ビルドリポジトリの指定

Get Source からビルドリポジトリを指定します。Github からぽちっと。

Submodule など チェックアウトオプションの指定

YAML 定義の リポジトリのチェックアウト指定には制約があります。

https://github.com/Microsoft/vsts-agent/blob/master/docs/preview/yamlgettingstarted-features.md

  • YAML 上では Submodule checkout を指定できない
  • Build Report の有効化が指定できない

しかしこれらは、UI上でリポジトリのチェックアウトとしては有効化がかのうなので必要に応じてUIで有効化すればいいでしょう。

環境変数の設定

YAML 内部でも Variables は定義可能です。が、ビルドによって変わるものやシークレットは当然入れなくないでしょう。

https://github.com/Microsoft/vsts-agent/blob/master/docs/preview/yamlgettingstarted-phase.md#variables

CircleCI でもそうですが、シークレットな情報は環境変数に鍵付きマスクで設定しておけます。

ビルド実行

ビルド設定ができたらこれでおしまいです。Save & Queue でビルド開始してみましょう。

なお、YAML の定義がおかしい場合、Queue 実行時にわかります。ちょっとタイミング遅いですね。

問題なく YAML が解釈できればビルドが開始するでしょう。

ビルド画面

ビルド画面はリアルタイムでビルド状況が表示されます。ここで YAML のパイプラインがわかります。ビルドUIでわからないのがやはり嫌ですね。

うまく変数も解釈され、ビルドが成功しました。

まとめ

Hosted Agent でしか動かないのが苦しいですが、おおよそ機能は満たしていていい感じです。

VSTS をこれからちょっと使ってみる、iOS ビルドで触ってみる (Hosted Agent on macOS) 場合にはYAML定義が慣れ親しんでいることが多いのでいいと思います。他のビルドサービスより癖が強く YAML 定義のハードルが高いのでなんとかしてほしいですね。

現状の利用シーン

エージェントが弱いのでほどほどの開始から、という印象ですが Private Agent がきたらすぐにでも使えそうですね。

  • Recommend: Your Project is Simple enough includes pipeline count and parameters
  • Recommend: Your Project is referencing variables with many pipelines. yaml offers easy view checking
  • Accept: yaml <-> pipeline conversion is not available
  • Accept: Private Agent is not available

VSTS yaml ビルドのここが苦しい

  • Checkout options: Tag sources, Report build status, Checkout submodules
  • Hosted Agent のみ対応
    • Private Agent対応していないので強いのがほしいときに非力
    • Hosted Agent がかなり非力で大きなリポジトリのビルドが現実的な時間でできないので致命傷になりかねない
  • パラメータなに使えるかとか初見殺し
    • ぽちぽち作成 -> yaml 生成しないとむりぽ
    • Circle CI とかだとコマンド実行しか露出させないのに対してパイプラインのカスタム要素で構築していく VSTS スタイルだときっつい
    • Store のパイプラインのところとかで、パラメータ提供してくれないときつそう
  • yaml定義はパイプラインには出ない
    • パイプラインの途中だけ無効とかが当然できない
    • パイプラインの内容を yaml 翻訳はできても yaml -> パイプライン翻訳ができてないので制約としは自然
  • yaml -> ふつうのパイプライン、ふつうのパイプライン -> yaml の変換ができない
    • 新しく作るしかない...

ここは嬉しい

  • dotnet みたいにグループ定義になっている場合にParameters として変数見えてるので設定しやすい
  • ビルドステップが単純なら各ブランチビルド定義が楽ちん
  • 変数が定義しやすいのは相当楽。見通しいい
  • UIぽちぽちから yaml 出力できるので定義が楽にテンプレート組める
    • ただし、これがただしいとは限らない
    • 変数が抜けていたりする

*1:Windows な Managed CI Service は VSTS か AppVeyorぐらい

*2:Git リポジトリを Github 以外で管理するメリットがかなり薄いのもあり微妙

*3:ブランチ切って履歴から抹消という手もありますが、そこはチームにお任せで

.NET Core App を Docker コンテナとして公開する

C# を使っていて最も困るのがランタイムと感じます。

C#は書きやすい、Visual Studio も使いやすいは良く耳にします。実際享受しやすいメリットだと思いますが、C# を Windows 以外で実行したいはどうでしょうか?

今回はその実行方法についてコンテナを用いるのはどうかと考えたメモです。

※ モバイルではなく、サーバー/デスクトップにおけるアプリケーションについて考えます。

目次

感じる課題

.NET を実行するときにはランタイムが必要です。現在、 Windows / macOS / Linux など色々な環境で同じように動かす場合は .NET Core が用いられます。簡単に実行を実行を確認したい、さくっと試したい、使いたいというユースケースが大半を占めるのではないでしょうか。

これをはじめに考えてみます。

ランタイムの導入

ローカル開発でランタイムが入っている方が便利と感じるシーンは多いです。これは、エディタ/IDEでの開発でSDKやランタイム参照をしつつ動的に解決することが多いためで、「開発したい」に対して「インストール、導入」という手間なコストをかけても割が合うことが多いです。またツーリングからみても、今はまだランタイムをインストールする方が様々なツールとの統合も楽でしょう。*1

ではサクッと動かしてアプリを試したい。場合はどうでしょうか? 例えば、 .NET Core で書いたC# アプリを macOS で動かしたい、Linux で動かしたい*2、あるいはRasPi で動かしたい、むしろ Windows Server では? このような色々なプラットフォームで動かす場合は事情が変わると思います。

私は、動かしたいプラットフォームに合わせて「動かす」、ただこれだけのためにランタイムを入れるのは大変と感じるぐらいにはぐうたらです。いい感じのアプリがあった!ワンオフで動かしたい!.NET Core を使って動かせばいいの?そのランタイムはどうやって入れるの?なるほど、ランタイムをダウンロードしてインストールをこのアプリだけのためにするの.... 更新は? 実行の保証は? 面倒です。*3

例えば .NET Core の場合環境に合わせて実行ランタイムがあるのはご存知の通りです。

www.microsoft.com

C# をWindows で実行する分には.NET Framework が初めから入っていることもあり気にならなかったことが、マルチプラットフォームだとおっくうと感じるのが、今*4のC#に感じる障壁の高さと思っています。

実行保証

「アプリのロジック」ではなく、「アプリをどう実行するか」が C# にとっては大きな課題に感じると書きました。*5

他に気になることとして「プラットフォームでの実行保証」があります。環境によって動かしてみたら予想外の挙動をした。というのは、C# に限らず良くあることで様々な言語が平等に持つ課題です。

これも解決は単純で、手元に環境があればいいでしょう。では、環境どうやりましょうか、めんどくさくないですか?

コンテナはどうなのか

これらの課題は、Docker をはじめとしたコンテナ*6で一定の改善が期待できます。*7

例えば配布するコンテナイメージにランタイムが入っていれば、利用する側は docker run するだけで ランタイムを隠蔽*8して機能を実行できます。これは多くの言語で作成されたツールが活用しているようにC# だってもちろん同様にできます。

また、Windows でも macOS でもローカルコンテナでの動作が確認できれば、そのコンテナイメージを配布することで同じ挙動が期待できます。ポータビリティの高さは重要なのは言わずもがなです。

S3Sync - .NETCore で S3同期するツール

x00万を超える大量のアセットファイルを配信したいということをしたくなったときに、S3などのオブジェクトストレージがパット思いつきます。*9これを現実的な速度でS3と同期するためにツールを作りました。*10数年前に PowerShell で同様の同期ツールを書いたのですがx000ファイルを対象に書いていて大量のファイルだと遅かったので C# で書き直ししたものです。

Github にて S3Sync として公開しました。

github.com

ツールは、docker でも利用可能です。これは Dockerfile 専用のリポジトリを別途用意しています。

github.com

Docker hub はこちら。

https://hub.docker.com/r/guitarrapc/s3sync/

どんなことをしているのかを通して、Docker として公開する良さを考えてみます。

Docker hub での公開用リポジトリ

もともと単一リポジトリにしていたのですが、Docker hub での automated build と コードの更新/バージョン管理とずれるため分離しました。他のDocker Automated build をしている人も同様にしているようなので、まぁこれが素直なのかなと思いますがいいアイディアあったら教えていただきたく...。

今は、s3sync-docker リポジトリのmater/tag を使って自動ビルドしています。

これでバージョンに応じたタグでイメージも公開されるので楽ちんです。

docker hub 用の Dockerfile は、コード側リポジトリの指定バージョンのリリースに仕込んだバイナリを持ってくるようにして、コードのバージョンとコンテナのバージョンを合わせています。

FROM microsoft/dotnet:2.0-runtime
WORKDIR /app
ENV S3Sync_LocalRoot=/app/sync
RUN curl -sLJO https://github.com/guitarrapc/S3Sync/releases/download/1.2.0/s3sync_netcore.tar.gz \
    && tar xvfz s3sync_netcore.tar.gz \
    && rm ./s3sync_netcore.tar.gz
CMD ["dotnet", "S3Sync.dll"]

.NET Core と .NET4.7 ビルド対応

両方のビルド対応は、凝ったことはしておらず <TargetFrameworks>netcoreapp2.0;net47</TargetFrameworks> のみです。

https://github.com/guitarrapc/S3Sync/blob/master/source/S3Sync/S3Sync.csproj#L6

Docker でのアセンブリビルド

Visual Studio の Docker Support が、いまいちイケテナイというか結構癖あって docker 触るだけのためにその構成は苦しい。ということで、ベースとしつつ組んでいます。*11

Microsoft からはこのあたりで

docs.microsoft.com

Docker からも出てるのでこのあたりみつつがいいです。

https://docs.docker.com/engine/examples/dotnetcore/docs.docker.com

Docker for Windows / Docker for Mac だけ入れておくと Docker 操作ができます。*12

さて、dotnet build ビルドを、VSと docker のどちらでも行えます。Docker を使ったビルドが楽なのは手元にdotnet ランタイムがなくてもビルドできることで、ビルド結果がどのOSでも変わらず取得できます。.NETCore をビルドするのにランタイムが必要、という都合を気にしないで使うというのは良さを感じます。

Docker でのビルドをするにあたり、以下のような docker-compose.yml を用意してあります。

version: '3'

services:
  ci-build:
    image: microsoft/dotnet:2.0-sdk
    volumes:
      - .:/src
    working_dir: /src
    command: /bin/bash -c "dotnet restore ./S3Sync.sln && dotnet publish ./S3Sync/S3Sync.csproj -c Release -o ./obj/Docker/publish -f netcoreapp2.0"

S3Sync/source パスで docker-compose -f docker-compose.ci.build.yml up をコマンド実行することでdocker コンテナ内部で dotnet build が実行され、S3Sync/source/S3Sync/obj/docker/publish にdotnet build によって生成されたアーティファクトができます。

$ docker-compose -f docker-compose.ci.build.yml up
Starting source_ci-build_1 ...
Starting source_ci-build_1 ... done
Attaching to source_ci-build_1
ci-build_1  |   Restoring packages for /src/S3Sync.BenchmarkCore/S3Sync.BenchmarkCore.csproj...
ci-build_1  |   Generating MSBuild file /src/S3Sync.BenchmarkCore/obj/S3Sync.BenchmarkCore.csproj.nuget.g.props.
ci-build_1  |   Generating MSBuild file /src/S3Sync.BenchmarkCore/obj/S3Sync.BenchmarkCore.csproj.nuget.g.targets.
ci-build_1  |   Restore completed in 225.41 ms for /src/S3Sync.BenchmarkCore/S3Sync.BenchmarkCore.csproj.
ci-build_1  |   Restoring packages for /src/S3Sync.Core/S3Sync.Core.csproj...
ci-build_1  |   Restoring packages for /src/S3Sync/S3Sync.csproj...
ci-build_1  |   Generating MSBuild file /src/S3Sync/obj/S3Sync.csproj.nuget.g.props.
ci-build_1  |   Generating MSBuild file /src/S3Sync.Core/obj/S3Sync.Core.csproj.nuget.g.props.
ci-build_1  |   Generating MSBuild file /src/S3Sync/obj/S3Sync.csproj.nuget.g.targets.
ci-build_1  |   Generating MSBuild file /src/S3Sync.Core/obj/S3Sync.Core.csproj.nuget.g.targets.
ci-build_1  |   Restore completed in 78.35 ms for /src/S3Sync.Core/S3Sync.Core.csproj.
ci-build_1  |   Restore completed in 74.78 ms for /src/S3Sync/S3Sync.csproj.
ci-build_1  | Microsoft (R) Build Engine version 15.5.179.9764 for .NET Core
ci-build_1  | Copyright (C) Microsoft Corporation. All rights reserved.
ci-build_1  |
ci-build_1  |   Restore completed in 18.76 ms for /src/S3Sync.Core/S3Sync.Core.csproj.
ci-build_1  |   Restore completed in 3.33 ms for /src/S3Sync/S3Sync.csproj.
ci-build_1  |   S3Sync.Core -> /src/S3Sync.Core/bin/Release/netcoreapp2.0/S3Sync.Core.dll
ci-build_1  |   S3Sync -> /src/S3Sync/bin/Release/netcoreapp2.0/S3Sync.dll
ci-build_1  |   S3Sync -> /src/S3Sync/obj/Docker/publish/
source_ci-build_1 exited with code 0

$ ls S3Sync/obj/Docker/publish

Docker コンテナビルド

コンテナと配布するにはローカル実行を試しておきたいので、コンテナイメージのビルドもしましょう。これも 以下のような docker-compose.yml を用意してあります。

version: '3'

services:
  s3sync:
    image: guitarrapc/s3sync
    build:
      context: ./S3Sync
      dockerfile: Dockerfile

ローカルビルド用の Dockerfile は次のようなものです。

FROM microsoft/dotnet:2.0-runtime
ARG source
WORKDIR /app
ENV S3Sync_LocalRoot=/app/sync
COPY ${source:-obj/Docker/publish} .
CMD ["dotnet", "S3Sync.dll"]

S3Sync/source パスで docker-compose build をコマンド実行することでdocker イメージがビルドできます。

$ docker-compose build
Building s3sync
Step 1/6 : FROM microsoft/dotnet:2.0-runtime
 ---> c3e88dec1c1a
Step 2/6 : ARG source
 ---> Using cache
 ---> 647c269a901b
Step 3/6 : WORKDIR /app
 ---> Using cache
 ---> 6b3ed8b5ba59
Step 4/6 : ENV S3Sync_LocalRoot /app/sync
 ---> Using cache
 ---> 0e5b9c7353eb
Step 5/6 : COPY ${source:-obj/Docker/publish} .
 ---> 9eef14226f86
Step 6/6 : CMD dotnet S3Sync.dll
 ---> Running in 8ceb9cd9194d
 ---> 7e32766ae910
Removing intermediate container 8ceb9cd9194d
Successfully built 7e32766ae910
Successfully tagged guitarrapc/s3sync:latest

イメージの生成 は docker image ls で。

$ docker image ls
REPOSITORY                   TAG                 IMAGE ID            CREATED             SIZE
guitarrapc/s3sync            latest              b33b90c72cee        6 hours ago         220MB

ローカル実行

exe / .NETCore / Docker のいずれもローカル実行ができます。IAM Role で認証をバイパスできない場合は、AWS Credential Profile を利用します。*13

同期パラメーターは、引数か、環境変数で指定できます。デフォルトで DryRun が有効になっているので、同期を実行する場合は「引数で DryRun=false」 か 「環境変数 でS3Sync_DryRun=false」 してください。

https://github.com/guitarrapc/S3Sync#configuration

# Full .NET
$ S3Sync.exe BucketName=your-fantastic-bucket LocalRoot=C:/Users/User/HomeMoge DryRun=false
# dotnet core
$ dotnet S3Sync.dll BucketName=your-awesome-bucket LocalRoot=/Home/User/HogeMoge DryRun=false
# docker
$ docker run --rm -v <YOUR_SYNC_DIR>:/app/sync/ -e S3Sync_BucketName=<YOUR_BUCKET_NAME> -e AWS_ACCESS_KEY_ID=<YOUR_ACCESS_KEY> -e AWS_SECRET_ACCESS_KEY=<YOUR_SECRET> S3Sync_DryRun=false guitarrapc/s3sync

Docker イメージは Windows/mobyLinux/macOS 上で動作を確認しています。

速度

ベンチマークを測る中で速度自体は、.NET4.7 も .NETCore2.0 もあまりずれは出ていません。

.NET Core で遅くなるかもと思っていたので、なるほど計測大事。

ec2 で実行しているのですが、CI の記録では 20000ファイルで20sec 程度のようです。350000ファイルぐらいだと、初回のアップロードが6minで、以降差分であれば100sec 程度のようです。

Complete : Calculate Diff. 10.01sec
-----------------------------------------------
Start : Upload to S3. New = 0, Update = 0)
-----------------------------------------------
Complete : Upload to S3. 0.11sec
-----------------------------------------------
Start : Delete on S3. (0 items)
-----------------------------------------------
Complete : Delete on S3. 0sec
===============================================
Detail Execution Time :
-----------------------------------------------
Obtain S3 Items : 3.32sec
Calculate Diff  : 10.01sec
Upload to S3    : 0.11sec
Delete on S3    : 0sec
-----------------------------------------------
Total Execution : 13.44sec, (0.22min)
===============================================
===============================================
Show Synchronization result as follows.
===============================================
| TotalCount  | New  | Update  |  Skip  | Remove |
| ----------: | ---: | ------: | -----: | ------: |
|      20000  |   0  |      0  | 20000  |      0 |
Complete : Synchronization. 13.69sec
Total. 20.54sec

MSDeploy のようなファイル同期だと恐ろしく時間がかかりますが、S3などオブジェクトストレージだと手早くできるのはいいですね。

課題

.NETCore だと、大量のファイルを送信すると時々通信が打ち切られる現象を確認しています。何度か遭遇しているのですが、発生原因がいまいち見えず困っています。そのため、.NET4.7 で実行するのが安定していて、こまったちゃんです。

github.com

まとめ

docker run で C# で書いたアプリが実行できる。dockerを日常的に触っていると、アプリを試したりどこか環境を変えて利用するには一番楽です。

利用する側にとって「使うための準備を最小限にする」というのは重要だと考えています。この意味で、これから .NET Coreで書かれたアプリが どんどん Docker で公開されるといいですね。特に、ASP.NET Core MVC とかは nginx 同様ホスティングするだけなのでやりやすいわけで。

*1:APIやHTTP(S) など通信で隠蔽できない場合を想定しています

*2:ディストリは本質ではないのでおいておきましょう

*3:もちろんやってきたのですが、面倒だと思っています

*4:そしてこれから

*5:個人の感想です。私がC# を各環境で動かすにあたっていつも感じる感想であって、読んでいる方にとっては別の課題をお持ちだと思います

*6:ハイパバイザーでいい人はそれでいいんじゃないでしょうか

*7:必ずしも最善ではないですが、現状では現実解として妥当と思います

*8:カプセル化と言い換えてもいいです

*9:BlobでもGCSでも好みで置き換えてください

*10:aws clie の s3 sync だと大量データの同期がCaused by : [Errno 104] Connection reset by peer) でおちるのもある

*11:dotnet restore できなくするのはワカルけどその解決でなぜ納得すると思うのか

*12: Linux Containers on Windows (LCOW)を使う - http://www.misuzilla.org/Blog/2017/12/27/Lcow を使うともうちょい楽そうです

*13:aws configure でも AWS Tools for PowerShell でも VS でも生成できるのでご随意に

2017年 に使ったサービス

選択はいたってシンプルにしています。

  • 基本的に無料のサービスでいいものがあれば使う
  • 有料のサービスでしかない場合は、必要性に応じて使うようにしている
    • 有料サービスはサブスクリプション以外は使わないようにしている

この状況って、いつでも状況に合わせてやめたり変更が効くようになるのだが、逆にいくらだったかなとなってしまうように思うです.... Money Foward できっちり管理してみようかしら。

ここで1回書き出します。

わたしの考えはごく単純です。

目次

有料継続

はてなブログProと GitKraken が異様に大きいですね。GitKraken はいいのですが、はてなブログ Pro は本当に変え時かもしれない。

サービス名 価格 種類 用途
AWS $2.64/month クラウド Route53 / Lambda / S3
Flawless $30/永年 iOS開発 デザインとシミュレートの確認
Github $7.00/month DVC Private Repository が使いたいのとメインストリームだから
GitKraken $49/user/year Git GUI Git 操作にWindows/Mac 両方で利用
G Suite Basic ¥600/user/moth オフィス Gmail / Group / Calendar / Drive & Document / Photo
Google Play Music ¥980/user/month 音楽 Google Home からの音楽再生
Jump+ ¥900/month 雑誌 そろそろおわりかな
TeamsId $3/user/month パスワード管理 チーム管理の楽さが神がかってる
Udemy コース次第 スクール 技術系の動画スクール
Zaim Premium ¥360/month 家計簿 キャッシュフロー管理
はてなブログPro ¥8434/year ブログ 今使ってるマネージドなブログサービス

AWS

Route53 のみで課金されている。そろそろ GCP にしようと思っているのでRoute53 解約の兆し。(実は DNS 管理なら GCP のほうが安い)

Flawless

ちょうど安かった時に$15かったのでした。iOS 開発にめっちゃオススメ。

applech2.com

Github

2013年からずっと使い続けているが、Private Repository が数無制限になってかなり使いやすくなりました。

LFS は個人では使う必要なくて使ってない。

GitKraken

SourceTree を長年使っていて、どんどん操作が重くなっていったので乗り換え。

GitKraken にして、操作の待ちが消えた、Branch/Tag付けの操作容易さ、Conflict 解決が非常に楽になったことでかなりメリットを享受できています。

G Suite Basic

もともと会社で G Suite 使うにあたって普段から使い慣れておこうと思って始めたのがきっかけ。

Email 登録系のサービスによって グループメールにしたりオフィス系をこっちに寄せていて、完全に基幹になってる。

あと、使うサービスが Google 認証に対応しているかが利用の基準にもなってる。(SSO は大事です)

Google Play Music

Google Home で音楽を再生するにあたり、Spotify と悩んだ。

選択理由は使い勝手が一番の理由。Spotify がジャンル指定とか使いにくいと感じる一方で、Google Play Music は苦しさがなかった。

あとは、自分が聞く曲の多くがGoogle Play Music にあって Spotify になかった。(クラシックが多いです。ようは演奏者 * 曲の組み合わせ)

Jump+

OnePiece や Stone world が特に面白いです。読まずに忙しさにかまけることがあって、忙しさのバロメータにしていたり。

でもそろそろおわりかなぁ。

TeamsId

Meldium おわったので乗り換え。チームレベルでのパスワード管理できるのは本当に楽。

使ってて不満はほぼない*1

Google ログインえらい。

Udemy

知らないことを学ぶのにいい。

Zaim Premium

家計簿なのですが、クレジット連携したくてプレミアムにしたもののよく連携きれるしもういや。ってことで 2017年はほぼ能動的に使わずに過ごしてしまいました。

Money Forward を実は契約だけしてあるので、切り替え予定。

はてなブログPro

WordPress.com から はてなブログに移行してずっと使ってる。

主にカスタムドメインがProを使いたい理由。

はてなブログを選んでいる理由は、マネージドサービス + SEO 流入の良さ から。

ただ、https 移行のアクションの遅さを見るとそろそろやめようかと思ったり。Medium 一度試して辞めたのですが、記事の書き方を変えて使うようにしようかな?

Google ログインできるのえらい。

無料継続

サービス名 価格 種類 用途
Azure 無料 クラウド AzureFunctions / AppService / AKS メイン
CircleCI 無料 ビルド ビルド全般
Cloud Craft 無料 AWS構成図 構成図を描くのに便利
Docker Hub 無料 CR コンテナリポジトリ
Eight 無料 名刺 名刺管理
Fastly 無料 CDN 検証に Developer Account で。
Google Analytics 分析 はてなブログの分析
Google Adsense アド収入 やらないよりやってみようで
Grammarly 無料 校閲 英語の校閲
Heroku 無料 PaaS Python 系とか乗っける時に
inVision 無料 プロトタイピング 他はいらない
Kibela 無料 Wiki ドキュメント/Wiki/ Blog / 勉強会メモ
GCP 無料 クラウド Firebase / Cloud Functions
Slack 無料 チャット 通知とかチャット、メモ、RSSとか
Visual Studio 2017 Enterprise MVP特典 IDE C# での開発全般
Visual Studio App Center 無料 ビルド iOS/Androidビルド
Visual Studio Team Service 無料 ビルド Windows系/Azure系ビルド
Wunderlist 無料 TODO TODOの管理
一休 無料 予約 レストラン、ホテル他

Azure

主に技術検証や無料内でのサービス利用なので無料枠で足りてる。

AzureFunctions の JapanWestPlan (Consumption: 0 Small) だけ $5.7 と思いきや、Visual Studio Enterprise の枠ないで収まっており無料。

Circle CI

ビルドサービスとして利用している。2.0 でコンテナになっていい感じ。

iOS ビルドどうするか検討中。

ビルドサービスは複数扱えると何かと良さの検討になるので無料内は使っておく

Cloud Craft

AWS の 3D的な構成図書くのにちょくちょく使ってる。

Google ログインできるのえらい。

Docker Hub

コンテナのリポジトリ管理

Eight

名刺管理最高。名刺もらってもすいませんがいらないです。Eight で交換が最高。

Fastly

開発向けの Developer Account の範囲で検証に利用。

GCP

Firebase や Cloud Functions に使っているが無料内なので課金なし。

当然ですが、Google ログインできるのえらい。

Google Analytics

はてなブログの閲覧はこいつでとってます。

Google Adsense

広告を出さないための Pro だからこそ、広告ってどれぐらいの効果で目的を持てるのかを測るために入れてみました。

Grammarly

たいぽつぶし、経度な文法のミス。

Heroku

なにかとしれっと乗っけるには便利。最近は使う頻度減った。

GAE でいいかなという気分。

inVision

もう他いらないです。最高。free で結構十分使える。

Kibela

esa.io をドキュメントに利用していたが、個人利用の範囲だと kibela でいい気がしてきたので乗り換えた。

Google ログインできるのえらい。だが、一度ログインしてから設定なのは結構いや。イケテナイ。

Slack

チャットはこいつ。今のところ他いらない。

Visual Studio 2017 Enterprise

以前は Pro 買ってた。個人で使う分には、Visual Studio Community で困らない感じする。

CodeLens が Community にきたのは大きい。

Visual Studio App Center

モバイルビルドに使っている。

ビルドサービスは複数扱えると何かと良さの検討になるので無料内は使っておく

パイプラインが使えず、割り込み処理をスクリプト定義なのでいや。

Visual Studio Team Service

Windows 系のビルドに使ってる。

ビルドサービスは複数扱えると何かと良さの検討になるので無料内は使っておく

Wunderlist

TODO として。なくなるらしいけど乗り換え先見つからない...。

一休

便利。好きな会社、好きな人が働いていることもあるけど、必要な時に重宝してる。

普段からは使ってない。

解約したサービス

サービス名 価格 解除 用途
esa.io ¥500/user/month Wiki ドキュメント、Wiki、勉強会メモ -> kibela に乗り換え
Meldium 無料 パスワード管理 Discontinue
ReSharper $299/user/year VS Extension VSの強化 -> 不要
Unity Plus $37.80/月 2018/1 マルチプラットフォームなゲーム/3D開発 -> 不要

esa.io

ドキュメントに利用していたが、個人利用の範囲だと kibela でいい気がしてきたので乗り換えた。

有料の範囲で不満はなかったが、個人としてはほぼ同等機能の場合に無料が勝った。

Google ログインできるのえらい。

Meldium

おわこん..。

ReSharper

VS2017 でReSharper で使ってた機能入っていらなくなった。

重すぎ。

Unity Plus

しばらく Plus を使ってきたが、おおよそすべての開発は Free で十分できるようになった。

アセットストアの月一お得も含めて特典になるのだが、加味した上で個人ユースでは解除でいいと判断した。

Free でいいといえる判断ができるようになったぐらいには、Free は強力になりました。すごい。

store.unity.com

検討して使わなかったサービス

LastPass

いやぽ。使い勝手も悪い。

OneLogin

使い勝手悪い

OnePassword for Team

ないです。使い勝手最悪

Office365 Solo

G Suites で十分以上に事足りているため。

Tower

Git UI が面白くない。操作が別に GitKraken よりいいと思えるものもなかった。だったら GitKraken でいい。

*1:Google 認証の定めとしてChromeツールバーでログイン解けること多いぐらい