How to uninstall specific (preview) version .NET Core SDK from macos
I'm in trouble...
待望の .NET Core SDK 2.1 がリリースされました!
というわけで、現在のメインマシンである 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 が提供されています。
ここでは上記を参考に手動でアンインストールを実行していきます。
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 するようにしています。
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
次回以降は、
について記事にしたいと思います。
How to run Kubernetes on local machine (Docker for Windows)
Summary
現在、多くのクラウドプラットフォーム で Kubernetes をベースとした Container Service が提供されいています。
- Amazon EC2 Container Service
- Google Cloud Platform Container Engine
- Microsoft Azure Azure Container Service
しかし、検証や Pods の構成を試すために Container Service をセットアップし、接続するのはとても大変ですしコストもかかります。 (結構めんどくさい。。。)
ここではローカルマシンで Kubernetes を実行可能な minikube のインストールと実行方法について説明します。
Download and install “minikube”
Download minikube
まずは Kubernetes を実行するための minikube の新ストールを行います。
最新のリリースバージョンのバイナリファイルを GitHub からダウンロードします。
https://github.com/kubernetes/minikube/releases/
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 プロジェクトの作成から実際にサーバーアプリケーションによるプラグインの動作確認までのコマンドが提供されています(スゴイ便利)。
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 コマンドを実行すると、
がすべて行われます(すげー!)。
ただし、時間もかかります。初回は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 を実現できたのは本当に素晴らしい体験でした!
今後とも宜しくお願い致します。