「Go」カテゴリーアーカイブ

SwaggerEditorで生成したGo API Serverの処理を実装する

  • はじめに
  • APIの全体像
  • MongoDBの作成
    • Dockerfileの作成
    • Dockerビルド
  • Go-Serverの作成
    • APIの実装
      • CreateUserメソッドの実装
      • GetUserByNameメソッドの実装
      • go/api_user.goの全体
    • Dockerfileの作成
    • Dockerビルド
  • APIの確認
    • docker-compose.yamlの作成
    • コンテナの起動
    • curlによるAPIの確認

はじめに


SwaggerEditorはOpenAPI specを様々な言語に変換することができます。以下の記事では、SwaggerEditorを使って簡単なOpenAPI specを作成し、Go-Serverに変換するところまで紹介しました。

MacにSwaggerEditorをインストールしてOpenAPI specを実装する

しかし、あくまでもAPIの雛形であって、中身の処理が実装されているわけではありません。本記事では、上記の記事で作成したGo-Serverに処理を実装します。

APIの全体像


本記事で作成するAPIの全体像について紹介します。

APIの仕様は以下の通りです。DBにはMongoDBを利用し、apiとdbはそれぞれコンテナで起動します。

  • POST /v2/user/create・・・Context-TypeでJson形式のユーザー情報を受け付け、DBに保管します。
  • GET /v2/user/{username}・・・URLに指定したusernameとマッチするレコードをDBから取得し、表示します。

MongoDBの作成


Dockerfileの作成


MongoDBのDockerfileを作成します。

ディレクトリ構造は以下の通りです。

$ tree mongo/
mongo/
├── Dockerfile
├── init.sh
└── users.json

今回は揮発性のDBコンテナにします。コンテナ起動時に初期データ(users.json)を流し込むinit.shも併せて作成します。

1. 初期データの作成


コンテナ起動時に流し込む初期データをjson形式で作成します。

[
  { "username":	"koratta", "email": "koratta@example.com" },
  { "username":	"koratta2", "email": "koratta2@example.com" }
]

2. 初期実行ファイルの作成


1で作成したJsonファイルをMongoDBに保管するためのスクリプトinit.shを作成します。

mongoimport --authenticationDatabase admin --username root --password password --db api --collection users --drop --file /docker-entrypoint-initdb.d/users.json --jsonArray

3. Dockerfileの作成


init.shをコンテナ起動時に実行するmongoベースのDockerfileを作成します。コンテナ起動時に実行するため、/docker-entrypoint-initdb.dにコピーします。

FROM mongo:latest
COPY users.json /docker-entrypoint-initdb.d/
COPY init.sh /docker-entrypoint-initdb.d/

Dockerビルド


上記で作成したDockerfileをビルドし、コンテナイメージを作成します。

$ docker build -t api-mongo-db:latest mongo/

Go-Serverの作成


APIの実装


APIリクエストのルーティング情報は、go/routers.goに記述されています。

~~go/router.goより抜粋~~
var routes = Routes{ Route{ "Index", "GET", "/v2/", Index, }, Route{ "CreateUser", strings.ToUpper("Post"), "/v2/user/create", CreateUser, }, Route{ "GetUserByName", strings.ToUpper("Get"), "/v2/user/{username}", GetUserByName, }, }

/v2/user/createに対してPOSTされたらCreateUserメソッドを、/v2/user/{username}に対してGETされたらGetUserBynameメソッドを呼び出すようになっています。それぞれのメソッドはgo/api_user.goで定義されているので、それぞれを実装します。

CreateUserメソッドの実装


CreateUserメソッドを以下に示します。

func CreateUser(w http.ResponseWriter, r *http.Request) {
	w.Header().Set("Content-Type", "application/json; charset=UTF-8")

	//ヘッダー情報の取得
	if r.Header.Get("Content-Type") != "application/json" {
		w.WriteHeader(http.StatusBadRequest)
		return
	}
	length, err := strconv.Atoi(r.Header.Get("Content-Length"))
	body := make([]byte, length)
	length, err = r.Body.Read(body)
	var insert_record User
	err = json.Unmarshal(body[:length], &insert_record)

	//DBへのInsert
	connect := getConnect()
	_, err = connect.Database("api").Collection("users").InsertOne(context.Background(), insert_record)
	if err != nil {
		w.WriteHeader(http.StatusBadRequest)
		return
	}

	w.WriteHeader(http.StatusOK)
}

9~11行目でPOSTされたJson形式のユーザー情報を取得しています。

	length, err := strconv.Atoi(r.Header.Get("Content-Length"))
	body := make([]byte, length)
	length, err = r.Body.Read(body)

12~13行目でUser構造体のinsert_recordに変換しています。

	var insert_record User
	err = json.Unmarshal(body[:length], &insert_record)

このUser構造体は、OpenAPI specから生成されていて、go/model_user.goに記述されています。

package swagger

type User struct {

	Username string `json:"username,omitempty"`

	Email string `json:"email,omitempty"`
}

16~17行目でMongoDBに保管しています。getConnectメソッドはMongoDBとの接続を確立するメソッドで、go/api_user.goの全体に載せています。

	connect := getConnect()
	_, err = connect.Database("api").Collection("users").InsertOne(context.Background(), insert_record)

GetUserByNameメソッドの実装


GetUserByNameメソッドを以下に示します。

func GetUserByName(w http.ResponseWriter, r *http.Request) {
	w.Header().Set("Content-Type", "application/json; charset=UTF-8")

	//検索ユーザー情報の取得
	user := strings.Replace(r.URL.Path, "/v2/user/", "", 1)

	//user情報の取得
	var output User
	connect := getConnect()
	filter := bson.D{{"username", user }}
	err := connect.Database("api").Collection("users").FindOne(context.Background(), filter).Decode(&output)
	if err != nil {
		w.WriteHeader(http.StatusBadRequest)
		return
	}

	//Jsonの出力
	json.NewEncoder(w).Encode(output)

	w.WriteHeader(http.StatusOK)
}

5行目で検索条件となるユーザー名を取得しています。今回のAPIの仕様は、URLのパスに指定されたユーザー名の情報を表示するので、URLパスからユーザー名を取得しています。

user := strings.Replace(r.URL.Path, "/v2/user/", "", 1)

9~11行目で、URLに指定されたユーザー名を基にMongoDBから情報を取得しています。

	connect := getConnect()
	filter := bson.D{{"username", user }}
	err := connect.Database("api").Collection("users").FindOne(context.Background(), filter).Decode(&output)

go/user_api.goの全体


user_api.goの全体は以下の通りです。

/*
 * Koratta Test API
 *
 * This is sample api
 *
 * API version: 1.0.0
 * Contact: koratta@example.com
 * Generated by: Swagger Codegen (https://github.com/swagger-api/swagger-codegen.git)
 */

package swagger

import (
	"net/http"
	"log"
	"time"
	"encoding/json"
	"context"
	"strconv"
	"strings"
	"go.mongodb.org/mongo-driver/mongo"
	"go.mongodb.org/mongo-driver/mongo/options"
	"go.mongodb.org/mongo-driver/bson"
)

