App Engine Standard Go 1.11へのマイグレーションの方針が大幅に変更されたので追従した #101
Conversation
Go 1.11はベータ登場当初は2nd genとして、appengine apiを廃止する方向で動いていたが、方針転換によりGo Runtime最後の1st genとなることになったので、マイグレーションの方法が大幅に変わっている。 Go 1.11の方針転換の内容は https://qiita.com/apstndb/items/314e461aed518a4ad26f が詳しい
|
https://speakerdeck.com/emahiro/go-conference-2019-spring-go1-dot-9-to-go1-dot-11 5月のGo Conference 2019 Spring でGo1.9->Go1.11移行についての上記の発表したので、よろしければリンクしていただけるとmm |
|
@emahiro 色んな人の移行してみた記事へのLinkをこいつに入れるかは悩ましいところですねー ちなみに19ページ目の やらないと決めたことの以下の2つが疑問なのですが、なぜなのでしょう？ urlfetchの廃止Quota制限も存在するurlfetchを使い続けることにした理由はなんだろう？ cloud.google.com/loggingを移行先として検討した
|
x-appengine-inbound-appid を使ってマイクロサービス間の内部通信判定をしており、変更した場合の影響範囲が大きいためにスライドを作成する少し前の移行検討〜開始時期ではurlfetchの継続使用を選択しました。
構造化ログが欲しい！という一点で調査してました。ログについては一旦移行はpendしてます。 |
|
@emahiro なるほど。urlfetchを使って、別のApp Engine Serviceにリクエストを送ってる人は少数派なんじゃないかなーという気持ちがあるので、そこの部分のユースケースががっつり書いてあると嬉しいですね！ |
|
#102 が爆誕しました |
|
#102 に上記のスライドのリンクは貼らせていただきますね！ありがとうございます！ |
|
|
||
| Google App Engine Standard 2nd Generationがどういうものなのかは以下を確認するとよいです。 | ||
| gVisorがどういったものなのかは以下を確認するとよいです。 |
There was a problem hiding this comment.
我々は知っていることを書きたくなりがちですが、 gVisor の話は脇道なのであまり書かなくても良いのでは。
「Go 1.11 以降は従来のサンドボックスから gVisor ベースのサンドボックスになることでいくつかの制限がなくなった。」として、その後は「Go 1.11 になって緩和されこと」として言及するくらいで良いかと。
嬉しいことについても、嬉しいことがあるから移行するんじゃなくて迫られているから移行するのであって今回は必ずしも必要ないですしね。
There was a problem hiding this comment.
元々書いてあったから、とりあえず残したけど、ごっそり消しますかねー
|
そのドキュメントの目的から逸れる話は削るという思想が我々にも Google にも足りないことが多いので、何らかのトピックがあれば分割してリンクすることを検討してもよさそう。
|
| ものすごく致命的というわけではないですが、一部のライブラリが使えなかったりするので、多少不便でした。 | ||
|
|
||
| 外と通信するにもApp Engine SDKの機能を利用する必要がありました。 | ||
| httpを行いたければ、App Engine URLFetch APIを利用する。 | ||
| Socket通信を行いたければ、App Engine Socket APIを利用する必要がありました。 | ||
| 2nd Generationでは、http clientなどがそのまま使えるようになっています。 | ||
| gVisor版では、http clientなどがそのまま使えるようになっています。 |
There was a problem hiding this comment.
Socket API なしで net.Dial や gRPC 接続する GCP クライアントライブラリが使えるようになったことで Cloud Spanner 以外も使えるようになったので、一般的にここに含めても良さそうな。
は僕もすべてのパターンを知ってるわけではないから、よく分からんな・・・って気持ちですねぇ |
| @@ -177,25 +84,18 @@ Go 1.9までは `app.yaml` の位置がWorking Dirでしたが、Go 1.11の場 | |||
| [サンプル](https://github.com/sinmetal/codelab/commit/f3eb2cacb0af05bcd733742e225fe68544fda2b3) のようにトップをmain packageにしてしまえば、OKです。 | |||
| 2つ目はシンボリックリンクなどを利用して、両方のPathでアクセスできるようにしてしまう方法です。 | |||
There was a problem hiding this comment.
app.yaml で main を指定できる機能は移行用にできたものだと思うので、これを使うことで解決できるのでは。
https://cloud.google.com/appengine/docs/standard/go111/config/appref?hl=en#main
There was a problem hiding this comment.
| * [SAKURA Internet Image Flux](https://www.sakura.ad.jp/services/imageflux/) | ||
|
|
||
| ## 2nd Generationへのマイグレーション | ||
| ## Go1.11へのマイグレーション | ||
|
|
||
| 基本的には [公式ドキュメント通り](https://cloud.google.com/appengine/docs/standard/go111/go-differences#migrating-appengine-sdk) に行えばよい。 |
There was a problem hiding this comment.
公式ドキュメントでは optional だが strongly recommended として App Engine API からの移行について言及しているが期限が迫る Go 1.9 から Go 1.11 への移行に必須ではないため、このドキュメントでは扱わないというコンテキストを書いておいた方が、公式ドキュメントを読んで混乱する人が減りそうですね。
Go 1.11はベータ登場当初は2nd genとして、appengine apiを廃止する方向で動いていたが、方針転換によりGo Runtime最後の1st genとなることになったので、マイグレーションの方法が大幅に変わっている。
Go 1.11の方針転換の内容は https://qiita.com/apstndb/items/314e461aed518a4ad26f が詳しい
refs #100