tkaaad97’s diary

json - The Go Programming Language

この issue でなんとなく CodeCommit などでの使い方がわかりました。

デフォルトでは https で依存パッケージを取得するようなんですが、メタデータを取得する API に対応している必要があってサーバーによってはこれに対応していないので https を使わないようにしてやる必要があるのだと思います。

~/.gitconfig の設定に以下を追加しました。

[url "ssh://git-codecommit.ap-northeast-1.amazonaws.com/"]
    insteadOf = https://git-codecommit.ap-northeast-1.amazonaws.com/

それからモジュール名末尾には .git をいれました。これはいらない場合もあるかもしれません。

go mod init git-codecommit.ap-northeast-1.amazonaws.com/v1/repos/hello.git

パッケージ

下のようにソースの一行目にパッケージの指定があります。

package main

import (
    "fmt"
)

func main() {
    fmt.Println("hello, world")
}

最初は一つのファイルがパッケージと対応しているのかと思っていましたが、これは間違いで Go のパッケージは一つのディレクトリと対応しているようです。

同じディレクトリにおいたファイルは同一のパッケージにする必要があって、ファイルが分かれていても同じパッケージ内であれば import せずに関数などを利用できます。

それから同じリポジトリ内であっても import は相対的パスなどではなくホスト名を含むパッケージ名を使うのが普通のようでした。

Lambda を書いたりする場合に CLI ツールとしても使えるようにライブラリのパッケージ、Lambda パッケージ、CLI ツールパッケージと分けたりすることがあるんじゃないかと思います。

例えば下のようなディレクトリ構成になります。

hello/
├── app
│   └── main.go
├── lambda
│   └── main.go
└── lib
    └── hello.go

lib/hello.go はライブラリとして他のパッケージから使われる関数などを含んでいます。パッケージで公開される関数や定数の名前は大文字で開始するという決まりになっているようです。これは人によって好み分かれそうですが export を別に書かなくていいのは楽だなと思いました。

package hello

import (
    "fmt"
)

func Hello() {
    fmt.Println("hello, world")
}

app/main.go は CLI ツールなどのパッケージで lib/hello.go を import して使います。 import する名前にはソースリポジトリ名にパッケージのディレクトリのパスを追加して指定します。ライブラリではなくアプリケーションとして実行するパッケージは main パッケージにして main 関数を定義します。

package main

import (
    "git-codecommit.ap-northeast-1.amazonaws.com/v1/repos/hello.git/lib"
)

func main() {
    hello.Hello()
}

go build コマンドで実行ファイルをビルドします。

go build -o hello ./app

go run コマンドでそのまま実行もできます。

go run ./app

スライス

スライスはランダムアクセスできて要素の追加もできるコンテナです。 C++ の std::vector に近いものだと思います。内部に要素サイズと、確保したサイズ、ポインタを保持するような実装になってるんじゃないかと思います。 std::vector のように要素をメモリ上に連続で確保するようになっていて、足りない場合は新しくメモリを確保して作り直すようです。下のようなコードでポインタの値が変わっているのが見られました。

package main

import (
    "fmt"
)

func main() {
    a := make([]int, 2,  3)
    fmt.Println(a) // [0 0]

    a[0] = 1
    a[1] = 2
    fmt.Println(a) // [1 2]

    fmt.Printf("%v %p %p\n", a, &a, &a[0]) // [1 2] 0xc00000c060 0xc000014380

    a = append(a, 3)
    fmt.Printf("%v %p %p\n", a, &a, &a[0]) // [1 2 3] 0xc00000c060 0xc000014380

    a = append(a, 4)
    fmt.Printf("%v %p %p\n", a, &a, &a[0]) // [1 2 3 4] 0xc00000c060 0xc0000181b0
}

要素数がわかる場合は指定したほうが余分なメモリ確保やコピーが減るので速くなると思います。これは std::vector で reserve 使ったりするのと同じ感じだと思います。

マップ