func CreateUser(w http.ResponseWriter, r *http.Request) {
	w.Header().Set("Content-Type", "application/json; charset=UTF-8")

	//ヘッダー情報の取得
	if r.Header.Get("Content-Type") != "application/json" {
		w.WriteHeader(http.StatusBadRequest)
		return
	}
	length, err := strconv.Atoi(r.Header.Get("Content-Length"))
	body := make([]byte, length)
	length, err = r.Body.Read(body)
	var insert_record User
	err = json.Unmarshal(body[:length], &insert_record)

	//DBへのInsert
	connect := getConnect()
	_, err = connect.Database("api").Collection("users").InsertOne(context.Background(), insert_record)
	if err != nil {
		w.WriteHeader(http.StatusBadRequest)
		return
	}

	w.WriteHeader(http.StatusOK)
}

func GetUserByName(w http.ResponseWriter, r *http.Request) {
	w.Header().Set("Content-Type", "application/json; charset=UTF-8")

	//検索ユーザー情報の取得
	user := strings.Replace(r.URL.Path, "/v2/user/", "", 1)

	//user情報の取得
	var output User
	connect := getConnect()
	filter := bson.D{{"username", user }}
	err := connect.Database("api").Collection("users").FindOne(context.Background(), filter).Decode(&output)
	if err != nil {
		w.WriteHeader(http.StatusBadRequest)
		return
	}

	//Jsonの出力
	json.NewEncoder(w).Encode(output)

	w.WriteHeader(http.StatusOK)
}

func getConnect() *mongo.Client{
	//MongoDBの認証情報
	credential := options.Credential{
		Username: "root",
		Password: "password",
	}
	//MongoDBへの接続
	ctx, cancel := context.WithTimeout(context.Background(), 10*time.Second)
	defer cancel()
	connect, err := mongo.Connect(ctx, options.Client().ApplyURI("mongodb://db:27017").SetAuth(credential))
	if err != nil { log.Fatal(err) }

	return connect
}

Dockerfileの作成


Dockerfileを作成します。

ディレクトリ構造は以下の通りです。

$ tree api
api
├── Dockerfile
└── src
    ├── api
    │   └── swagger.yaml
    ├── go
    │   ├── README.md
    │   ├── api_user.go
    │   ├── logger.go
    │   ├── model_user.go
    │   └── routers.go
    └── main.go

src配下のファイルは、MacにSwaggerEditorをインストールしてOpenAPI specを実装するで作成したソースコードです。

Dockerfileは以下の通りです。

FROM golang:latest
# gouserの作成
RUN useradd -m -s /bin/bash gouser
# コンテナ作業ディレクトリの変更
WORKDIR /go/src/api
RUN chown gouser:gouser /go/src/api
# モジュールのダウンロード
RUN go get -u github.com/gorilla/mux &&\
    go get -u "go.mongodb.org/mongo-driver/mongo"
# ホストOSの ./src の中身を作業ディレクトリにコピー
COPY --chown=gouser:gouser ./src .
# go build
RUN go build -o koratta-api &&\
    chown gouser:gouser api
# gouserに変更
USER gouser
# API実行コマンドの実行
CMD ["/go/src/api/koratta-api"]

必要なモジュールのgorilla/muxとmongo-driver/mongoをインストールし、gouserに実行権限を与えてgouserで実行するようにしています。root権限でも当然実行できます。

注意点は、main.goのimportパッケージのsw "go"部分です。コンテナの場合デフォルトで$GOPATH=/go/srcなので、上記のDockerfileの場合sw "api/go"になります。

APIの確認


docker-compose.yamlの作成


MongoDBとAPIのコンテナを起動するためのdocker-compose.yamlを作成します。

version: '3'
services:
  db:
    container_name: db
    image: api-mongo-db:latest
    environment:
      MONGO_INITDB_ROOT_USERNAME: root
      MONGO_INITDB_ROOT_PASSWORD: password
    ports:
      - "27017:27017"
  api:
    container_name: api
    image: api:latest
    depends_on:
      - db
    links:
      - db
    ports:
      - "8080:8080"

コンテナの起動


docker-composeを使ってコンテナを起動します。

$ docker-compose up -d

curlによるAPIの確認


作成したAPIの挙動を確認します。

初期データとして保管されているレコードをAPI経由で確認すると、以下の通り、指定したユーザー名に該当する情報を取得できます。

$ curl -X GET "http://localhost:8080/v2/user/koratta"
{"username":"koratta","email":"koratta@example.com"}

保管されていないユーザーは、当然取得できません。

$ curl -X GET "http://localhost:8080/v2/user/koratta5
$

従って、APIを使ってユーザー情報を保管します。

$ curl -X POST "http://localhost:8080/v2/user/create" -H "accept: application/xml" -H "Content-Type: application/json" -d "{ \"username\": \"koratta5\", \"email\": \"koratta5@example.com\"}"

再度確認すると、ユーザー情報を確認することができます。/v2/user/createのAPI経由でDBに保管できていることが確認できました。

$ curl -X GET "http://localhost:8080/v2/user/koratta5"
{"username":"koratta5","email":"koratta5@example.com"}

以上です。

Ginを使ったGo API開発の初歩(cookie編)

以下の記事でGinをインストールしてGo APIの実装を始めました。今日はcookieを実装します。

Ginを使ったGo API開発の初歩

  • cookieとは
  • cookieの実装
  • APIの確認

cookieとは


cookieとは、ウェブブラウザに保存される情報のことを指します。

サイトにログイン後、再度同じサイトにアクセスするとログインした状態になっていることがあります。これはcookieとしてユーザー情報が保存されているからです。他にも閲覧したページに関連する広告を出したりと、様々な場面で利用されています。

本記事では、Ginによるcookie操作を確認します。

cookieの実装


Ginによるcookieの設定と取得には以下のメソッドを利用します。それぞれのメソッドの引数・戻り値の型については、gin-GoDocに記載されています。

  • cookieの設定・・・gin.Context.Cookie
  • cookieの取得・・・gin.Context.SetCookie

上記のメソッドを使ったcookie.goを以下に示します。

package main

import "github.com/gin-gonic/gin"

func main() {

    router := gin.Default()

		authorized := router.Group("/admin", gin.BasicAuth(gin.Accounts{
			"koratta":    "koratta",
			"koratta2":   "koratta2",
		}))

		authorized.GET("/login", func(c *gin.Context) {
			user := c.MustGet(gin.AuthUserKey).(string)
			c.SetCookie("user", user, 3600, "/", "localhost", false, true)
		})

		authorized.GET("/hello-cookie", func(c *gin.Context) {
			user, user_cookie_err := c.Cookie("user")
			if user_cookie_err != nil {
				user = "Guest"
			}
			c.JSON(200, gin.H{ "message": "Hello " + user })
		})

    router.Run()
}

/loginにログインしたユーザー情報をcookieに保存し、/hello-cookieにアクセスすると”user”cookieの値を表示します。違いがわかるように、直接/hello-cookieにアクセスした場合は”Guest”が表示されるようにしています。

16行目c.SetCookie("user", user, 3600, "/", "localhost", false, true)の引数について解説します。

  • 第一引数・・・cookieのKeyを指定します。ここでは”user”を指定しています。
  • 第二引数・・・第一引数のKeyに対応するValueを設定します。ここでは、string型変数userを設定しています。userは、15行目のc.MustGet(gin.AuthUserKey).(string)で、ログインしたユーザー名を代入しています。
  • 第三引数・・・cookie情報を保存する時間を指定します。ここでは1時間で設定しています。
  • 第四引数・・・cookie情報が扱える範囲のパスを指定します。ここではルートパスを指定しています。
  • 第五引数・・・cookie情報が扱えるドメインを指定します。ここではlocalhostで指定しています。
  • 第六引数・・・httpsでもcookieを利用するか指定します。trueの場合はhttpsでも利用できます。
  • 第七引数・・・httpリクエストのみcookieを利用できるようにするか指定します。trueの場合JavaScriptからcookieを利用することができません。trueにすることで、クロスサイトスクリプティング(XSS)攻撃を緩和することができます。

