Goをローカルでビルド -> EC2へ簡易デプロイ

簡易な検証等でgoのプログラムをEC2へデプロイする手段メモ。

ローカルのmain.goをEC2へアップロードする。

1. linux向けにビルドし、実行ファイルを作成する。
$ GOOS=linux GOARCH=amd64 go build  main.go
2. 実行ファイルをEC2インスタンスへ転送。
# ec2-userのホームディレクトリ下 appディレクトリにアップロードする場合
$ scp -i　<your-key-pair>.pem main ec2-user@<public-ip>:~/app

EC2のメトリクスにメモリ使用率とディスク使用量を追加（モニタリングスクリプト使用）

参考

https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/mon-scripts.html

手順

1．必要なパッケージをインストール

$ sudo yum install -y perl-Switch perl-DateTime perl-Sys-Syslog perl-LWP-Protocol-https perl-Digest-SHA.x86_64

2．モニタリング用スクリプトをダウンロード

# スクリプト保存用ディレクトリを作成
$ cd
$ mkdir custom-metrics
$ cd custom-metrics
# モニタリング用スクリプトをダウンロード
$ sudo yum install -y perl-Switch perl-DateTime perl-Sys-Syslog perl-LWP-Protocol-https perl-Digest-SHA.x86_64
# ダウンロードファイルを解凍
$ unzip CloudWatchMonitoringScripts-1.2.2.zip && rm CloudWatchMonitoringScripts-1.2.2.zip

3．EC2のロールに以下の内容のポリシーをアタッチする

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "cloudwatch:PutMetricData",
                "cloudwatch:GetMetricStatistics",
                "cloudwatch:ListMetrics",
                "ec2:DescribeTags"
            ],
            "Resource": "*"
        }
    ]
}

4．cronの設定

# crontabエディタを開く
$ crontab -e

以下の内容を追加する

*/5 * * * * ~/custom-metrics/aws-scripts-mon/mon-put-instance-data.pl --mem-used-incl-cache-buff --mem-util --disk-space-util --disk-path=/ --from-cron

Amazon Redshiftのスナップショットについて

スナップショットの種類

  • 自動スナップショット
  • 手動スナップショット

自動スナップショット

デフォルトで有効となっており、8時間ごとまたはノードあたり5GBのデータ変更ごとに自動的に作成される。 スナップショットの保持期間はデフォルトで1日と設定されている（変更可。0日に設定するとスナップショットが作成されなくなる）。 スナップショットストレージの無料分（クラスターのストレージ容量と同等）を使用でき、無料分を超えた場合は課金される。 クラスターを削除した場合、自動スナップショットも削除される。

手動スナップショット

好きなタイミングで作成できる。 自動的には削除されない。 手動スナップショットにはストレージ料金（S3 標準ストレージ 使用料）が発生する。不要になったスナップショットは適宜手動で削除する必要がある。 クラスターを削除した後も、手動スナップショットは保持される。 クラスターを削除する際、その時点のスナップショットを作成できる。

スナップショットからの復元

クラスターの復元

ノード数、ノードタイプなどの設定を含めたクラスターの状態を復元。 リージョン、アベイラビリティゾーンも指定をしない限り同一。

クラスター復元の手順（コンソールから操作）
  1. Amazon Redshiftのコンソールから、スナップショットのページを開く。
  2. 対象のスナップショットを選択。
  3. 「アクション」をクリックし、プルダウンメニューから「スナップショットからの復元」をクリック。
  4. 「スナップショットからのクラスターの復元」で設定を確認。
  5. 「復元」ボタンをクリックしてテーブルを復元。

テーブルの復元

クラスターサイズが異なる場合、復元はできない。

テーブル復元の手順（コンソールから操作）
  1. Amazon Redshiftのコンソールから、対象クラスターのページを開く。
  2. 「テーブルの復元」タブを開く。
  3. 「テーブルの復元」ボタンをクリック。
  4. 「テーブルレベルの復元」で必要な情報を入力（データベース名、スキーマ名、テーブル名）。 5.「復元」ボタンをクリックしてテーブルを復元。

