本物のクラスタを利用してkubectl pluginをテストする - GeekFactory
kubectlのプラグインを開発していると、ユニットテストだけでなく、本物のKubernetesクラスタを利用したテストが欲しくなります。プラグインの振る舞いが複雑な場合は自動テストがあると安心してリリースできます。 本稿では、本物のKubernetesクラスタを利用してkubectlプラグインをテストする方法を考えます。 テストの基本形 本物のクラスタを利用してプラグインをテストするための構成を下図に示します。 必要なのは以下の3つです。 テスト対象のプラグイン テスト対象が依存するクラスタやリソース テストシナリオ テストの流れは以下のようになります。 クラスタを作成する。 必要なリソースをデプロイする。 kubectlを実行する。 間接的にkubectl pluginが実行される。 実行結果が期待通りか検証する。 このようなテストはプラグインのリリース前に手動でやっていることが多いと
golang.org/x/tools/go/packages による構文解析と型解析 - GeekFactory
golang.org/x/tools/go/packages を利用すると，抽象構文木や型情報を利用したコードが簡単に書けるので調べてみました．日本語の情報があまりないようです． 抽象構文木を表示する Goのソースコードを読み込むには，packages.Load 関数を利用します．packages.Load 関数の引数にはどんな情報を解析してほしいかという設定を渡します．抽象構文木（AST）を取得するには下記のコードのようにフラグを渡します．ドキュメントを読むと packages.NeedSyntax だけで良さそうなのですが，実際に実行してみると複数のフラグが必要でした． Load 関数の引数にはパッケージ名の配列を渡します．./helloworld, os/exec, ./... のような表記が使えます． package main import ( "go/ast" "log" "os
新しい技術を学ぶ時のアプローチ - GeekFactory
新しい技術を学ぶ時にどのようなアプローチを踏むことが多いのか書き出してみました。具体的には、新しい言語、フレームワーク、インフラ、アーキテクチャ、プロセス、考え方などを学ぶことを考えます。 名前を知る（ポータル、SNS、Podcast等） 特徴を知る（公式サイト、ブログ等） どれぐらい有名なのかを知る（GitHub、Google Trend等） コミュニティで情報を得る（勉強会、カンファレンス） チュートリアルを試す 小さなものを作る（Hello World） 試してみた記事を公開する 個人開発で使う 作ったものをオープンソースで公開する 気付きをブログで公開する 気付きをコミュニティで発表する 詳しい人から情報を得る 導入に必要な情報をまとめる（特徴、リンク） チーム開発で使う 気付きをブログで公開する 気付きをコミュニティで発表する 動作原理を調べる（原典、コードを読む等） 動作原理を
特定URLへのアクセスを契機としたHTTPサーバのGraceful Shutdown - GeekFactory
Goで特定のURLへのアクセス（例：GET /shutdown）を受けたらHTTPサーバを停止するにはどうすればよいか考えてみました。 HTTPサーバを停止する http.Server にはGraceful Shutdownを行う Shutdown メソッドがあります。/shutdown へのリクエストを受けた契機で Server.Shutdown を実行すれば停止できそうです。 func main() { m := http.NewServeMux() s := http.Server{Addr: ":8000", Handler: m} m.HandleFunc("/shutdown", func(w http.ResponseWriter, r *http.Request) { s.Shutdown(context.Background()) }) if err := s.Liste
Spring MVCで所要時間付きのリクエストログを出力する - GeekFactory
Spring MVCのアプリケーションでリクエストログを出力するには CommonsRequestLoggingFilter を使うと簡単です。 リクエストログの設定 Spring Bootの場合は以下のように設定します。 @Configuration public class AppConfiguration { @Bean public CommonsRequestLoggingFilter requestLoggingFilter() { CommonsRequestLoggingFilter filter = new CommonsRequestLoggingFilter(); filter.setIncludeClientInfo(true); filter.setIncludeQueryString(true); filter.setIncludeHeaders(true);
Spring Bootアプリケーションのログファイル運用 - GeekFactory
Spring Bootアプリケーションのログファイル運用についてメモ。 前提 EC2などのクラウドのインスタンスで運用する場合を想定する。 ログ基盤に転送して蓄積する。 インスタンスに残っているログファイルは基本的に見ない。 Spring Bootのログ Spring Bootのログはデフォルトでは標準出力に出力される。ログファイルを出力するにはapplication.ymlで設定するか、JVMに起動オプションを渡す。 java -jar app.jar --logging.path="$LOG_PATH" 上記を指定すると、10MBのサイズでローテーションされる。最大で8世代まで保持される。 spring.log ←最も新しい spring.log.1 (10MB) spring.log.2 (10MB) … spring.log.7 (10MB) ←最も古い 最大世代に達した場合は最も
Spring BootアプリのテストをSpockで書く(続編) - GeekFactory
以前にSpring BootアプリケーションのテストをSpockで書く方法を紹介しましたが、この方法ではテストの所要時間が長くなる問題がありました。本稿では他の方法を紹介します。 int128.hatenablog.com 具体的には、インナークラスの @TestConfiguration でMockを定義するとSpecificationクラスごとにApplication Contextが再生成されてしまうため、スローテストの原因になる問題がありました。 // Specificationのインナークラス @TestConfiguration static class MockConfig { final detachedMockFactory = new DetachedMockFactory() @Bean ExternalApiClient externalApiClient() {
Spring BootでログやActuatorにバージョン情報を含める - GeekFactory
ログやActuatorにバージョン情報を含めておくと、本番環境でどのバージョンのアプリケーションが実行されているか簡単に確認できるので便利です。 ビルド時にapplication.ymlにバージョン情報を含める Gradleでは、以下のようなビルドスクリプトを書くとapplication.ymlの文字列を置換できます。 version = System.getenv('TAG_NAME') ?: 'SNAPSHOT' processResources { filter(org.apache.tools.ant.filters.ReplaceTokens, tokens: [ 'APP_NAME': project.name, 'APP_VERSION': project.version ]) } ここでは、ビルド時に TAG_NAME という環境変数にバージョン番号が設定されている前提で、
ターミナルのウィンドウタイトルにホスト名などを入れる - GeekFactory
久しぶりにzshネタです。 複数のタブを開いていろんなサーバにSSHしていると区別が付かなくなってきたので、ウィンドウタイトルに実行コマンド、ホスト名、カレントディレクトリを入れてみました。zshの組み込みコマンドだけで実現してみました。 function _window_title_cmd () { local pwd="${PWD/~HOME/~}" print -n "\e]0;" print -n "${pwd##*/} (${HOST%%.*})" print -n "\a" } function _window_title_exec () { local pwd="${PWD/~HOME/~}" print -n "\e]0;" print -n "${1%% *}:${pwd##*/} (${HOST%%.*})" print -n "\a" } [[ "$TERM" =~
Spring BootアプリのテストをSpockで書く - GeekFactory
Spring BootアプリケーションのテストをSpockで書く方法を説明します。最近のバージョンを対象にしています。 Spring Boot 1.4 Spock 1.1-rc-3 Groovy 2.4 本稿では以下のテストレベルを対象とします。 コンポーネントテスト（依存コンポーネントをモックに差し替えた状態でコンポーネントをテストする） E2Eテスト（依存コンポーネントをモックに差し替えた状態でAPIをテストする） まずは、build.gradleに依存関係を追加しておきます。 dependencies { testCompile 'org.springframework.boot:spring-boot-starter-test' testCompile 'org.spockframework:spock-core:1.1-groovy-2.4-rc-3' testCompile '
Spring Bootで例外発生時にJSONを返す - GeekFactory
Spring BootのREST APIサーバで例外発生時のエラー情報をJSONで返す方法を調べたのでメモです。 やりたいこと 例外が発生した場合は常にエラー情報をJSONで返したい。 例外の種類によってステータスコードを分けたい。例えば、バリデーションエラーが発生した場合は400、その他は500を返す。 Spring MVCの本来の振る舞いは変更しない。例えば、認可エラーで401を返す振る舞いは維持する。 実現方法 ErrorController インタフェースを実装すると、例外時のレスポンスをカスタマイズできる。 キャッチした例外によってステータスコードを変更する。 ステータスコードを指定できる例外クラスを作成します。実際のプロダクトでは、エラーコードやエラーメッセージを含む業務例外クラスを作成するとよいでしょう。 class AppException extends RuntimeE
Gradleで特定の条件を満たした場合にのみテストケースを実行 - GeekFactory
Gradleで特定の場合にのみテストケースを実行する方法を説明します。例えば、通常のテストケースはH2 Databaseを利用するけど、一部はテスト環境上のMySQLで実行したいといった場合を考えます。 基本的な考え方 JUnitのカテゴリ機能でテストケースをフィルタします。もしくは、パッケージ名でテストケースをフィルタします。 Gradleでは以下の2タスクを作成します。 カテゴリの付いていないテストケースを実行するタスク カテゴリの付いているテストケースを実行するタスク 開発環境では1だけ実行します。テスト環境では1と2の両者を実行します。 実装例 以下の例はGradleとSpockで書いていますが、JavaやJUnitでも同様です。 Spec ここでは、MySQLが必要なテストケースには RequireDatabase カテゴリを付けることにします。 interface Requir
Docker Machineで既存サーバにDockerホストを構築する - GeekFactory
Docker MachineはDockerホストを構築するためのツールです。VirtualBoxやVMwareなどの仮想化基盤、AWSやGCEなどのクラウドに対応しており、環境構築からDockerクライアントの接続設定まで自動的に行ってくれます。これによって気軽にDocker環境を調達できるようになります。 既存サーバにDockerホストを構築する Docker Machineでは、ドライバにGenericを指定することで、既存のサーバにDockerホストを構築することも可能です。Genericを指定したときにどんなコマンドが実行されるのか調べてみました。 下記のコマンドを実行すると、指定したサーバに対してSSH経由で一連の環境構築コマンドが実行されます。 docker-machine -D create --driver generic --generic-ip-address some
JVMベースのコマンドラインツールをHomebrewで配布する - GeekFactory
JavaVMで動くコマンドラインツールをHomebrewで配布する方法を説明します．JavaやScala，Groovyなどで書かれたツールをMacユーザに配布する際に役立ちます． Homebrewとは Mac OS Xで使えるパッケージ管理システムの一つにHomebrewがあります． Homebrewを使うと，ユーザは brew コマンドを実行するだけで新しいパッケージをインストールできます．また，デベロッパーはわざわざインストーラを用意する必要がなくなり，パッケージ本体とメタデータ（Formula）を公開するだけでソフトウェアを提供できるようになります． 例えば，OS Xでopensslを使いたい場合は，下記のコマンドを実行するだけでパッケージのダウンロードやビルドを行ってくれます． brew install openssl また，開発中の最新版を使いたい場合は，--HEAD引数を渡すこ
2014年に書いた記事の振り返り - GeekFactory
2014年に書いた記事を分類して振り返ります。 TLDR Gradle Docker Jenkins, Travis CI, Bintrayなどのビルド職人系 マネジメントの話 Scala, Groovy GitHub API, Evernote APIなどを使ってみた 運用改善 Gradle #JGGUG でGradle SSH Pluginについて話しました - GeekFactory GradleでビルドしてDockerで配布する - GeekFactory 今日から始めるGradleプラグイン開発 #gadvent - GeekFactory Gradleプラグインのテンプレートプロジェクトを公開します #gadvent - GeekFactory GradleによるJVMアプリケーションのパッケージングと配布 #gadvent - GeekFactory GradleでBintr
GradleでビルドしてDockerで配布する - GeekFactory
JGGUG LTにて、GradleでビルドしてDockerで配布するという内容を発表しました。ビールを片手にピザをつまみながら発表を聴くというゆるいスタイルで楽しかったです。 speakerdeck.com DockerがあればJVMをインストールする必要がなくなるので、GroovyやScalaで作ったツールを布教しやすくなるのではと思います。 何人かの方とお話ししたところ、Dockerを活用している開発現場は意外と多いようですね。2015年は本格的な普及期に入るのではないでしょうか。 皆様ありがとうございました。 Gradle徹底入門 次世代ビルドツールによる自動化基盤の構築 作者: 綿引琢磨,須江信洋,林政利,今井勝信出版社/メーカー: 翔泳社発売日: 2014/11/05メディア: 大型本この商品を含むブログ (6件) を見る
GradleによるJVMアプリケーションのパッケージングと配布 #gadvent - GeekFactory
G*Advent Calendar(Groovy,Grails,Gradle,Spock...) Advent Calendar 2014 - Qiitaの10日目です。 アプリケーションを公開する際、ユーザが使いやすい形でアプリケーションを配布することで、より多くのユーザに使ってもらえることが期待できます。また、アプリケーションをサービスとして公開する際にも、インフラにデプロイしやすい形でアプリケーションをリリースすることで、より早くユーザに提供することができます。どんなに優れたアプリケーションであっても、インストールや実行に面倒な手間がかかる場合は魅力が半減してしまいます。 JVMベースのアプリケーションを配布する際の課題 JVMベース（Java、Groovy、Scalaなど）のアプリケーションをユーザに配布するには以下の課題が考えられます。 まず、アプリケーションの実行に必要な ja
DockerでLinuxデスクトップを使ってみる - GeekFactory
Linuxをサーバ用途に使う場合、クリーンな環境を保つため、XやGNOMEなどをインストールしないことが多いと思います。とはいえ、ちょっとした調査などでデスクトップ環境があれば作業効率が上がるケースもあります。そこで、Dockerを使って、独立した環境でLinuxデスクトップを使えないか調べてみました。 結論としては、XfceやLXDEなら動作しました。GNOMEやUnityは動作しませんでした。日本語入力は要調査です。 とりあえず、DockerでUbuntu Desktopを使うための手順を残しておきます。参考まで。 暫定手順 新しいコンテナを実行します。 docker run -p 5901:5901 -it ubuntu:latest /bin/bash コンテナ内で以下を実行します。 apt-get update apt-get install xfce4 tightvncserv
docker run dockerfile/java:oracle-java7 - GeekFactory
JDK 7u65/8u11以降でバイトコード検証の不具合があったためこれまでDockerfileを自作していましたが、JDK 7u72/8u25で不具合が修正されたのでDocker Hubで公開されているイメージに乗り換えました。Docker HubではいくつかのJavaイメージが公開されていますが、javaとdockerfile/javaが主要のようです。前者は8u40があるのに7u72がなかったりするので、後者を使っています。 11/16時点で、dockerfile/javaのバージョンは以下の通りです。 % docker run --rm dockerfile/java:oracle-java7 java -version java version "1.7.0_72" Java(TM) SE Runtime Environment (build 1.7.0_72-b14) Java
JDK 7u65/8u11以降に存在するバイトコード検証の不具合 - GeekFactory
JDK 7u65/8u11以降にはバイトコード検証の不具合 JDK-8051012 があります。Groovyでは、 GROOVY-6951 で報告されているように、コンストラクタ内でsuper()やthis()を使うと実行時エラーが発生します。 Gradle SSH Pluginでもコンストラクタ内でsuper()を実行するコードがあり、JDK 7u65/8u11以降で正常に動作しない問題があります。最近のJDKで不具合が修正されているか確認してみたのですが、やはり動作しませんでした。結果は以下の通りです。 成功 7u60-b19 失敗 7u65-b17 失敗 7u67-b01 成功 8u5-b13 失敗 8u11-b12 失敗 8u20-b26 残念ながら、GROOVY-6951 のスレッドによると8u40まで待つしかないようです。 なお、Travis CIでは当該の不具合に対する暫定対
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