20行目のuser, user_cookie_err := c.Cookie("user")は、”user” KeyのValue値を取得しています。Cookieメソッドの戻り値はstring, errorと二つあります。

APIの確認


実際にAPIの挙動を確認してみます。

まずはlocalhost:8080/hello-cookieに直接アクセスします。以下の通り、cookieに保存していないので”Hello Guest”が返ってきます。

$ curl -u koratta:koratta localhost:8080/admin/hello-cookie
{"message":"Hello Guest"}

次に、localhost:8080/loginに一度アクセスしてから、localhost:8080/hello-cookieにアクセスします。/loginでユーザー情報をcookieに設定しているので、以下の通り”Hello koratta”が表示されます。

以上です。

Ginを使ったGo API開発の初歩(ルーターグループ化編)

以下の記事でGinをインストールしてGo APIの実装を始めました。ルーティングをグループ化することができるので、今日はその機能を実装してみたいと思います。

Ginを使ったGo API開発の初歩

  • ルーターグループ化とは
  • ルーターグループ化機能の実装
  • APIの確認

ルーターグループ化とは


Ginにはルーティングをグループ化する機能があります。

この機能によって、同じAPIでもルーティング毎に仕様を変更することができます。よく見かけるのは、API毎にバージョンを分ける使い方です。APIの仕様を突然変更すると、そのAPIを使って自動化しているシステムは影響を受けてしまいます。ユーザーが任意のタイミングで切り替えられるように、バージョン毎に提供することがよくあります。

ルーターグループ化機能の実装


サンプルコードを参考に、ルーターグループ化機能を実装します。

Groupメソッドを使用してv1, v2のルーテンググループを作成し、それぞれが返すmessageの値を変更します。クライアントは、Groupに指定されたURL(以下の場合は/v1,/v2)でルーティングを使い分けます。

package main

import "github.com/gin-gonic/gin"

func helloV1() gin.HandlerFunc {
	return func(c *gin.Context) {
		c.JSON( 200, gin.H{ "message": "hello v1", } )
	}
}

func helloV2() gin.HandlerFunc {
	return func(c *gin.Context) {
		c.JSON( 200, gin.H{ "message": "hello v2", } )
	}
}

func main() {
	r := gin.Default()
	v1 := r.Group("/v1")
	{
		v1.POST("/hello", helloV1() )
	}

	v2 := r.Group("/v2")
	{
		v2.POST("/hello", helloV2() )
	}
	r.Run()
}

APIの確認


ルーティング毎にAPIの出力が変わることを確認します。

$ go run router_group.go

別ターミナルで確認すると、以下の通り/v1/helloと/v2/helloでmessageの値が変わっていることがわかります。

$ curl --request POST localhost:8080/v1/hello
{"message":"hello v1"}
$ curl --request POST localhost:8080/v2/hello
{"message":"hello v2"}

ちなみに、GETリクエストは定義していないのでNotFoundが返ってきます。

$ curl --request GET localhost:8080/v2/hello
404 page not found

以上です。

Ginを使ったGo API開発の初歩(BindQuery編)

以下の記事でGinをインストールしてGo APIの実装を始めました。今日はBindQueryを導入し、フォームに応じて出力を変更するAPIを実装します。

Ginを使ったGo API開発の初歩

  • BindQueryとは
  • BindQueryの実装
  • APIの確認

BindQueryとは


BindQueryとは、golangにおいてクエリパラメータをバインドする機能です。

この機能によってフォームに応じた返答を行うことができます。例えば、日付をフォームに入力したら、その日付のデータのみ返すことができます。このようにBindQueryを使うことで、より使い勝手のいいAPIを作成できるようになります。

BindQueryの実装


BindQueryを実装します。

グループに所属するメンバーを表示するbind_query.goを作成します。存在するグループはgroup1とgroup2を用意し、クライアントはnameフォームの値にグループ名を入力することで表示するグループを切り替えます。指定したグループ名が存在しない場合は、httpリクエストステータスを400にして「There are no groups」を返します。

package main

import "github.com/gin-gonic/gin"

type Group struct {
	Name    string `form:"name"`
}

var GROUP1_MEMBER_LIST = [...] gin.H{ gin.H{"name": "koratta01"}, gin.H{"name": "koratta02"} }
var GROUP2_MEMBER_LIST = [...] gin.H{ gin.H{"name": "ratta01"}, gin.H{"name": "ratta02"} }

var GROUP_MEMBER_LIST = gin.H{
	"group1":  gin.H{ "member": GROUP1_MEMBER_LIST },
	"group2":  gin.H{ "member": GROUP2_MEMBER_LIST },
}

func main() {
	route := gin.Default()
	route.Any("/member", getGroupMember)
	route.Run(":8080")
}

func getGroupMember(c *gin.Context) {
	var group Group
	if c.BindQuery(&group) == nil {
		if member_list, exists := GROUP_MEMBER_LIST[group.Name]; exists {
			c.JSON(200, member_list)
		} else {
			c.String(400, "There are no groups")
		}
	}
}

APIの確認


作成したbind_query.goを実行してAPIを確認します。

$ go run bind_query.go

別ターミナルで以下のコマンドを実行すると、グループ名に所属するメンバーリストが取得できることを確認できます。

$ curl --request GET 'http://localhost:8080/member?name=group1'
{"member":[{"name":"koratta01"},{"name":"koratta02"}]}
$ curl --request GET 'http://localhost:8080/member?name=group2'
{"member":[{"name":"ratta01"},{"name":"ratta02"}]}
$ curl --request GET 'http://localhost:8080/member?name=group3'
There are no groups

bind_query.goのログを確認すると以下の通り、所属するグループだけステータスが200となっています。

[GIN] 2020/07/14 - 22:38:15 | 200 |     199.543µs |             ::1 | GET      "/member?name=group1"
[GIN] 2020/07/14 - 22:38:21 | 200 |      51.177µs |             ::1 | GET      "/member?name=group2"
[GIN] 2020/07/14 - 22:38:26 | 400 |      57.617µs |             ::1 | GET      "/member?name=group3"

Postで送信したときの挙動も確認すると、Getではメンバーリストが返ってきたグループ名でも「There are no groups」が返ってきています。これはBindQueryがPostデータをバインドしないからです。

$ curl --request POST 'http://localhost:8080/member?name=group3'
There are no groups
[GIN] 2020/07/14 - 22:45:10 | 400 |      56.774µs |             ::1 | POST     "/member?name=group3"

以上です。

Ginを使ったGo API開発の初歩(Basic認証編)

以下の記事でGinをインストールしてGo APIの実装を始めました。今日はBasic認証を導入し、ユーザーIDとパスワードが必要なAPIを実装します。

Ginを使ったGo API開発の初歩

  • Basic認証とは
  • Basic認証の実装
  • APIの確認

Basic認証とは


Basic認証とは、httpリクエストにおける認証システムです。以下の画面のようにユーザーIDとパスワードを求められたことがあると思います。あらかじめ登録されたユーザーIDとパスワードを入力するとアクセスできる仕組みです。

