Briswell Tech Blog

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

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触ってみた感想

AWS

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

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

感想としては

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

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

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

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

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

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

 

思いついたら追記

 

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

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

 

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

2019年

2019年

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

 

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

 

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

GitLab master Push エラー解決

便利

最近弊社ではソース管理をGitLabに移行してまして。

ちょっと多く悩まされたのが、

"Please make sure you have the correct access rights"

この子。

 

アクセス権限確認してねって言ってるんだが、権限はしっかりある。

プロジェクトオーナーなので問題ないはず。

 

......

 

なんだろう。

 

...

 

とりあえず、protect リポジトリでmaster削除してみる

 

...

 

関係ない。

 

結果の解決策とりあえずKeyファイル作成し直し。

 

ssh-keygen -t rsa -C "GitLabのメアド" -b 4096

 

で、pub コピってGitLabに貼り付け

 

その後ローカルで

ssh-add ~/.ssh/id_rsa

 

ってやってmaster Pushでいけた。

 

無駄に悩まされた！

GitLabとAWS Codecommitの連携

AWS

GitLabでソース管理している物を、AWSのCodebuild + CodeDeploy + CodePipeline

でもろもろ自動化がしたかった。

 

GitLabをAWS上からは選べなかったので、GitLab -> Codecommit を自動連携するようにしてみた。

結構簡単で、

Codecommit、GitLabでプロジェクト作成、

AWS IAM ユーザ作成、Codecommit Fullアクセス権限を付与し、作成

 

IAMユーザ画面の認証情報タブ内、一番下の「AWS CodeCommit のHTTPS Git 認証情報」というところの生成ボタンを押してユーザ名、パスワードを取得する

 

GitLab、プロジェクト内設定 -> リポジトリから「Mirroring repositories」を選択

Push設定にして、パスワードを選択、ユーザ名入れるところなかったので、

https://"ユーザ名"@...

という形でセット

 

これでGitLabにPushしたソースは自動でCodeCommitにもあがる

 

AWS ELB スティッキーセッション

AWS

仮リリースしてたAPI サーバーを冗長化するために、セッション管理をどうしようかなと思った。

CakePHP3 で構築してたので、DB管理にしてもよかったが、AWS ELB置いといたのでスティッキーセッションというのを試してみた。

 

こんな簡単なの？ってほど設定は簡単で、

ターゲットグループの維持設定を有効化するだけ。

 

後はよしなにAWS君がやってくれる。

簡単。

AWS S3 + CloudFront + WAF

AWS

f:id:Toshi_bw:20181022111018p:plain

 

株式会社ブリスウェル、Toshiです。

 

とあるAWS上で稼働している業務システムで、写真の表示がとても遅いと大量の声があがってきたため、構成を変えてみた。

 

  •  変更前

AWS EC2 - EBS で、写真をひたすらEBSに置いていた。

EC2が複数構成なので、File ServerとしてEC2をmountしていた。

（ELB スティッキーセッション入れようかな。）

 

  • 変更後

EBS -> S3 に写真ファイルを移行

（既存の置き方がとてもよくなかったため、同時にファイルパス構成も変更）

S3コマンドでひたすら待つ。。。

もっと良い方法がきっとあったはず。一度キリと思い、そのまま実施。

 

EC2からアクセスするのはS3ではなく、CloudFrontに。

結果速度は3倍以上に向上。

S3やCloudFront URL直アクセスを禁止するために、簡易的にWAFのQuery stringを使用。

 

S3 mountと、goofysも試してみたけど、CloudFrontの方が全然早かった。

 

次回はEC2 - CloudFront - WAF - S3の設定、実際のスピード変化の値について載せます！ 

 

 

 

ブリスウェルでは一緒に働く仲間を募集しています https://www.briswell.com/career/
All Rights Reserved by Briswell Ltd