参考

Amazon Redshift スナップショット - Amazon Redshift

Git Subtree

git subtreeとは

git subtreeは、外部のgitリポジトリを自分のgitリポジトリのサブディレクトリとしてする仕組み。

使い方

外部のリポジトリを取り込む方法

mainリポジトリとsubリポジトリの二つが存在している。 mainのサブディレクトリとしてsubリポジトリの内容を取り込みたいとする。

ステップ1：mainプロジェクトのremoteにsubリポジトリを登録する
$ git remote add sub-repo https://github.com/example/sub.git
ステップ2：mainプロジェクトにsubリポジトリの内容を取り込む

mainプロジェクトにおいて以下のコマンドを実行する。

$ git subtree add --prefix=lib/sub sub-repo master

実行後、"lib/sub"ディレクトリにsubリポジトリのmasterブランチの内容が取り込まれる。 subtreeの中身の処理としては、subリポジトリのコミットログからなる新規ブランチ（上記の例だとsubリポジトリ）を作成し、そのブランチをマージしている。 そのため、gitのlogにも取り込み先のコミットログが追加される。

リポジトリの更新

subリポジトリの変更を取り込む

外部でのsubリポジトリの更新があった際に、mainに取り込んでいるサブディレクトリの中身を更新する場合。

$ git subtree pull --prefix=lib/sub sub-repo master
subリポジトリに変更を反映する

mainプロジェクト内でsubサブディレクトリを編集し、その変更分をsubのリモートリポジトリにプッシュする場合。 変更分のコミットを行なったのちに以下のコマンドを実行。

$ git subtree push --prefix=lib/sub sub-repo master

"lib/sub"ディレクトリの変更分がsubリポジトリのmasterブランチにプッシュされる。

プロジェクトの一部を切り出す方法

mainプロジェクトの"lib/sub"ディレクトリを切り出して個別のリポジトリとしたい場合。

ステップ1：切り出すディレクトリのコミットログのみを、新しいブランチとして切り出す
$ git subtree　split --prefix=lib/sub -b split-sub

このコマンドにより、"lib/sub"ディレクトリ内の変更分のコミットログのみを含んだ"split-sub"という名前のブランチが作成される。

ステップ2：切り出したブランチをリモートリポジトリへプッシュする

切り出したブランチに移動して、取り込み先のリポジトリへプッシュ。

$ git checkout split-sub
$ git push https://github.com/example/sub.git split-sub

参考

・Git Subtree 事始め https://qiita.com/mikakane/items/487ca8b3acddfa5fdb41

・git-subtree移行メモ https://qiita.com/shogo82148/items/04b29b195dbbb373152f

Git Submodule

git submoduleとは

git submoduleは、外部のgit リポジトリを自分のgitリポジトリのサブディレクトリとして登録し、その特定のcommitを参照する仕組み。

使用方法

外部リポジトリをサブモジュールとして取り込む

リポジトリAのsubディレクトリに外部リポジトリBを取り込む場合

git submodule add https://github.com/example/B.git sub/B

これで、subディレクトリ内にBというディレクトリが追加される。この時点でBの中身は空である。

また、Aのディレクトリ直下に.gitmodules というファイルが追加される。このファイル内で参照先のリポジトリと手元のファイルパスの対応づけを記録している。

Bリポジトリの実体を取り込むには以下のコマンドを実行する。

git submodule update --init

initしたサブモジュールの実体を削除する

以下のコマンドで、プロジェクト内に取り込んだサブモジュールの実体を削除できる。サブモジュールの参照情報を含んだファイルは削除されない（initする前の状態となる）。

git submodule deinit sub/B

参考

Git submodule の基礎 https://qiita.com/sotarok/items/0d525e568a6088f6f6bb