Basic認証の実装


実装サンプルを参考に、Basic認証を実装します。

リンク先のサンプルコードでは、認証されたユーザーの秘匿情報を返すように実装されていますが、今回はわかりやすく認証されたら適当な値を返すだけのbasic_auth.goを作成します。

package main

import "github.com/gin-gonic/gin"

func main() {
  r := gin.Default()

  authorized := r.Group("/admin", gin.BasicAuth(gin.Accounts{
    "koratta":    "koratta",
    "koratta2":   "koratta2",
  }))

  authorized.GET("/hello", func(c *gin.Context) {
    user := c.MustGet(gin.AuthUserKey).(string)
    c.JSON(200, gin.H{ "message": "Hello " + user })
  })

  r.Run(":8080")
}

gin.Accountsでは、[ユーザー名]:[パスワード]のJson形式で認証情報を定義しています。その認証情報と/adminプレフィックスによってauthorizedグループを作成します。このGroupからauthorized.Getで作成されたエンドポイントは、定義された認証情報を持つユーザーのみがアクセスできます。admin/helloエンドポイントは、ユーザー名をメッセージに追加してJsonフォーマットで表示します。

APIの確認


basic_auth.goを実行して、APIを確認します。

$ go run basic_auth.go 
[GIN-debug] [WARNING] Creating an Engine instance with the Logger and Recovery middleware already attached.

[GIN-debug] [WARNING] Running in "debug" mode. Switch to "release" mode in production.
 - using env:	export GIN_MODE=release
 - using code:	gin.SetMode(gin.ReleaseMode)

[GIN-debug] GET    /admin/hello              --> main.main.func1 (4 handlers)
[GIN-debug] Listening and serving HTTP on :8080

curlコマンドを使ってAPIにリクエストを行います。-uオプションを使うことでユーザー名とパスワードを入力することができます。以下のように、basic_auth.goに登録されているkoratta, koratta2のみリクエストが返ってきてることがわかります。

$ curl -u koratta:koratta localhost:8080/admin/hello
{"message":"Hello koratta"}
$ curl -u koratta2:koratta2 localhost:8080/admin/hello
{"message":"Hello koratta2"}
$ curl -u koratta3:koratta3 localhost:8080/admin/hello
$ 

Ginのログを確認しても、3回目にリクエストを行ったkoratta3のみ、ステータスコード401を返していることがわかります。

[GIN] 2020/07/12 - 16:23:51 | 200 |     116.147µs |             ::1 | GET      "/admin/hello"
[GIN] 2020/07/12 - 16:24:19 | 200 |        67.2µs |             ::1 | GET      "/admin/hello"
[GIN] 2020/07/12 - 16:24:28 | 401 |      52.325µs |             ::1 | GET      "/admin/hello"

 

Ginを使ったGo API開発の初歩

今日はGinを使って、簡単なGo APIを動かすところまでやってみたいと思います。初歩ということで、まずはインストールとQuick Startを実施します。

  • Ginとは
  • Ginのインストール
  • Ginを動かす

Ginとは


Ginとは、Golangで開発されたWebフレームワークで、パフォーマンスに優れたAPI機能を提供します。(GinのGitHubから引用しています。)

Gin is a web framework written in Go (Golang). It features a martini-like API with performance that is up to 40 times faster thanks to httprouter. If you need performance and good productivity, you will love Gin.

引用元:https://github.com/gin-gonic/gin#contents

日本語訳されたドキュメントが以下リンク先に用意されています。非常にありがたいです。。。

https://gin-gonic.com/ja/docs/

Ginのインストール


以下のコマンドでGinの必要なパッケージをインストールします。インストール後、ソースコードにimport "github.com/gin-gonic/gin"を記述して使えるようになります。

$ go version
go version go1.14.3 darwin/amd64
$ go get -u github.com/gin-gonic/gin

Ginを動かす


GinのQuick Startを実施して、httpリクエストを受け付けるとJsonを返すAPIを作成します。

リンク先のソースコードをコピーして、getting_start.goを作成します。

package main

import "github.com/gin-gonic/gin"

func main() {
	r := gin.Default()
	r.GET("/ping", func(c *gin.Context) {
		c.JSON(200, gin.H{
			"message": "pong",
		})
	})
	r.Run() // listen and serve on 0.0.0.0:8080 (for windows "localhost:8080")
}

実行すると以下のエラーが発生しました。

$ go run getting_start.go 
getting_start.go:3:8: cannot find module providing package github.com/gin-gonic/gin: working directory is not part of a module

ワークディレクトリにmoduleがないというエラーなので、以下のコマンドでモジュールを作成します。

$ go mod init
go: creating new go.mod: module gin
$ ls
getting_start.go	go.mod

再度実行します。

$ go run getting_start.go 
go: finding module for package github.com/gin-gonic/gin
go: found github.com/gin-gonic/gin in github.com/gin-gonic/gin v1.6.3
[GIN-debug] [WARNING] Creating an Engine instance with the Logger and Recovery middleware already attached.

[GIN-debug] [WARNING] Running in "debug" mode. Switch to "release" mode in production.
 - using env:	export GIN_MODE=release
 - using code:	gin.SetMode(gin.ReleaseMode)

[GIN-debug] GET    /ping                     --> main.main.func1 (3 handlers)
[GIN-debug] Environment variable PORT is undefined. Using port :8080 by default
[GIN-debug] Listening and serving HTTP on :8080

localhost:8080/pingにhttpリクエストを送信すると、Jsonを返します。

$ curl localhost:8080/ping
{"message":"pong"}

getting_start.goの出力結果にレスポンスタイムとステータスが記録されていました。

[GIN] 2020/07/12 - 01:45:41 | 200 |      38.361µs |             ::1 | GET      "/ping"

以上です。まずは動かしてみたということで、これから色々触ってみたいと思います。

golangでhttpリクエストフォームの値を扱う

golangに慣れている人にとっては当たり前の処理ですが、一応メモとして書き留めておきたいと思います。

  • リクエストフォームの値を取得する
  • curlコマンドで確認する
    • URLにフォームを入力する
    • –formオプションを利用する

リクエストフォームの値を取得する


golangでformの値を取得するには、FormValueメソッドを利用します。具体的には、以下のように取得したいKeyの値を指定します。

http.Request.FormValue(Key)

テスト用ソースコードを作成してみました。以下のソースコード は、ポート番号8080でhttpリクエストを受け付け、Formに入力されたnameとcountryの値を表示します。

package main

import (
    "log"
    "net/http"
    "fmt"
)

func main() {
    //index関数をルートディレクトリに指定
    http.HandleFunc("/", index)
    //サーバー起動
    if err := http.ListenAndServe(":8080", nil); err != nil {
        log.Fatal("ListenAndServe:", nil)
    }
}

func index(writer http.ResponseWriter, r *http.Request) {
  fmt.Println( r.FormValue("name") )
  fmt.Println( r.FormValue("country") )
}

curlコマンドで確認する


curlコマンドで確認する場合は、URLに入力するか、–formオプションを利用します。

先に上記で作成したgoファイルを実行しておきます。

$ go run main.go

URLにフォームを入力する


URLにフォームを入力する場合は、?の後に記述します。複数入力する場合は&を利用します。

$ curl --request GET 'http://localhost:8080/?name=koratta&country=japan'

上記コマンドの出力結果は以下の通りです。

koratta
japan

–formオプションを利用する


