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キー発行しなければコンソールに入れない、不要なリスク排除

 

思いついたら追記

 

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

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

 

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

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でいけた。

 

無駄に悩まされた!

API Blueprintを使ってみた

基本的受託開発時は設計書類は完全にExcelベースで作成していた。

そろそろExcelから脱却したいなと思い、API 設計書をAPI Blueprintを使って作成してみた。

 

 使い方としては特に問題はなさそう。

下記現在のURL

http://ec2-13-231-41-178.ap-northeast-1.compute.amazonaws.com/

※本件は受託案件ではなく、自社サービス向けのAPIなので公開してます。

 

コマンドから試しにAPIを叩くことも可能。

ただ、弊社は開発拠点がベトナムにあることから、設計書を翻訳、というプロセスが存在する。

そこの管理さえしっかりと行えれば、Excelからの脱却は可能そう。

GitLabとAWS Codecommitの連携

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にもあがる