マップはキーと値を持つコンテナです。大体は C++ の std::map と似ているんですがキーはソートされていない構造のようです。 map の要素をイテレートするとき順序が保証されないことに気を付ける必要があります。

下のコードを実行すると順序がバラバラになっているのが見られました。

順序固定する場合はキーを一度取得してソートしてからキーでアクセスします。

package main

import (
    "fmt"
)

func main() {
    a := map[string]int{
        "a": 1,
        "b": 2,
        "c": 3,
        "d": 4,
        "e": 5,
    }

    fmt.Println(a)

    for i := 0; i < 10; i++ {
        for k, v := range a {
            fmt.Printf("%s %d\n", k, v)
        }
    }
}

JSON

golang.org

標準で入っている JSON のライブラリが使えます。 json.Marshal で JSON への変換、 json.Unmarshal で JSON から struct などの変換ができます。

struct はそのまま何もしなくても JSON にできます。

フィールドにタグを付けて少しカスタマイズすることもできます。

package main

import (
    "encoding/json"
    "fmt"
)

type Person struct {
    Name string `json:"name"`
    Age int `json:"int"`
    PhoneNumber string `json:"phone_number,omitempty"`
}

func main() {
    a := Person{
        Name: "Taro",
        Age: 3,
    }

    bytes, err := json.Marshal(a)
    if err != nil {
        panic(err)
    }

    fmt.Println(string(bytes))

    b := Person{}
    err = json.Unmarshal(bytes, &b)
    if err != nil {
        panic(err)
    }

    fmt.Println(b)
}

独自に変換処理を書きたい場合は MarshalJSON と UnmarshalJSON を定義してやればいいようです。

Example (CustomMarshalJSON) の部分に例がありました。

テスト

go test のコマンドで簡単にテスト実行できるようになっています。 hoge_test.go のようなファイル名にして Test ではじまる名前の関数を定義するとテストとして実行されます。

テストで assert を書くのにこのライブラリが便利でした。

package main

import (
    "github.com/stretchr/testify/assert"
    "testing"
)

func TestA(t *testing.T) {
    a := []string{ "aaa", "bbb" }
    b := []string{ "aaa", "BBB", "ccc" }
    assert.Equal(t, a, b)
}

CLI

CLI ツールを書くときに使えるライブラリも色々あるようなんですが cobra というライブラリを少し使いました。

少し使った感じはサブコマンドも書けて、引数やオプションのキャプチャも簡単だったのでよさそうに感じました。

aws-cli を使ったシェルスクリプトなどを書いていてオプションとか扱うのがなかなか大変なので Go で書いて aws-sdk-go 使うのもいいかもなと思いました。

Lambda や CodeBuild でも多分使えると思うので実行もしやすいと思います。

AWS SAM

aws.amazon.com

Go 言語関係無い話ですが Lambda を書くときに AWS SAM を使うと便利でした。

CloudFormation に変換されるテンプレートで Lambda や CloudWatch イベント、API Gateway、IAM ロールなどのリソースを定義して AWS SAM のコマンドでパッケージ化とデプロイが簡単にできるようになっています。

ローカル環境で Docker を使って Lambda の挙動をテストすることもできます。

AWS SDK

Go 言語向けに AWS SDK のライブラリが公開されていてこれを使って AWS の API を色々利用できます。

aws.amazon.com

aws-sdk-go-v2 というライブラリもあるようなんですがまだ Developer Preview の段階でした。

基本的に API 呼び出すためのライブラリですが一部ユーティリティの機能も追加されていてページネーションに対応した便利な関数などもあるようでした。

テスト用のモックも用意されているようです。

Programming OpenGL in Linux: GLX and Xlib - OpenGL Wiki

感想

使う前は機能が色々足りてないような印象だったんですが書いてみると意外と書きやすく感じました。

書きにくいと感じたり他の言語でできることができないために自分で書かなければいけないようなコードが増えたりもするんですが、こういう言語だから仕方ないとあきらめて書いているとあまり悩まずに書ける気がしました。