–formオプションを利用する場合は、–formオプションの後ろにフォームを入力することで確認できます。

$ curl http://localhost:8080 --form "name=koratta" --form "country=korea"

上記コマンドの出力結果は以下の通りです。

koratta
korea

以上です。

NAMESPACEをプロビジョニングするOPERATORを作ってみる(ユーザー権限編)

NamespaceをプロビジョニングするOperatorがあったら、マルチテナントでクラスター運用するのが楽になるかなぁと思い、Operatorを作成しています。本日はNamespaceにおけるユーザーアクセス権限のプロビジョニング機能を作成します。

  • はじめに
  •  Operatorを作成する
    • CRDを作成する
    • Controllerを追加する
  • Operatorをビルドする
  • Operatorをデプロイする
  • Operatorを確認する
    • ユーザーを作成する
    • Contextを作成する
    • CRを作成する
    • 権限を確認する

はじめに


最近、NamespaceをプロビジョニングするOperatorを作成しています。以下の関連記事にあるように、これまでResourceQuotaやNetworkPolicyをプロビジョニングするOperatorを作成しました。

本記事では、このOperatorにアクセス権限をプロビジョニングする機能を追加します。具体的には、CR(Cutom Resouce)に指定されたGroupに所属するユーザーが、Namespaceにアクセスできるように設定します。システムやプロジェクト単位でNamespaceを分割する際、関係ないユーザーが勝手に操作することを防げるので、必ずと言っていいほどインフラチームが実施する設定です。

Operatorを作成する


CRDを作成する


CRで設定できる設定項目を定義します。今回は、pkg/apis/nspro/v1alpha1/nspro_types.goのNsproSpecにAllowedGroup []string `json:”allowedGroup”`を加えて、Namespaceにアクセス可能なグループを指定できるようにします。

Operator SDKのインストール方法は、Operator SDK をインストールしてOperatorを作成する(1/2)で紹介していますので、よろしければご参照ください。

type NsproSpec struct {
    // INSERT ADDITIONAL SPEC FIELDS - desired state of cluster
    // Important: Run "operator-sdk generate k8s" to regenerate code after modifying this file
    // Add custom validation using kubebuilder tags: https://book.kubebuilder.io/beyond_basics/generating_crd.html
    NsSize string `json:"nssize"`
    Managed bool `json:"managed"`
    AllowedGroup []string `json:"allowedGroup"`
}

変更を加えたら、以下のコマンドで必要なコードを再生成します。

$ operator-sdk generate k8s
INFO[0006] Running deepcopy code-generation for Custom Resource group versions: [nspro:[v1alpha1], ]
INFO[0011] Code-generation complete.

Controllerを追加する


ControllerのReconcile関数には、newRolePolicyForNSとnewRoleBindingForNSを呼び出してRole, RoleBindingリソースを作成する処理を記述します。

func (r *ReconcileNspro) Reconcile(request reconcile.Request) (reconcile.Result, error) {
    ~~省略~~
    role := r.newRoleForNS(instance)
    err = r.client.Create(context.TODO(), role)

    group_names := instance.Spec.AllowedGroup
    for i := range group_names {
      rb := r.newRoleBindingForNS(instance, group_names[i])
      err = r.client.Create(context.TODO(), rb)
    }
    ~~省略~~
}

newRoleforNSは以下の通りで、CRで作成するNamespaceの全権限(クラスター権限を除く)を付与します。作成方法は他のリソースと同じですが、RoleとRoleBindingの定義は、vender/k8s.io/api/rbac/v1/type.goに記述されています。

func (r *ReconcileNspro) newRoleForNS(cr *nsprov1alpha1.Nspro) *rbacv1.Role {
  nsname  := cr.Name
  role := &rbacv1.Role {
    ObjectMeta: metav1.ObjectMeta {
      Name:      nsname + "-role",
      Namespace: nsname,
    },
    Rules: []rbacv1.PolicyRule {
      {
        APIGroups: []string{ rbacv1.APIGroupAll },
        Resources: []string{ rbacv1.ResourceAll },
        Verbs: []string{ rbacv1.VerbAll },
      },
    },
  }
  controllerutil.SetControllerReference(cr, role, r.scheme)
  return role
}

newRoleBindingForNSは以下の通りで、newRoleforNSで作成したRoleをCRに指定されたGroupに付与します。

func (r *ReconcileNspro) newRoleBindingForNS(cr *nsprov1alpha1.Nspro, group_name string) *rbacv1.RoleBinding {
  nsname  := cr.Name
  rb := &rbacv1.RoleBinding {
    ObjectMeta: metav1.ObjectMeta {
      Name:      nsname + "-rb",
      Namespace: nsname,
    },
    Subjects: []rbacv1.Subject {
      {
        Kind: "Group",
        Name: group_name,
        APIGroup: "rbac.authorization.k8s.io",
      },
    },
    RoleRef: rbacv1.RoleRef {
      Name: nsname + "-role",
      Kind: "Role",
      APIGroup: "rbac.authorization.k8s.io",
    },
  }
  
  controllerutil.SetControllerReference(cr, rb, r.scheme)
  return rb
}

Operatorをビルドする


作成したOperatorのコンテナイメージをビルドします。

$ operator-sdk build 192.168.64.2:32000/nspro-operator:v1

以下のコマンドでレジストリに登録します。今回はMicroK8s上のコンテナレジストリ上に登録するので、[WorkerNodeのIPアドレス]:[NodePort]/[イメージ名]:[タグ名]のように登録しておきます。

$ docker push 192.168.64.2:32000/nspro-operator:v1

Operatorをデプロイする


Operatorをデプロイします。Operatorの前にCRDを作成しないとapiVersionが利用できないので、CRDから作成します。

$ kubectl create -f deploy/crds/nspro_v1alpha1_nspro_crd.yaml
customresourcedefinition.apiextensions.k8s.io/nspros.nspro.example.com created

続いてdeploy/配下にあるyamlを作成します。operator.yamlだけイメージ名を変更する必要があります。

$ kubectl delete -f deploy/operator.yaml 
deployment.apps "nspro-operator" deleted
$ kubectl create -f deploy/operator.yaml -n nspro-operator
deployment.apps/nspro-operator created
$ kubectl create -f deploy/service_account.yaml -n nspro-operator
serviceaccount/nspro-operator created
$ kubectl create -f deploy/role.yaml -n nspro-operator
role.rbac.authorization.k8s.io/nspro-operator created
$ kubectl create -f deploy/role_binding.yaml -n nspro-operator
rolebinding.rbac.authorization.k8s.io/nspro-operator created

デプロイすると以下のエラーが発生します。

E0701 15:06:25.610185 1 reflector.go:134] sigs.k8s.io/controller-runtime/pkg/cache/internal/informers_map.go:126: Failed to list *v1alpha1.Nspro: nspros.nspro.example.com is forbidden: User "system:serviceaccount:nspro-operator:nspro-operator" cannot list resource "nspros" in API group "nspro.example.com" in the namespace "nspro-operator"

アクセス権限を付与するために、以下の記事でRBAC機能を有効化したことによってOperatorに権限がなくなったことが原因です。

MicroK8sへのユーザー追加と権限付与でハマった話

従って、OperatorにCluster権限を与える必要があります。以下のyamlを使ってnspro-operator ServiceAccountにcluster-adminを付与します。

kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: admin-for-nspro-operator
subjects:
- kind: ServiceAccount
  name: nspro-operator
  namespace: nspro-operator
