The dawn of modern programmers

現代プログラマーの朝焼け

How to uninstall specific (preview) version .NET Core SDK from macos

I'm in trouble...

待望の .NET Core SDK 2.1 がリリースされました!

blogs.msdn.microsoft.com

というわけで、現在のメインマシンである Macbook Pro .NET Core SDK 2.1 RC-1 をアンインストールして、SDK 2.1 をインストールしようとしましたが。。。

どうやってアンインストールするんだろう?

Windows では、「プログラムの追加と削除」から削除できる。 Linux では各ディストリビューションのパッケージマネージャの機能で削除できる。 MacOS では。。。

というわけで実行した方法を公開します。

How to uninstall .NET Core SDK from macos

すべてのバージョンをアンインストールする方法は Shell Script が提供されています。

github.com

ここでは上記を参考に手動でアンインストールを実行していきます。

1. Remove packages

まずは インストールされている .NET Core のパッケージをリストアップします。

pkgutil --pkgs | grep -i microsoft.dotnet

削除したいバージョンのパッケージを削除します。

sudo pkgutil --force --forget com.microsoft.dotnet.hostfxr.2.1.0-rc1.component.osx.x64
sudo pkgutil --force --forget com.microsoft.dotnet.dev.2.1.300-rc1-008673.component.osx.x64

2. Remove files

pkgutil コマンドでは MacOS のパッケージを削除することができないので実際に SDK と Runtime のファイルを削除します。

下記のコマンドを実行して SDK のファイルパスを確認します。

dotnet --list-sdks

SDK のファイルを削除します。

sudo rm -rdf /usr/local/share/dotnet/sdk/2.1.300-rc1-008673

次はランタイム

dotnet --list-runtimes

ランタイムファイルを削除します。

sudo rm -rdf /usr/local/share/dotnet/shared/Microsoft.NETCore.App/2.1.0-rc1
sudo rm -rdf /usr/local/share/dotnet/shared/Microsoft.AspNetCore.App/2.1.0-rc1-final
sudo rm -rdf /usr/local/share/dotnet/shared/Microsoft.AspNetCore.All/2.1.0-rc1-final

Summary

若干手間がかかりますが、特定のバージョンを MacOS から削除することができました。

((~/.dotnet ディレクトリ内にもキャッシュファイルがあるのですが、こちらは今の所削除していません。))

nginx Reverse Proxy on Docker

Why we use nginx reverse proxy

昨今、多くのサービス、システムで Microservices Architecture (MSA) が採用されるようになっています。 MSA では各アプリケーション(サービス)は独立した Web アプリケーションとして構築・配置されます。 利用ユーザーはあくまでサービスの集合を”アプリケーション” として利用しているため、利用ユーザーがアクセスする URL は1つに統合されているべきです。 また、各 Web アプリケーションごとに DNS の設定や、SSL 証明書の設定、管理などの運用作業の負荷は思いのほか高く、またミスによる障害が発生する要因ともなります。 このような課題に対応するために Reverse Proxy を利用します。 この記事では Reverse Proxy を nginx (軽量な Web Server)を利用して、Docker Container として稼働させる方法について説明します。

What is pass proxy

この記事では nginx の Reverse Proxy 機能の中でも “pass proxy” の設定について説明します。 pass proxy でどのように Web アプリケーションにアクセスするのかは下記の図を参照してください。 ここでは www.eshop.com というアドレスとルートパスによって各アプリケーションに HTTP リクエストを Porxy するようにしています。

f:id:chegue:20170330123514p:plain

Applciation Application Address Proxy Address
Catalog 10.0.0.1 https://www.eshop.com/catalog
Basket 10.0.0.2 https://www.eshop.com/basket
Order 10.0.0.3 https://www.eshop.com/order

How to configure nginx.

nginx pass proxy の設定は nginx.conf ふぃあるに記述します。 下記はサンプルです。

設定は下記の通りです。 * server セクション で nginx サーバーの DNS 名を指定します。 * location セクションに HTTP 要求のパスを記載します。 * proxy_pass セクションに Porxy する Web アプリケーションの IP アドレスを指定します。

この設定により、各アプリケーションの IP アドレスを外部に公開する必要がなくなります。

e.g. Pass proxy from www.eshop.com to 10.0.0.1

http {
    include /etc/nginx/mime.types;
    default_type    application/octet-stream;

    sendfile    on;
    keepalive_timeout   65;
    server{
        server_name    www.eshop.com;
        proxy_set_header    Host    $http_host;

        location /catalog/ {
            proxy_pass    http://10.0.0.1/;
        }
    }
}

How to run nginx pass proxy

nginx を Docker Container として実行するには下記のコマンドを利用します。(簡単!)

 docker run --name nginx-pass-proxy -v ./nginx.conf:/etc/nginx/nginx.conf:ro -d nginx

次回以降は、

  • 動的な proxy_pass の設定
  • SSL による暗号化とアクセラレーション

