Briswell Tech Blog

ブリスウェルのテックブログです

GitLab CI Doker imageからAWS S3経由でLambdaに更新をかける

とある基幹システムの非同期処理等をAWS Lambda上で構築しようとした際のGitLab CI のご紹介です。

※ただ、結果として非同期処理はElasticBeanstalk の Worker環境で行うことにしたので、本番運用までは行なっていないです。

 

前回同様、test などは省きます

 

- pip install awscli

→EB install

 

- git checkout SendMail

→メールを送信するバッチをGitから持ってくる


- chmod +x .aws-config.sh
- ./.aws-config.sh

AWS の credentials


- export PATH=~/.local/bin:$PATH

→PATH通す


- apt-get update
- apt-get install -y zip unzip

→unzip を install

 

ここまでが事前準備

 

- zip -j SendMail.zip dst/*

→deployしたい対象ソースをzip化


- aws s3 cp SendMail.zip s3://lambda-zip/SendMail.zip

→zip したファイルをS3に置く


- aws lambda update-function-code --function-name SendMail --s3-bucket lambda-zip- --s3-key SendMail.zip --publish --profile=lambda

→置いたzipからLambdaへdeploy

 

これで一応deployはしてくれました。

ただ、本番運用するとなると、実行中のLambdaにdeployする訳にはいかないケースなど出てくると思うので、その辺りは都度調整が必要そう...

 

以上です。

間違い等ございましたらご指摘いただけますと幸いです...

GitLab CI Doker imageからAWS Elastic Beanstalkに更新をかける

  • GitLab CI Doker imageからAWS Elastic Beanstalkに更新をかける

だいぶ放置しました。

最近はGitLab CIから Circle CI に乗り換えたりしているのですが、載せます!

と言ったので、載せます!

 

  • 事前準備編

eb init

コマンドで作成される

.elasticbeanstalk/config.yml

があること

※開発と本番でglobal application_name が異なるため、僕は

.elasticbeanstalk/development/config-dev.yml

.elasticbeanstalk/production/config-prod.yml

 に分けて、後ほどCIで mv コマンドで入れてます。

 

.ebextensions/ の中にやりたい内容があること

僕がやってるのは

https の設定

nginx の設定

env の設定

くらいです。

https の設定で

SSLCertificateArns を間違えて開発と同じでデプロイしておかしくなったこともありました。

 

  • GitLab CI の中身

stages とか、test コマンドなどは省きます。

単純に ElasticBeanstalk に上がるとこらへんのみの Script を記載してます。

- mv .elasticbeanstalk/development/config-dev.yml .elasticbeanstalk/config.yml

これで開発環境のを持ってくる

- mv .ebextensions/development/env-dev.config .ebextensions/env.config

環境変数もついでに持ってくる

- mv .ebextensions/development/load-balancer-dev.config .ebextensions/load-balancer.config

SSLCertificateArnsが違うのでこれも持ってくる

 

- pip install awsebcli --upgrade --user

EB install

- git checkout develop

Git から持ってくる

- chmod +x .eb-config-dev.sh

- ./.eb-config-dev.sh

↑この中にAWS情報を記載しておく

- export PATH=~/.local/bin:$PATH

PATH通す

- eb --version

一応確認しておく

 

- eb use AdminConsoleDevelopment-env

deployしたい環境を記載しておく

- eb status

一応確認しておく

- eb deploy

でデプロイ

 

以上です。

 

これをdevelopブランチとmaster ブランチで分けて記載して環境分ければうまくいくのかなと...

 

個人的に悩んでいるところは、

eb use AdminConsoleDevelopment-env ← ここにdeployをし、稼働開始

その後、新しいソースを乗っけたサーバ

AdminConsoleDevelopment-env-1 ←を作成し、URLスワップを行うと

↑こいつが最新になる

とすると、次回deployする時、またCIの中身を

AdminConsoleDevelopment-env

など、違うアプリーケーション名にしないといけない状態...

これを解決したい...

 

何か誤り等ございましたらご指摘いただけますと幸いです...

AWS認定ソリューションアーキテクト・アソシエイト 取得しました

AWS認定ソリューションアークテクト アソシエイト 取得しました!

 

AWS自体は2013年頃から触りはじめ、今年の頭くらいから取得しようと考えてずるずると11月に...

このままだと!と思い、11月頭に申し込みを行いました。

 

試験まで約2週間

とにかく

https://www.amazon.co.jp/dp/4295005495

 

この本を3度読み直し、触ったことないサービスはできるだけ自分で触ってみて理解を深める。

それ以外の足りない知識は別で調べて記事を読む...

というのを繰り返し行いました。

 

結果は

804/1000

でした。

f:id:Toshi_bw:20191115194620p:plain

 

模擬などと比べ、他の方も言われている通り、日本語がわかりずらい部分が多少ありました...

 

受かってよかった!

AWS Lightsail

今までAWS Lightsail ってメニューになんかいるなー、程度で全く知らなかった。

本日たまたま [Amazon Personalize] のハンズオンセミナー に参加した時に触れてて、初めて触った。

 

料金面でEC2 インスタンスの場合

時間単位の課金 + 従量課金

→そのため、中々正確な金額を見積ことが難しい

Lightsail

→月額固定

これが凄く良い。

 

他にもWordPress Lamp Redmine GetLab などなどが用意されていて、

本当に3クリックくらいで簡単に構築できた。

$3.5出し...一番安いの...

 

更にEC2 への移行もできるらしい....

本番環境等では使えないかもしれないが、気軽に立てて遊んだりするのにはとても良いと感じた。

 

排他制御

Web基幹システム(その他でも)を構築しているとよく後勝ち問題に出くわす。

 

  • 後勝ち問題

f:id:Toshi_bw:20190312100234p:plain

後勝ち問題

上記図のように、Aさんが修正画面起動後にBさんが編集画面を起動、

後に修正画面を開いたBさんが先に保存を行い、Aさんが後で保存を行う。

すると、Bさんの修正をAさんは知らない状態なので、Bさんの修正はAさんによって上書きされてしまう。

Bさんは修正したのにされていないこととなってしまう。

 

Bさんは自分は修正できた!と思っているはずなので、何かしらで後々修正されていないことを知ることとなる。

 

業務的にこのようなことが発生する = AさんとBさんがやりたい業務が異なっており、画面の責務を分割すべき、というのももちろんあるが、一旦そこはおいておく。

(例えばAさんは顧客情報を修正しようとしており、Bさんは顧客ステータスのようなものを修正しようとしていたなど)

 

先ほどの図と同じだが、Aさんが保存をしようとした時に「Bさんが保存処理を行なったため、最初からやり直してください」 or 「Bさんが保存処理を行いました、強制的に保存を行うとBさんの修正を上書きしてしまいます」

といった処理。

具体的にはAさんが修正画面起動時に最終更新日時のようなデータを保持しておき、保存時に現在の最終更新日時と比べる。

異なっていればメッセージを表示することにより、知らずに上書きされることをある程度避けることが可能となる。

(ある程度、というのはAさんがいじわるで、強制保存を行い、Bさんに通達しないケース)

 

この処理が向いているのは、更新頻度が低く、更新者があまりいない、マスタ系に向いている。

 

f:id:Toshi_bw:20190312100904p:plain

悲観的排他制御

ほぼ一緒の図だが、今回はBさんは修正開始で終わっている。

Aさんが修正開始したタイミングで、データに編集中フラグのような物を更新する。

Bさんが修正開始しようとしたタイミングで「Aさんが何時何分から修正中です」

とメッセージを表示し、修正できないようにする方法。

Aさん保存時に編集中フラグをOFFに更新することによって、他のユーザが編集可能となる。

Aさんが途中で画面離脱するケースも想定し、何分以上保存されなかった場合は編集中フラグを自動でOFFにする、というJobも必要となる。

 

この処理が向いているのは割と更新頻度が高く、更新対象者も先ほどよりかは多くいるケース、トランザクション向き。

 

 

システム利用経験が少なかったりするユーザの場合、後勝ちを理解していない場合が多いので、システム利用前に予め説明を行い、何かしらの制御を入れるのが良いと思う。

 

 

です!

 

t1.micro サーバのお話

AWS EC2インスタンス

t1.micro

に対してメンテナンスが入ると通知があった

 

Amazon Web Services is performing a refresh on all Amazon EC2 T1.micro instances. The instance refresh will offer higher host reliability, better CPU performance and match the CPU burst experience of T1.micro instances to be consistent with T2 instances.

 」

t2インスタンス並みにCPUパフォーマンスがあがるよーと。

Starting February 1, 2019, you can stop and restart your Amazon EC2 T1.micro instances to take advantage of the instance refresh. After March 1, 2019, Amazon EC2 T1.micro instances that have not been stopped, will be scheduled for maintenance.

 」

3/1までに停止 → 開始をすることで反映されて、3/1までにやってないインスタンスは強制再起動されるよーと。

 

CPUパフォーマンスが向上するのは良いことなので、先にやってしまおうと。

結構古くから使ってるインスタンスで、社内ツールが配置されているもので対象が3台あった。

社内に通達して、停止 →  開始を3台行う、

内2台は確かにCPUの使用率は格段に下がった!!

ラッキー!

 

けど、うち1台は変わらず。。。

とりあえずAWSサポートに連絡してみると、その子はまだメンテナンス対象になってるよ、反映されてないよと言われる。

→もう一回停止 → 開始やってみる。CPUの向上は見受けられない。。

再度連絡してみる

→まだメンテナンス対象だよー、と。

 

やってるのに。。

もしこのまま対象から外れなかったら3/1 強制再起動??

手動で反映されないなら強制でも反映されなくない??

したら何回も再起動されまくるでしょ??

って連絡してみたら現状は不明ときた。

 

ってことでもうt2インスタンスに入れ替えを行なった。

というお話。

 

いつかはt1 → t2にしといた方がよかったので良いタイミングではあったが、

たまたま社内用で助かった。

 

反省点

・忙しさを理由にギリギリまで放置してた

・もっと早くやってれば計画性を持って入れ替えを行えた

・社内AWS管理が個人依存になっている

 

以上!

 

GitLab CI AWS Elastic Beanstalkとの連携

GitLab CiからAWS Elastic Beanstalk へ更新をかけてみた。

 

ソース直下に

.elasticbeanstalk

フォルダを追加し、config.ymlを作成

内容は公式ドキュメント参照

https://docs.aws.amazon.com/ja_jp/elasticbeanstalk/latest/dg/environment-configuration-methods-before.html

 

続いて、GitLabCIからAWSにアクセスできるように、ソース直下に

.eb-config.sh

ファイルを追加

内容は

--

#!/usr/bin/env bash
set -x
set -e

{
AWS_CONFIG_FILE=~/.aws/config

mkdir ~/.aws
touch $AWS_CONFIG_FILE
chmod 600 $AWS_CONFIG_FILE

echo "[profile bw_package]" >> $AWS_CONFIG_FILE
echo "aws_access_key_id=${AWS_ACCESS_KEY_ID}" >> $AWS_CONFIG_FILE
echo "aws_secret_access_key=${AWS_SECRET_ACCESS_KEY}" >> $AWS_CONFIG_FILE
} &> /dev/null

--

こんな感じで、GitLab CIの環境変数にIAMのアクセスキーとシークレットアクセスキーを設定しておく。

 

後は.gitlab-ci.ymlの設定

今回は下記のような感じにしてみている。

-- 

stages:
- test
- deploy

test:
image: node:latest
stage: test
script:
- npm install
 - npm run build

deploy_aws:
stage: deploy
image: python:3.6-stretch
before_script:
- pip install awsebcli --upgrade --user
- git checkout master
- chmod +x .eb-config.sh
- ./.eb-config.sh
- export PATH=~/.local/bin:$PATH
- eb --version
script:
- eb deploy

--

 

後は便利なところとして、.ebextensions

を同じくソース直下にフォルダ作成して、色々設定してあげるとenv設定とか、ロードバランサー設定とか、様々な設定系が管理できる。

万が一アプリケーション削除などを行ってしまっても、時間経過以外は問題がなくなる。

 

次はLambdaへの試してみた感じを書きます!

 

※様々な記事を参考にさせていただき、ここにたどり着きました。

GitLab CI 触ってみた

最近弊社ではソース管理にGitLabを使い始めた。

折角なので、GitLab CIを使ってみた。

まだまだ初心者中の初心者なので、ご指摘等ございましたらぜひお願いします。

 

やってみたのは下記内容

・サーバにGitLab Runnerを仕込み単純にGitから最新ソースを取得する

・Doker imageからAWS Elastic Beanstalkに更新をかける

・Doker imageからAWS S3経由でLambdaに更新をかける

 

・サーバにGitLab Runnerを仕込み単純にGitから最新ソースを取得する

CentOSにて実行

curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.rpm.sh | sudo bash
yum install -y gitlab-runner

でGitLab runnerを最新ソースを取得したいサーバにinstall

gitlab-runner register

で、いくつか質問されるので、順番に回答する

 

Please enter the gitlab-ci coordinator URL (e.g. https://gitlab.com/)

→GitLabのURL

Please enter the gitlab-ci token for this runner:

→GitLab画面

プロジェクト → CI/CD → Runner

画面に記載されているTokenを入力

Please enter the gitlab-ci description for this runner:

[ip-172-31-43-84.ap-northeast-1.compute.internal]:

→なんか、一意の判断

Please enter the gitlab-ci tags for this runner (comma separated):

→tagが必要であれば入れる

Please enter the executor: ssh, docker+machine, kubernetes, docker, docker-ssh, parallels, shell, virtualbox, docker-ssh+machine

→種類を入力、今回はshellで作成

 

ps aux | grep gitlab
→このコマンドで、GitLab CIがどのユーザで実行されるかを確認する

今回はrootで強制的に実行したかったので、

gitlab-runner uninstall
gitlab-runner install -user root
gitlab-runner restart

の3つを実行し、再度ユーザ確認すると、rootに変わっている

 

SSHログイン時に実行するコマンドを定義

yum install expect

→installを行う
vi ~/.bash_profile

→でファイル編集

記載内容

eval `ssh-agent`

# 秘密鍵ファイル
KEY_FILENAME='id_rsa'
# パスフレーズ
PASSPHRASE='password'

expect -c "
set timeout -1
spawn ssh-add $HOME/.ssh/$KEY_FILENAME
expect {
\"Enter passphrase for\" {
send \"$PASSPHRASE\r\"
}
}
expect {
\"denied\" { exit 1 }
eof { exit 0 }
}
"

 

で、該当プロジェクトの直下に

.gitlab-ci.yml

を作成

—pullの場合—
stages:
- deploy

deploy:
stage: deploy
script:
- id
- ssh-add -l
- ssh -vT git@gitlab.com
- cd /var/www/html/

git pull origin master:master
only:
- master
tags:
- tags_name

 

で、とりあえずmaster Push時にだけ反応するように設定

developだけであればdevelopに変更すればOK

次回は
・Doker imageからAWS Elastic Beanstalkに更新をかける
・Doker imageからAWS S3経由でLambdaに更新をかける

を書きます

 

Elastic Beanstalk触ってみた感想

元々はEC2などは自前で立てて、開発や本番運用を行なっていた。

今回自社のパッケージを作成することになり、ElasticBeanstalkで構築することとした。

感想としては

・作成は全て勝手にやってくれるので、簡単

・環境をスワップできるので、stg prodみたいな環境があれば便利

・RDSは別で立てたほうが良さそう(アプリケーション、環境を削除してしまった場合データベースまで削除されてしまう、リスク排除のため)

・.ebextensions にconfigファイル追加していけば eb create コマンドだけで環境が作れる

・今回言語はnodejsなので、ローカルから eb deploy コマンドやるだけでnpm installとかは勝手にやってくれる

・pemキー発行しなければコンソールに入れない、不要なリスク排除

 

思いついたら追記

 

ただ、過去に全て自前で構築していじいじしていた経験は割と生きてる感じがする。

知ってると知っていない、の差だと思うが。

 

これならサーバ依存というのはなく、簡単にインスタンス入れ替えも可能だなー。

2019年

2019年

あけましておめでとうございます!!

 

このブログも中々更新できていませんが、本年はもう少し頻度と詳細度をあげて更新していきたいと思ってます。

 

今年もよろしくお願いします。