roleRef:
  kind: ClusterRole
  name: cluster-admin
  apiGroup: rbac.authorization.k8s.io

Operatorを確認する


CRを作成してOperatorの挙動を確認します。

ユーザーを作成する


Operator確認用に、dev1グループに所属するdev1-user01とdev2グループに所属するdev2-user01を作成します。

basic_auth.csv に以下の行を追加します。今回はMicroK8sを利用しているので/var/snap/microk8s/current/credentials/配下にあります。環境毎にパスが異なるので注意してください。

[dev1-user01のパスワード],dev1-user01,dev1-user01,"system:authenticated,developer,dev1"
[dev2-user01のパスワード],dev2-user01,dev2-user01,"system:authenticated,developer,dev2"

Contextを作成する


~/.kube/config を編集して、dev1-user01とdev2-user01で操作する用のContextを作成します。

apiVersion: v1
clusters:
- cluster:
    insecure-skip-tls-verify: true
    server: https://127.0.0.1:16443
  name: microk8s-cluster
contexts:
- context:
    cluster: microk8s-cluster
    user: admin
  name: microk8s
- context:
    cluster: microk8s-cluster
    user: dev1-user01
  name: microk8s-dev1
- context:
    cluster: microk8s-cluster
    user: dev2-user01
  name: microk8s-dev2
current-context: microk8s
kind: Config
preferences: {}
users:
- name: admin
  user:
    password: [adminのパスワード]
    username: admin
- name: dev1-user01
  user:
    password: [dev1-user01のパスワード]
    username: dev1-user01
- name: dev2-user01
  user:
    password: [dev2-user01のパスワード]
    username: dev2-user01

CRを作成する


CRを作成してNamespaceをプロビジョニングします。

dev1グループがアクセスできるdev1-nsとdev2グループがアクセスできるdev2-nsを以下のyamlを使って作成します。

apiVersion: nspro.example.com/v1alpha1
kind: Nspro
metadata:
  name: dev1-ns
spec:
  nssize: large
  managed: true
  allowedGroup: ["dev1"]
apiVersion: nspro.example.com/v1alpha1
kind: Nspro
metadata:
  name: dev2-ns
spec:
  nssize: large
  managed: true
  allowedGroup: ["dev2"]
$ kubectl create -f deploy/crds/dev1-ns.yaml -n nspro-operator
nspro.nspro.example.com/dev1-ns created
$ kubectl create -f deploy/crds/dev2-ns.yaml -n nspro-operator
nspro.nspro.example.com/dev2-ns created
$ kubectl get ns dev1-ns dev2-ns
NAME      STATUS   AGE
dev1-ns   Active   82s
dev2-ns   Active   74s

権限を確認する


dev1-user01とdev2-user01のコンテキストに切り替えて、それぞれの権限を確認すると、以下のようにCRのallowedGroupに指定されたNamespaceのみアクセスできることがわかります。

$ kubectl config use-context microk8s-dev1
Switched to context "microk8s-dev1".
$ kubectl auth can-i get pods -n dev1-ns
yes
$ kubectl auth can-i get pods -n dev2-ns
no
$ kubectl config use-context microk8s-dev2
Switched to context "microk8s-dev2".
$ kubectl auth can-i get pods -n dev1-ns
no
$ kubectl auth can-i get pods -n dev2-ns
yes

以上です。段々Operatorの使い方も慣れてきました。

NamespaceをプロビジョニングするOperatorを作ってみる(NetworkPolicy編)

NamespaceをプロビジョニングするOperatorがあったら、マルチテナントでクラスター運用するのが楽になるかなぁと思って作成してみています。本日はNetworkPolicyのプロビジョニング機能を作成します。

  • はじめに
  •  Operatorを作成する
    • CRDを作成する
    • Controllerを追加する
  • Operatorをビルドする
  • Operatorをデプロイする
  • Operatorを確認する

はじめに


以下の記事からNamespaceをプロビジョニングするOperatorを作成しています。以下の記事では、リクエストサイズに合わせてResourceQuotaを作成する機能を作成しました。

NamespaceをプロビジョニングするOperatorを作ってみる(サイズ編)

今回は、上記で作成したOperatorにNetworkPolicyを作成する機能を追加します。アプリケーション毎にNetworkPolicy要件は変わりますが、ログ管理やメトリクス管理などの管理系Podからの通信は許可することが多いです。従って、以下の通信要件を持ったNetworkPolicyをプロビジョニングするOperatorを作成します。

  • Ingress・・・カスタムリソースのmanagedの値に応じて、通信要件を変更する。
    • managed: true・・・ラベルが「app=infra」のNamespace内にあるPod(管理系Pod)からの通信を許可する。それ以外は拒否。
    • managed: false・・・全て許可。
  • Egress・・・全て許可。

Operatorを作成する


CRDを作成する


CRで設定できる項目を定義します。pkg/apis/nspro/v1alpha1/nspro_types.goのNsproSpecにManaged bool `json:”managed”`を加えて、運用管理対象か指定できるようにします。

~~省略~~
type NsproSpec struct {
    // INSERT ADDITIONAL SPEC FIELDS - desired state of cluster
    // Important: Run "operator-sdk generate k8s" to regenerate code after modifying this file
    // Add custom validation using kubebuilder tags: https://book.kubebuilder.io/beyond_basics/generating_crd.html
    NsSize string `json:"nssize"`
    Managed bool `json:"managed"`
}
~~省略~~

変更を加えたら、以下のコマンドで必要なコードを再生成します。

$ operator-sdk generate k8s
INFO[0006] Running deepcopy code-generation for Custom Resource group versions: [nspro:[v1alpha1], ]
INFO[0011] Code-generation complete.

Controllerを追加する


ControllerのReconcile関数にはnewNetworkPolicyForNSを呼び出して、リソースを作成する処理を記述します。

func (r *ReconcileNspro) Reconcile(request reconcile.Request) (reconcile.Result, error) {
    ~~省略~~
    np := r.newNetworkPolicyForNS(instance)
    err = r.client.Create(context.TODO(), np)
    ~~省略~~
}

newNetworkPolicyforNSは以下の通りです。作成方法は他のリソースと同じですが、NetworkPolicyのAPIはvender/k8s.io/api/networking/v1/type.goに記述されています。

func (r *ReconcileNspro) newNetworkPolicyForNS(cr *nsprov1alpha1.Nspro) *networkingv1.NetworkPolicy {
  nsname  := cr.Name
  namespace_labels := map[string]string{}
  if ( cr.Spec.Managed ) {
    namespace_labels["app"] = "infra"
  }
  np := &networkingv1.NetworkPolicy{
    ObjectMeta: metav1.ObjectMeta{
      Name:      nsname + "-np",
      Namespace: nsname,
    },
    Spec: networkingv1.NetworkPolicySpec{
      Ingress: []networkingv1.NetworkPolicyIngressRule{
        {
          From: []networkingv1.NetworkPolicyPeer{
            {
              NamespaceSelector: &metav1.LabelSelector{
                MatchLabels: namespace_labels,
              },
            },
          },
        },
      },
    },
  }
  controllerutil.SetControllerReference(cr, np, r.scheme)
  return np
}

Operatorをビルドする


作成したOperatorのコンテナイメージをビルドします。

$ operator-sdk build 192.168.64.2:32000/nspro-operator:v1

