こんにちは、Wantedly Visitのサーバーサイドエンジニアの一條（Github: @rerost Twitter: @hazumirr）です。

みなさん、The Go Playgroundを使ってますか？

僕は元々Railsエンジニアだったのですが、ここ最近ずっとGoを書いています。元々Goを書いていていたわけではないので、Goの動作の確認などのために、Playgroundをよく使っています。

これは非常に良くて、Railsではrails cでコードを試していたように、PlaygroundでGoのコードを試すことができます。

ただ、Playgroundでは外部パッケージが使えず、ちょっとした動作確認などができませんでした。他のGolangエンジニアにざっくり解決策を聞いてみたところ

1. 試すためのレポジトリを作ってしまう
2. そのパッケージ用のテストを書く（書いたテストはすぐ捨てられるように別ファイルにしておく）

などがありました。どちらも解決はするのですが、僕はシュッと試してサッと捨てられるものが欲しかったです。

そのために、Playgroundレポジトリをforkしその機能を入れたのでその解説をしたいと思います。

基本的に10/20にGo(Un)Conference で話した内容と同じです。

改造したPlaygroundのデモ: https://play-dot-k8s-test-219404.appspot.com

レポジトリ

発表資料

どうやって実現したか

元々のPlaygroundでは、go buildは単にexec.Commandから実行しており、そのバイナリの実行時のみSandbox環境が実現されています。なので、その前に外部パッケージをインストールすることは可能です。また、単にgo get .と実行することでそのフォルダ内で使われている外部パッケージの依存を解決できるので、実行前に簡単に依存パッケージをインストールすることができます。

ちなみに、Sandbox環境にはNaCl(Google Native Cloud)というもので実現していて、GOOS=naclと指定し、コンパイルし、sel_ldr_x86_64 を使い実行しています。

GCPへの依存をなくした

外部パッケージが動くようになったので、社内のインフラであったり、自分のローカルなどで常に動かす、といったこと行いたくなります。しかし、コードを共有するためにリンクを生成する機能（例: https://play-dot-k8s-test-219404.appspot.com/p/siiOpj5sHpi ）のために、Google Cloud Datastore が使われていました。これを変えて全てRedisベースで動かせると、ローカルでコードを保存できます。

また、Wantedly社内では基本的にAWSが使われるので社内のインフラに乗せることを考えるとあまりGCPに依存はしたくありません。

なので今は環境変数に REDIS_URL が入っていると自動でそれが使われるようにしています。Datastoreのアクセスには元々`interface`を使って実装されていたので単にそれを使うようにしてRedisにも保存できるようにしました。

これからどうしていきたいか

GCP依存がなくなったので社内インフラなどに移植できるようになりました。これから個人的にやりたいこととしては、以下の2つです。

1. 社内のプライベートパッケージを使えるようにする
2. NaCl上で動かさないオプションを作りたい

「1」がなぜやりたいかというと、現在Wantedly内にはいくつか社内用のパッケージがあり、これができると、楽にサービス開発ができるようになります。

また、「2」は外部と通信するパッケージなどのチェックに使いたいと思っています。これは若干「1」に関連していて、社内のパッケージは結構通信周りが多いのでそういったものを試す際に使えたらなと思います。ただし、これを導入すると悪用や社内の他のシステムに影響を及ぼす可能性があるので慎重にやっていきたいです。

最後に

https://play-dot-k8s-test-219404.appspot.com は僕の個人的なGCPのアカウントで動いています。なのであまり負荷をかけてしまうと僕の財布が死にます。あくまで"試す"程度に使っていただけると嬉しいです。

また、脆弱性やセキュリティの問題を見つけた際には @hazumirr まで連絡いただけると幸いです。