について記事にしたいと思います。

How to run Kubernetes on local machine (Docker for Windows)

Summary

現在、多くのクラウドプラットフォーム で Kubernetes をベースとした Container Service が提供されいています。

しかし、検証や Pods の構成を試すために Container Service をセットアップし、接続するのはとても大変ですしコストもかかります。 (結構めんどくさい。。。)

ここではローカルマシンで Kubernetes を実行可能な minikube のインストールと実行方法について説明します。

Download and install “minikube”

Download minikube

まずは Kubernetes を実行するための minikube の新ストールを行います。

最新のリリースバージョンのバイナリファイルを GitHub からダウンロードします。

https://github.com/kubernetes/minikube/releases/

ここでは Windows/amd64 を選択します。

Install minikube

ダウンロードされたバイナリを “minikube.exe” に re-name します。 minikube.exe ファイルを任意のフォルダに移動します。

e.g.

%USERPRFILE%\Apps\kubernetes

環境変数に KUBE_HOME を追加します。

環境変数 PATH に %KUBE_HOME% を追加します。

Download and install “kubectl”

Kubernetes に接続し、操作を行うための “kubectl” コマンドをインストールします。

安定バージョンの確認

CURL コマンドで安定バージョンを確認します。

curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt

最新の安定バージョンをダウンロードします。

curl -LO https://storage.googleapis.com/kubernetes-release/release/<LATEST_VERSION>/bin/windows/amd64/kubectl.exe

ダウンロードしたファイルを %KUBE_HOME% に移動します。

Setup your Hyper-V Virtual Network.

minikube は内部でインターネット経由でのイメージのダウンロードを行っているため、実行にはインターネット接続を行える必要があります。 また kubectl コマンドから接続を行うためには Hyper-V の仮想スイッチの設定が “外部ネットワーク” に設定されている必要があります。

Docker for Windows のインストール時に “Docker NAT” の名称で仮想スイッチが作成されていますので、このスイッチの設定を変更しておきます。

Run Kubernetes

実行コマンドはたった一つ。So easy! (必ず管理者権限で実行してください!)

# minikube start --vm-driver=hyperv

Connect by kubectl

kubectl コマンドを使って minikube を操作します。 まずは context を minikube に切り替えて、minikube に hello を配置してみます。

kubectl config use-context minikube
kubectl run hello-minikube --image=gcr.io/google_containers/echoserver:1.4 --port=8080
kubectl expose deployment hello-minikube --type=NodePort

How to build REST plugin module for Atlassian applications.

Atlassian アプリケーション (Bamboo) 向けに REST API プラグインを作成した際に、苦労したポイントがあったので記事にしておきます。

準備作業

プラグインの作成と動作確認は Atlassian 社から提供されている Atlassian SDK を利用します。 Maven プロジェクトの作成から実際にサーバーアプリケーションによるプラグインの動作確認までのコマンドが提供されています(スゴイ便利)。

  • 下記のサイトから Atlassian SDKインストーラーバイナリをダウンロードします。

Downloads - Atlassian Developers

Plugin プロジェクトの作成

Atlassian SDK のインストールが完了したら、Plugin 開発プロジェクトを作成します。 こちらは Atlassian SDK が提供するコマンドでセットアップできます。 よく考えられていますね。ここでは Bamboo のPlugin開発プロジェクトを作成します。

# atlas-create-bamboo-plugin

実行すると Maven Pom.xml の作成に必要な項目がプロンプトされますので必要な項目を設定します。

Define value for groupId: : org.esheeps.bamboo.plugin
Define value for artifactId: : bamboo-rest-plugin
Define value for version: 1.0.0-SNAPSHOT: : 1.0.0-SNAPSHOT
Define value for package: org.esheeps.bamboo.plugin: : org.esheeps.bamboo.plugin

プロジェクトの作成が完了するまでに5-10分程度かかります。

ローカル Maven リポジトリの状態によっては失敗することもありますので、 {$userprofile}/.m2 ディレクトリ内をクリアしておくことを強くお勧めします。

Plugin の実装

構成ファイルの編集

Atlassin アプリケーションの Plugin は resources/attlasian-plugin.xml ファイルで設定されます。 REST API の追加はこの XML ファイルに設定します。

rest タグで REST API の URL を設定しています。

<atlassian-plugin key="${atlassian.plugin.key}" name="${project.name}" plugins-version="2">
    <plugin-info>
        <description>${project.description}</description>
        <version>${project.version}</version>
        <vendor name="${project.organization.name}" url="${project.organization.url}" />
        <param name="plugin-icon">images/pluginIcon.png</param>
        <param name="plugin-logo">images/pluginLogo.png</param>
    </plugin-info>\

    <!-- add our i18n resource -->
    <resource type="i18n" name="i18n" location="bamboo-plan-rest-plugin"/>

    <rest name="Bamboo Build Plan Resource" key="bamboo-plan-rest-resource" path="/apps" version="1.0">
        <description>The Bamboo Build Plan Resource Plugin</description>
    </rest>
    