以下のコマンドでレジストリに登録します。今回はMicroK8s上のコンテナレジストリ上に登録するので、[WorkerNodeのIPアドレス]:[NodePort]/[イメージ名]:[タグ名]のように登録しておきます。

$ docker push 192.168.64.2:32000/nspro-operator:v1

Operatorをデプロイする


Operatorをデプロイします。Operatorの前にCRDを作成しないとapiVersionが利用できないので、CRDから作成します。

$ kubectl create -f deploy/crds/nspro_v1alpha1_nspro_crd.yaml 
customresourcedefinition.apiextensions.k8s.io/nspros.nspro.example.com created

続いてdeploy/配下にあるyamlを作成します。operator.yamlだけイメージ名を変更する必要がありました。

$ kubectl delete -f deploy/operator.yaml 
deployment.apps "nspro-operator" deleted
$ kubectl create -f deploy/operator.yaml -n nspro-operator
deployment.apps/nspro-operator created
$ kubectl create -f deploy/service_account.yaml -n nspro-operator
serviceaccount/nspro-operator created
$ kubectl create -f deploy/role.yaml -n nspro-operator
role.rbac.authorization.k8s.io/nspro-operator created
$ kubectl create -f deploy/role_binding.yaml -n nspro-operator
rolebinding.rbac.authorization.k8s.io/nspro-operator created

Operatorを確認する


デプロイしたOperatorが正常に動くか確認します。

largeサイズの運用管理対象とするNamespaceを作成するカスタムリソースを作成します。以下のyamlを$ kubectl create -f [ファイル名] -n [Operatorのnamespace]で作成します。

apiVersion: nspro.example.com/v1alpha1
kind: Nspro
metadata:
  name: np
spec:
  nssize: large
  managed: true

カスタムリソース作成後、Namespaceが確認できました。

$ kubectl get ns np --show-labels
NAME   STATUS   AGE   LABELS
np     Active   7s    managed=true,size=large

想定しているNetworkPolicyが作成されていることも確認できました。

$ kubectl describe networkpolicy np-np -n np
Name:         np-np
Namespace:    np
Created on:   2020-06-28 15:26:29 +0900 JST
Labels:       <none>
Annotations:  <none>
Spec:
  PodSelector:     <none> (Allowing the specific traffic to all pods in this namespace)
  Allowing ingress traffic:
    To Port: <any> (traffic allowed to all ports)
    From:
      NamespaceSelector: app=infra
  Allowing egress traffic:
    <none> (Selected pods are isolated for egress connectivity)
  Policy Types: Ingress

以上です。実際の挙動確認しようと思いましたが、network-pluginが入ってないと機能しないので断念しました。

NamespaceをプロビジョニングするOperatorを作ってみる(サイズ編)

以下の記事でOperatorを作成する方法がわかりましたので、NamespaceをプロビジョニングするOperatorがあったら、マルチテナントでクラスター運用するのが楽になるかなぁと思って初めてみました。

Operator SDK をインストールしてOperatorを作成する(1/2)
Operator SDK をインストールしてOperatorを作成する(2/2)

  • はじめに
  •  Operatorを作成する
    • プロジェクトを作成する
    • CRDを作成する
    • Controllerを追加する
  • Operatorをビルドする
  • Operatorをデプロイする
  • Operatorを確認する

はじめに


本記事では、サイジングされたNamespaceを作成するOperatorを作成します。サイズはLarge/Medium/Smallを用意し、以下のようにQuotaでサイズを制限します。

  • Large・・・CPU Core 300m, Memory 300Mi
  • Medium・・・CPU Core 200m, Memory 200Mi
  • Small・・・CPU Core 100m, Memory 100Mi

これだけだとyamlを用意しておいた方が早いですが、今後拡張していくので一旦これだけの機能を備えます。

Operatorを作成する


Operator SDKを使ってgolanでOperatorを作成します。

プロジェクトを作成する


Operator SDKのプロジェクトを作成します。

$ operator-sdk new nspro-operator

CRDを作成する


CR用のAPIを追加します。

$ cd nspro-operator
$ operator-sdk add api --api-version=nspro.example.com/v1alpha1 --kind=Nspro

pkg/apis/nspro/v1alpha1/nspro_types.goが作成されるので、CRで設定できる設定項目を定義します。今回は、NsproSpecにNsSize string `json:”nssize”`を加えて、それぞれのサイズが指定できるようにします。

~~省略~~
type NsproSpec struct {
    // INSERT ADDITIONAL SPEC FIELDS - desired state of cluster
    // Important: Run "operator-sdk generate k8s" to regenerate code after modifying this file
    // Add custom validation using kubebuilder tags: https://book.kubebuilder.io/beyond_basics/generating_crd.html
    NsSize string `json:"nssize"`
}
~~省略~~

変更を加えたら、以下のコマンドで必要なコードを再生成します。

$ operator-sdk generate k8s
INFO[0006] Running deepcopy code-generation for Custom Resource group versions: [nspro:[v1alpha1], ] 
INFO[0011] Code-generation complete.

Controllerを追加する


以下のコマンドを実行して、Controllerのテンプレートを作成します。作成が完了すると、pkg/controller/nspro/nspro_controller.go が作成されます。

$ operator-sdk add controller --api-version nspro.example.com/v1alpha1 --kind Nspro

nspro_controllerを以下に示します。

package nspro

import (
    "context"
    nsprov1alpha1 "operator/nspro-operator/pkg/apis/nspro/v1alpha1"
    corev1 "k8s.io/api/core/v1"
    "k8s.io/apimachinery/pkg/api/errors"
    metav1 "k8s.io/apimachinery/pkg/apis/meta/v1"
    "k8s.io/apimachinery/pkg/runtime"
    resource "k8s.io/apimachinery/pkg/api/resource"
    "sigs.k8s.io/controller-runtime/pkg/client"
    "sigs.k8s.io/controller-runtime/pkg/controller"
    "sigs.k8s.io/controller-runtime/pkg/controller/controllerutil"
    "sigs.k8s.io/controller-runtime/pkg/handler"
    "sigs.k8s.io/controller-runtime/pkg/manager"
    "sigs.k8s.io/controller-runtime/pkg/reconcile"
    logf "sigs.k8s.io/controller-runtime/pkg/runtime/log"
    "sigs.k8s.io/controller-runtime/pkg/source"
)

var log = logf.Log.WithName("controller_nspro")

/**
* USER ACTION REQUIRED: This is a scaffold file intended for the user to modify with their own Controller
* business logic.  Delete these comments after modifying this file.*
 */

// Add creates a new Nspro Controller and adds it to the Manager. The Manager will set fields on the Controller
// and Start it when the Manager is Started.
func Add(mgr manager.Manager) error {
    return add(mgr, newReconciler(mgr))
}

// newReconciler returns a new reconcile.Reconciler
func newReconciler(mgr manager.Manager) reconcile.Reconciler {
    return &ReconcileNspro{client: mgr.GetClient(), scheme: mgr.GetScheme()}
}