コンパイラで静的に色々チェックされるのも安心感があって Python とかシェルスクリプトとかで色々書くのよりも自分にはあってる気がしました。

2019-05-27

OpenGL を使うテストを CI でするときに osmesa が使えそう

はじめに

前に docker で OpenGL を使う環境を作ってそれでローカル環境では動かせていたんですが CI の環境では GPU が使えなかったり、X Server がない、privilegedのオプションが使えないなど場合もあってそのままでは使えないことが多いので CI でも使える方法を少し調べていました。

テストするときも実際に使うときと同じ環境でやったほうがいいのは間違いないですが、 CI である程度の部分だけでもテストできると嬉しいと思います。

osmesa

Linux 環境では OpenGL はほとんどの場合 GLX から使うようになっています。同様に Windows の場合は WGL から OpenGL を使います。

GLW と WGL には OpenGL のコンテクストを作成したり、OpenGL の API のアドレスを取得するインターフェースがあります。

CI 環境や GUI がインストールされていないサーバーだと GLX が使えない場合があります。こうした場合に osmesa が使えるようです。osmesa はソフトウェアレンダリングによる OpenGL 実装です。

www.mesa3d.org

ただ osmesa は OpenGL の機能を完全に実装しているわけではないようで、新し目の glsl バージョンのシェーダをコンパイルできないことがありました。なので描画に直接関係する部分のテストには使えないかなと思いますが、バッファの確保や解放などリソース管理のテストぐらいはある程度できると思います。

Ubuntu の場合は apt で osmesa を入れることができたので、これを使っています。 (apt のパッケージは libosmesa6-dev という名前でした。)

自分でビルドするともう少し新しい OpenGL バージョンに対応しているかもしれません。

LD_PRELOAD で関数を置き換える

osmesa を使うにはコンテキストを初期化する部分と OpenGL API のアドレスを取得する部分を変更する必要があります。

コンテキストを初期化する部分は独自に実装すればなんとかなりますが、 OpenGL API のアドレスを取得する部分が OpenGL バインディングライブラリ内にあって切り替えられないという問題がありました。

そこで LD_PRELOAD の環境変数を使って glXGetProcAddress を呼び出したときに OSMesaGetProcAddress が使われるようにするという方法を使いました。

動的リンクのライブラリに同じ名前の関数が複数あった場合に先に見つかった関数が使われるため、 LD_PRELOAD でライブラリを読み込ませることで上書きできるようです。

下のようなコードを書いて共有ライブラリを作成して使いました。

typedef unsigned char GLubyte;
typedef void (*genericFunctionPointer)(void);
extern genericFunctionPointer OSMesaGetProcAddress(const GLubyte *);

genericFunctionPointer glXGetProcAddress(const GLubyte* name)
{
    return OSMesaGetProcAddress((const char*)name);
}

genericFunctionPointer glXGetProcAddressARB(const GLubyte* name)
{
    return OSMesaGetProcAddress((const char*)name);
}

gcc -shared -fPIC cbits/glxoverride.c -o libglxoverride.so

GPU を使える場合

https://circleci.com/docs/ja/2.0/gpu/

nvidia で公開されている docker コンテナでは GLX のかわりに EGL を使うようになっているようです。 GPU は使えるが X Server はないという場合は EGL が使えそうです。

CircleCI で GPU を使える環境もあるようで予算がある場合はこれもいいかもしれません。

2019-03-31

CodeDeploy を導入したときに調べたことなど

はじめに

大分前に CodeDeploy について少し調べたことがありました。

tkaaad97.hatenablog.com

その後実際に CodeDeploy を導入する機会があってもう少し色々調べたり試したりしたことがあったのですが、導入したことに満足して調べたことをまとめていませんでした。

しばらく時間がたって忘れてるところもありますが、また使う機会もあるかもしれないのでここに書いておきます。