</atlassian-plugin>

上記の設定では下記のような URL になります。

http://<host>:<port>/<applicationpath>/rest/apps/1.0/<restresourcepath>

REST Resource Class の実装

REST Resource は JAX-RS (Jersey) を実装します。

@Path("/buildplan")
public class BuildPlanResource {

    private PlanManager planManager;

    public BuildPlanResource() {
        this.planManager = (PlanManager) ContainerManager.getComponent("planManager");
    }

    @GET
    @Produces({ MediaType.APPLICATION_JSON, MediaType.APPLICATION_XML})
    @Path("/plans/{key}")
    public Response getPlan(@PathParam("key") String key) {
        PlanKey planKey = PlanKeys.getPlanKey(key);
        Plan plan = planManager.getPlanByKey(planKey);
        
        BuildPlan buildPlan = new BuildPlan();
        buildPlan.setBuildKey(plan.getBuildKey());
        buildPlan.setBuildName(plan.getBuildName());
        buildPlan.setProjectName(plan.getClass().getName());
        
        return Response.ok(buildPlan).build();
    }

}

ここで大きな落とし穴があります。

Atlassian Plugin では Plugin 内でアプリケーションが提供するコンポーネントを Spring OSGi によるインジェクションで利用するようにするとありますが、 REST Resource に関しては、@Inject, @ImportComponent 属性を利用すると、プラグインが有効になりません。。。

公式なドキュメントに記載がないので動作する実装ということになるのですが、 ContainerManagerからコンポーネントインスタンスを取得するようにします。

this.planManager = (PlanManager) ContainerManager.getComponent("planManager");

Plugin の実行と動作確認

Plugin を実行するには下記のコマンドを Plugin 開発プロジェクトのルートディレクトリで実行するだけです。

# atlas-run

atlas-run コマンドを実行すると、

  • Maven ビルド

  • Bamboo サーバーのダウンロード

  • Plugin のインストール

  • Bamboo サーバーの実行

がすべて行われます(すげー!)。

ただし、時間もかかります。初回は15-30分程度、次回以降も5分程度はかかります。 ちょっとしたコーヒーブレークですね。

Quick Reload が有効ですので、別ターミナルで

atlas-mvn package

を実行して Plugin を変更することができます。

動作確認時の注意点

Spring OSGi の実装が誤っていた場合など特定の条件では、 そもそも Plugin が有効にならないことがあります。 この際にはログを注意深く確認してエラーの内容を確認してください。

MSDN データプラットフォームデベロッパーセンター に対談記事が公開されました。

MSDN データプラットフォームデベロッパーセンターに私が参加させていただいた対談の記事が公開されました。

「マイクロソフトのデータ アクセス技術の変移」(対談記事)

マイクロソフトの野村さん、赤間さん、小高さんという錚々たるメンバーと対談させていただけて非常に光栄です。
ディスカッションのテーマは「マイクロソフトのデータ アクセス技術の変移」ということで、昨今の .NET Framework のデータアクセステクノロジについて様々な意見を交換させていただきました。

小高さんもブログで書かれていますが、非常に意見が多かった(濃かった)ため記事かに際してご苦労をおかけしてしまいました。

データアクセステクノロジについての「ぶっちゃけた話」を読みたいという方には是非おすすめです。

Microsof Tech Fielders にインタビュー記事が公開されました

Microsoft Tech Fielders にインタビュー記事が掲載されました。
インタビュアーは小高さんに担当していただきました。
#長々とお話ししてしまったにも関わらず簡潔にまとめていただき本当にありがとうございます。

アーキテクチャーの大切さを伝えていきたい

若輩ですが、これまでの経験からアプリケーションアーキテクチャについての私の思いを込めてお話しさせていただきました。
これからエンタープライズで設計・開発に携わる方に少しでも伝えられることがあれば幸いです。

デブサミ2009 終了

2月12日(金) に開催された「デベロッパーサミット 2009」の
弊社森屋の講演「M + MVC 〜最新マイクロソフトWeb 開発動向 Ruby on Rails に追いつけ!追い越せ!〜」に コードアシスタント(黒子)として登壇させていただきました。

"Code Live" をコンセプトに 50分間で M 言語によるモデリングから ASP.NET MVC Framework による Commerce サイトの作成までをスクラッチデモさせていただきました。

基本的なテクノロジーの説明を削ぎ落とし、デモに集中したのはひとえにデベロッパーの皆さんにプログラミングで感動してほしいという弊社社長の熱い思いからです。
「50分でもあれだけのことができる」、「自分もぜひこの技術に触れてみたい」と思っていただければ幸いです。

黒子としての参加でもデベロッパーの皆さんを前に Code Live を実現できたのは本当に素晴らしい体験でした!

今後とも宜しくお願い致します。