// add adds a new Controller to mgr with r as the reconcile.Reconciler
func add(mgr manager.Manager, r reconcile.Reconciler) error {
    // Create a new controller
    c, err := controller.New("nspro-controller", mgr, controller.Options{Reconciler: r})
    if err != nil {
        return err
    }

    // Watch for changes to primary resource Nspro
    err = c.Watch(&source.Kind{Type: &nsprov1alpha1.Nspro{}}, &handler.EnqueueRequestForObject{})
    if err != nil {
        return err
    }

    // TODO(user): Modify this to be the types you create that are owned by the primary resource
    // Watch for changes to secondary resource Pods and requeue the owner Nspro
    err = c.Watch(&source.Kind{Type: &corev1.Namespace{}}, &handler.EnqueueRequestForOwner{
        IsController: true,
        OwnerType:    &nsprov1alpha1.Nspro{},
    })
    if err != nil {
        return err
    }

    return nil
}

// blank assignment to verify that ReconcileNspro implements reconcile.Reconciler
var _ reconcile.Reconciler = &ReconcileNspro{}

// ReconcileNspro reconciles a Nspro object
type ReconcileNspro struct {
    // This client, initialized using mgr.Client() above, is a split client
    // that reads objects from the cache and writes to the apiserver
    client client.Client
    scheme *runtime.Scheme
}

// Reconcile reads that state of the cluster for a Nspro object and makes changes based on the state read
// and what is in the Nspro.Spec
// TODO(user): Modify this Reconcile function to implement your Controller logic.  This example creates
// a Pod as an example
// Note:
// The Controller will requeue the Request to be processed again if the returned error is non-nil or
// Result.Requeue is true, otherwise upon completion it will remove the work from the queue.
func (r *ReconcileNspro) Reconcile(request reconcile.Request) (reconcile.Result, error) {
    reqLogger := log.WithValues("Request.Namespace", request.Namespace, "Request.Name", request.Name)
    reqLogger.Info("Reconciling Nspro")

    // Fetch the Nspro instance
    instance := &nsprov1alpha1.Nspro{}
    err := r.client.Get(context.TODO(), request.NamespacedName, instance)
    if err != nil {
        if errors.IsNotFound(err) {
            // Request object not found, could have been deleted after reconcile request.
            // Owned objects are automatically garbage collected. For additional cleanup logic use finalizers.
            // Return and don't requeue
            return reconcile.Result{}, nil
        }
        // Error reading the object - requeue the request.
        return reconcile.Result{}, err
    }

    // Define a new Namespace object
    ns := newNsproForCR(instance)

    // Set Nspro instance as the owner and controller
    if err := controllerutil.SetControllerReference(instance, ns, r.scheme); err != nil {
        return reconcile.Result{}, err
    }

    err = r.client.Create(context.TODO(), ns)

  quota := r.newQuotaForNS(instance)
  err = r.client.Create(context.TODO(), quota)

    return reconcile.Result{}, nil
}

func newNsproForCR(cr *nsprov1alpha1.Nspro) *corev1.Namespace {
    nssize := cr.Spec.NsSize
    labels := map[string]string{
        "size": nssize,
    }
    return &corev1.Namespace{
        ObjectMeta: metav1.ObjectMeta{
            Name:      cr.Name,
            Labels:    labels,
        },
    }
}

func (r *ReconcileNspro) newQuotaForNS(cr *nsprov1alpha1.Nspro) *corev1.ResourceQuota {
  nsname  := cr.Name
  size_map := map[string]int64{ "large": 3, "medium": 2, "small": 1 }
  size := size_map[cr.Spec.NsSize]
  cpuCores := resource.NewMilliQuantity(100*size, resource.DecimalSI)
  memorySize := resource.NewQuantity(1*1024*1024*size, resource.BinarySI)
  quota := &corev1.ResourceQuota{
    ObjectMeta: metav1.ObjectMeta{
      Name:      nsname + "-quota",
      Namespace: cr.Name,
    },
    Spec: corev1.ResourceQuotaSpec{
      Hard: corev1.ResourceList{
        "limits.cpu": *cpuCores,
        "limits.memory": *memorySize,
      },
    },
  }
  controllerutil.SetControllerReference(cr, quota, r.scheme)
  return quota
}

作成した部分は、newNsproForCR/newQuotaForNSとそれらの呼び出しです。

newNsproForCRがNamespaceを定義していて、nssizeで指定されたサイズをラベルに貼ってNamespaceを作成する単純な関数です。

newQuotaForNSは、nssizeで指定されたサイズに応じてlimitのサイズを定義します。各サイズに応じて数字をかけています。limits.cpu/limits.memoryは、Quantityを指定する必要があり、package resourceが参考になりました。

Operatorをビルドする


作成したOperatorのコンテナイメージをビルドします。

$ go mod vendor
$ operator-sdk build 192.168.64.2:32000/nspro-operator:v1

以下のコマンドでレジストリに登録します。今回はMicroK8s上のコンテナレジストリ上に登録するので、[WorkerNodeのIPアドレス]:[NodePort]/[イメージ名]:[タグ名]のように登録しておきます。

$ docker push 192.168.64.2:32000/nspro-operator:v1

Operatorをデプロイする


Operatorをデプロイします。Operatorの前にCRDを作成しないとapiVersionが利用できないので、CRDから作成します。

$ kubectl create -f deploy/crds/nspro_v1alpha1_nspro_crd.yaml 
customresourcedefinition.apiextensions.k8s.io/nspros.nspro.example.com created

続いてdeploy/配下にあるyamlを作成します。operator.yamlだけイメージ名を変更する必要がありました。

$ kubectl delete -f deploy/operator.yaml 
deployment.apps "nspro-operator" deleted
$ kubectl create -f deploy/operator.yaml -n nspro-operator
deployment.apps/nspro-operator created
$ kubectl create -f deploy/service_account.yaml -n nspro-operator
serviceaccount/nspro-operator created
$ kubectl create -f deploy/role.yaml -n nspro-operator
role.rbac.authorization.k8s.io/nspro-operator created
$ kubectl create -f deploy/role_binding.yaml -n nspro-operator
rolebinding.rbac.authorization.k8s.io/nspro-operator created

OperatorのPodがデプロイされます。

$ kubectl get pods -n nspro-operator
NAME                              READY   STATUS    RESTARTS   AGE
nspro-operator-585b76656d-jt4nm   1/1     Running   0          25s

Operatorを確認する


デプロイしたOperatorが正常に動くか確認します。

CRとして、nssizeがsmallのsmall-nsとnssizeがlargeのlarge-nsを作成します。それぞれ$ kubectl create -f [ファイル名] -n [Operatorのnamespace]でリソースを作成します。

apiVersion: nspro.example.com/v1alpha1
kind: Nspro
metadata:
  name: small-ns
spec:
  nssize: small
apiVersion: nspro.example.com/v1alpha1
kind: Nspro
metadata:
  name: large-ns
spec:
  nssize: large

ラベルで正しく分かれていることが分かります。

$ kubectl get ns small-ns -L size
NAME       STATUS   AGE   SIZE
small-ns   Active   19s   small
$ kubectl get ns large-ns -L size
NAME       STATUS   AGE   SIZE
large-ns   Active   7s    large

それぞれのサイズに合ったQuotaが定義されていて、使用量が制限できていることがわかります。

$ kubectl describe quota small-ns-quota -n small-ns
Name:          small-ns-quota
Namespace:     small-ns
Resource       Used  Hard
--------       ----  ----
limits.cpu     0     100m
limits.memory  0     1Mi
$ kubectl describe quota large-ns -n large-ns
Name:          large-ns-quota
Namespace:     large-ns
Resource       Used  Hard
--------       ----  ----
limits.cpu     0     300m
limits.memory  0     3Mi

以上です!半角スペースに気づかなかったりして大分PDに時間を取られてしまいました。。。