リビジョン作成

CodeDeploy ではデプロイするソースとして S3 か GitHub が使えます。しかしデプロイ時に展開するものは GitHub で管理されているソースだけでは無いことが多いので S3 を使うことの方が多いと思います。スクリプト言語の場合は依存ライブラリなども取得してデプロイする必要があります。コンパイルする場合バイナリは Git 管理しないことが多いと思います。

S3 にファイルをアップロードしてリビジョンを作成するためのコマンドがあります。

しかしこのコマンドではあまり細かい制御ができないため結局使いませんでした。隠しファイルを含めるかどうかというオプションがあるのですが一部だけ含めたりという指定ができませんでした。

dev.classmethod.jp

こちらの記事を参考に aws deploy push に相当する処理を行うスクリプトを作成してリビジョン作成を行うようにしました。

場合によっては CodeDeploy でのインストール処理とは別に Ansible Playbook などを実行して独自にインストール処理を行うということもあるかもしれません。この場合は CodeDeploy でインストールするのは Ansible のファイルだったりリビジョンに含めるものは変わってくると思います。

ソース配置ディレクトリをアプリケーションによって変えたい

CodeDeploy でどのディレクトリにソースを配置するかは appspec.yml で指定します。 files の destination の部分です。

あまり普通はやらないし推奨されないと思いますが複数のアプリケーションを同一のサーバーにデプロイする場合ソース配置ディレクトリが同じになってしまいます。

アプリケーションごとに appspec.yml を変えるといった方法は無いようでした。しかしリビジョン作成時に appspec.yml を書き換えるという無理やりな方法で一応は目的のことができました。

デプロイグループごとにデプロイ処理を変えたい

同じソースをデプロイするサーバーでも色々と役割が違うものがあります。例えばウェブサーバーがあったり、分析や集計などを行うサーバーがあったりして、役割ごとにデプロイグループを分けるのが普通だと思います。

デプロイグループごとに変えるには CodeDeploy で提供されている環境変数を使うことができます。

docs.aws.amazon.com docs.aws.amazon.com

APPLICATION_NAME と DEPLOYMENT_GROUP_NAME の環境変数があるのでこれに基づいて設定ファイルを読み込んだり、AWS Systems Manager パラメータストアから設定を取得しデプロイの処理を変えることができます。

オートスケーリンググループに複数のデプロイグループを付けられるか

複数のデプロイグループに同じオートスケーリンググループを設定することはできるんですが、試したところこれはやめたほうがいいということが分かりました。

問題はオートスケーリングでインスタンスが新しく追加されたときに両方のデプロイグループのデプロイ処理が同時に動いて正常に動作しないという点でした。オートスケーリングを使っていない EC2 タグでデプロイを行っている場合はそんなに問題ないかもしれません。同時にデプロイしたりするとエラー起こりそうですが。

デプロイごとに処理を変えたい

複数デプロイグループを作ろうとしたのは同じ役割のサーバーでもデプロイを行うときに処理を変えたい場合があったからでした。先に書いたように複数デプロイグループで分岐するのは上手くいかなかったため、リビジョン作成時にファイルを追加してこのファイルを読んで処理を分岐するというような方法を使いました。

オートスケーリンググループに複数のロードバランサーが付いている場合

複数のロードバランサーには CodeDeploy は対応していないようです。複数のロードバランサーを使うのは諦めるか、自前でロードバランサー関連の処理を行うことになります。

オートスケーリンググループのインスタンスは全てをロードバランサーに付けるか外すかの二択かと勘違いしていたのですが、オートスケーリンググループ中の個々の EC2 インスタンスごとにロードバランサーから一時的に外したりということができます。

インプレースデプロイの場合はアプリケーションストップ時にロードバランサーから一時的に外し、デプロイが終わってアプリケーションスタート時にロードバランサーに付けるという感じのことができるようです。

この処理については GitHub に公開されていたサンプルが参考になりました。