投稿者「kojima」のアーカイブ

ランサーズ リリースシステム 〜 Jenkins + Fabrics

kojima|2015年01月09日
AWS

こんにちわ。エンジニアの こじま です。

今回は,ランサーズのリリースシステムの紹介をします。

弊社プラットフォームは,1日に多い時は10回以上のコードのリリースを実施します。

ユーザ様によりよいプラットフォームを提供すべく日々,リリースをし改善を実施しています。

 

以前は,特定のエンジニアしかリリースができず,

都度サーバにログインしてオペレーションを実施していました。

現在では,非エンジニアでも,WEB UI からワンクリックで,安全にリリースを実施することができます。

以下のような WEB UI で実施しています。

リリース

 

リリースシステムは,Jenkins・Redmine・Fabrics と連携してリリースを実現しています。

以下のような構成で実現しています。

リリースシステム構成
上記の構成の詳細を説明をします。

Jenkins によって,Fabrics がキックされリリースを実施します。

また,リリースが完了すると,Redmine のチケットがクローズされる仕組みになっています。

Jenkins は Ruby で jenkins_api_client を利用して実現しています。

以下のように Job をビルドします。

require 'jenkins_api_client'

client = JenkinsApi::Client.new(conf)
client.job.build(job_name, params)

 

また,Redmine も API 経由でリクエストすればチケットを簡単にクローズできます。

(API の解放が必要です)

curl -s -H 'Accept: application/json' -H 'Content-type: application/json' -X PUT -d '{"issue":{"status_id":"<変えたいステータスの ID を指定>","done_ratio":"100"}}' "http://<Redmine のアドレスを指定>/issues/<チケット ID を指定>.json?format=json&key=<トークンを設定>"

 

このリリースシステムによって,開発が効率化され

より安全に早く,ユーザ様へよりよいものを提供できるようになりました。

このようにしてランサーズでは,

ユーザ様に快適なプラットフォームを提供すべく日々努力をしております。

AWS API とサーバ管理

kojima|2015年01月02日
AWS

あけましておめでとうございます。エンジニアの こじま です。

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

 

今回は,ランサーズの開発・運用を楽にするための

サーバ管理システムのご紹介をします。

弊社プラットフォームでは AWS を利用しています。

 

AWS には AWS マネジメントコンソールが提供されますが,

ランサーズでは,自社製のシステムでサーバ情報を一元管理し

各ツールと連携し開発・運用効率を図っています。

サーバ情報は以下のようなビューを持ち一元管理をしています。

サーバ一覧

 

また,不必要にサーバにログインしなくて済むように

ウェブサーバなどのログの表示も WEB UI から可能としています。

アクセスログ

 

今回は,サーバ管理を実現するために利用した

AWS の Ruby ライブラリによる API 取得についてご紹介します。

あらかじめ aws-sdk のインストールと

Endpoint, Access Key, Secret Key を準備ください。

EC2 インスタンスの Private IPAddress の一覧を表示するサンプルを記述します。

#!/bin/env ruby
require 'aws-sdk'

ec2 = AWS::EC2.new(
:ec2_endpoint = 'ec2.ap-????????.amazonaws.com',
:access_key_id = '??????????',
:secret_access_key = '??????????'
)

p ec2.instances.map{|m| m.private_ip_address}

 

実行結果

$ ./aws_sdk_sample1.rb
["10.0.1.11", "10.0.101.11"]

 

とても簡単に AWS の情報を取得できます。
このようにしてランサーズでは,
ユーザ様に快適なプラットフォームを提供すべく日々努力をしております。

Ruby Mechanize によるサービス監視のすすめ

kojima|2014年12月26日
DevOps

こんにちわ。エンジニアの こじま です。

今回は,ランサーズのサービス品質を支える

サービス監視システムのご紹介をします。

弊社プラットフォームは,複数の監視システムを導入して運用を実施しています。

システム 用途
(自社製)サービス監視システム サービス稼働チェック
NewRelic パフォーマンス計測
Nagios 死活・リソース・ミドルウェア監視
Munin キャパシティプランニング

 

自社製のサービス監視システムには2つの機能があります。

1)弊社プラットフォームのログインをはじめ各ページの表示確認
2)弊社プラットフォームの各ページのレスポンス速度の異常検知

以下のようにグラフィカルなビューを持ち,一目でサービスの異常を検知できます。

サービス監視 WEB UI

今回のサービス監視開発に至った経緯は

ユーザ様の視点に立った,サービスの異常を検知するためです。

サーバの CPU 利用率やディスク容量を監視すれば,システムの異常は検知できますが,

ユーザ様に,意図した仕様のサービスが,提供ができていることは把握できません。

当サービス監視は Ruby の Mechanize によって実現しています。

以下のスクリプトは特定のページにアクセスしてページタイトルをチェックするものです

数行のコードで簡単に実装できます。(過剰なスクレイピングは運営者様にご迷惑をおかけするためご遠慮ください)

#!/usr/bin/env ruby
require 'mechanize'
-
client = Mechanize.new
page   = client.get('http://<監視対象を設定してください>')
-
puts 'OK' if page.title =~ /<ページタイトルを設定ください>/

 

他にもいろいろできるのでご紹介させていただきます。

 

Mechanize でリンクを取得

page.links

 

Mechanize でフォームを取得

page.forms

 

Mechanize で特定要素の複数クラス名を指定して内部要素のテキストを取得

page.at('div[@class="<class名1> <class名2>"]').inner_text

 

Mechanize で特定要素の h1 のリンクを取得

page.search('div.<class 名>').map { |elm| elm.at('h1').at('a')['href'] }

 

Mechanize を利用すれば効率よく情報収集が出来そうですね。

このようにしてランサーズでは,

ユーザ様に快適なプラットフォームを提供すべく日々努力をしております。

AWS

AWS セキュリティ対策 〜 操作履歴を CloudTrail で残してみた

kojima|2014年10月21日
AWS

こんにちわ。こじまです。

ランサーズでは,AWS を利用してシステムを運用しています。

コンプライアンスの監査,トラブルシューティング,そして,セキュリティ分析を実施するために

AWS の操作履歴を残すことは必須です。

 

今日は,AWS 操作履歴を残すために,CloudTrail の導入についてご紹介させていただきます。

マネジメントコンソール・コマンドラインツール・SDK による API 呼び出しが履歴対象となります。

 

CloudTrail の費用は Amazon S3 と Amazon SNS を利用し

およそ月額 4 USD未満です。(http://aws.amazon.com/jp/cloudtrail/pricing/)

 

では,早速,導入の手順を説明します。

 

CloudTrail 基本設定

まず,AWS にログインし CloudTrail を選択します。

aws

Get Started を選択します。

Welcome to AWS CloudTrail

 

S3 backet 名を入力し Subscribe ボタンを押下してください。

Turn on CloudTrail

 

以上でロギングが開始されます。

Turn on CloudTrail

 

以下のように S3 にファイルが作成されます。

S3

以下のような結果を確認することができます。ログインのログ例です。

スクリーンショット 2014-10-21 19.41.01

 

 

CloudTrail でメール送信

更に,変更をメールで通知するようにしてみます。

SNS notification for every log file delivery? を Yes にして SNS topic (new) を入力します。

Update CloudTrail

メール宛先設定のため SNS の設定を変更します。

aws2

 

SNS で Protocol を Email 選択し,Endpoint に E-mail アドレスを入力します。

Create Subscription

 

ロギングされると,以下のようなメールが送出されます。

AWS Notifications

以上で,完了となります。

EC2 SSH サーバ ごった煮 〜 Google Authenticator + ChatWork 通知 入り

kojima|2014年08月19日
AWS

こんにちわ。

Lancers のバックエンドの開発と運用担当の こじま です。

 

みなさん,サーバをどのようにリモートしていますか?

直接,ターゲットのサーバへログインせず

SSH サーバを経由してリモートすることが多いと思います。

SSH サーバを構築することで

不要なリソース解放を防ぎ安全にインターネット経由でリモートできます。

 

今回は,そんな SSH サーバの構築例を紹介します。

AWS EC2 環境下で以下のような機能を盛り込みます。
※ Amazon Linux AMI 2014.03.2 (HVM) – ami-29dc9228 を利用

  1. ワンタイムパスワード認証
  2. 自動ログアウト
  3. アカウントロック
  4. コマンド実行履歴保存
  5. SSH ログイン通知(ChatWork株式会社様 chatwork を利用)

 

さっそく,サーバに SSH ログインして,構築を進めましょう。

 

まず,RPM パッケージのアップデート・インストールをします。

$ sudo sed -i ‘s/enabled=0/enabled=1/’ /etc/yum.repos.d/epel.repo
$ sudo yum -y update
$ sudo yum install -y git subversion screen emacs vim lv lynx sl curl zsh banner bind-utils lsof cowsay strace tcpdump mercurial make gcc pam-devel expect bash-completion

 

ログインメッセージをかえます。誤ったサーバログインを防ぐ事ができます。

/etc/motd を更新しても再起動時に上書きされるため

/etc/update-motd.d/30-banner を更新します。

バナーは “ascii banner generator” をキーワードに

ジェネレータツールサイトを検索して作成ください。

$ sudo vi /etc/update-motd.d/30-banner

#!/bin/sh
version=$(rpm -q --qf '%{version}'system-release)
cat << EOF
  _
 | |     __ _ _ __   ___ ___ _ __ ___
 | |    / _\` | '_ \ / __/ _ \\ '__/ __|
 | |___| (_| | | | | (_|  __/ |  \\__ \\
 \_____/\\__/_|_| |_|\\___\\___|_|  |___/
 
https://aws.amazon.com/amazon-linux-ami/$version-release-notes/
EOF

 

オペレーションミスを起こさないよう

プロンプトも分かりやすいものに変更します。

$ sudo vi /etc/profile.d/prompt.sh
PS1='(\[\033[31m\]PRD\[\033[m\])\[\033[36m\]\u\[\033[m\]@\[\033[32m\]\h:\[\033[33;1m\]\w\[\033[m\]\$ ‘

 

ランサーズではこんな感じのプロンプトです。

prompt

  • 本番環境
    • PRD
  • ステージング環境
    • STG
  • テスト環境
    • TEST
  • 社内開発環境
    • DEV

 

自動ログアウトするようにします。

$ sudo vi /etc/profile.d/tmout.sh

export TMOUT=3600

 

SSH ログインを chatwork に通知するようにします。

$ sudo vi /etc/ssh/sshrc

/usr/bin/curl --connect-timeout 5 -s -X POST -H "X-ChatWorkToken:<TOKEN>"-d "body=[info][title]$HOSTNAME - Login[/title]$USER has logined.[/info]""https://api.chatwork.com/v1/rooms/<room>/messages"> /dev/null

 

こんな感じの通知がきます。

chatwork

 

ワンタイムパスワード認証の設定します。

$ wget https://google-authenticator.googlecode.com/files/libpam-google-authenticator-1.0-source.tar.bz2

$ tar -jxvf libpam-google-authenticator-1.0-source.tar.bz2
$ cd libpam-google-authenticator-1.0-source && make
$ sudo make install
$ sudo echo'auth required pam_google_authenticator.so'>> /etc/pam.d/sshd
 
$ sudo vi /etc/ssh/sshd_config
- #ChallengeResponseAuthentication yes
- ChallengeResponseAuthentication no
 
+ ChallengeResponseAuthentication yes
+ #ChallengeResponseAuthentication no
 
+ Port ????? <--- 1024 以降の番号にする。ポート変更時は AWS セキュリティポリシーの変更が必要です。
+ Protocol 2
+ PermitRootLogin no
+ Banner none
+ PasswordAuthentication no

 

アカウントロックの設定をします。

5回パスワードを間違えると180秒間アカウントロックされます。安心ですね

$ which pam_tally2

/usr/sbin/pam_tally2 <--- pam_tally2 が存在することを確認
$ sudo vi /etc/pam.d/sshd
+ auth required pam_tally2.so deny=5 onerr=fail unlock_time=180
 
ロック時の解除は以下の通り
$ sudo pam_tally2 -u <user-id> --reset

 

コマンド実行履歴を保存するよう設定します。

$ sudo yum install -y psacct
$ sudo chkconfig psacct on

$ sudo chkconfig –list psacct
psacct          0:off   1:off   2:on    3:on    4:on    5:on    6:off

$ sudo /etc/init.d/psacct start
プロセスアカウントを開始中:                                [  OK  ]

 

以下のようにユーザを限定して履歴参照やアカウント別利用統計も参照可能です。

$ sudo lastcomm --user <user-id>

sl                      <user-id> pts/0      0.00 secs Thu Aug 14 08:53
ls                      <user-id> pts/0      0.00 secs Thu Aug 14 08:53
bash               F    <user-id> pts/0      0.00 secs Thu Aug 14 08:53
id                      <user-id> pts/0      0.00 secs Thu Aug 14 08:53
$ sudo sa -m
root                                  610  275703.50re       0.08cp    22134k
<user-id1>                             64       2.41re       0.00cp    28133k
<user-id2>                             32       0.12re       0.00cp    28133k
<user-id2>                             32       0.10re       0.00cp    27304k
sshd                                    7       3.10re       0.00cp    19824k
postfix                                 6 2336935.38re       0.00cp    22197k

 

アカウントにワンタイムパスワードを設定します。

$ sudo passwd <user-id>

$ sudo su - <user-id>
$ google-authenticator
google-authenticator
Do you want authentication tokens to be time-based (y/n) y
https://www.google.com/chart?chs=200x200&chld=M|0&cht=qr&chl=otpauth://totp/user-id@hostname%3Fsecret%
Your newsecret key is: ??????
Your verification code is ??????
Your emergency scratch codes are:
  ??????
  ??????
  ??????
  ??????
 ??????
Do you want me to update your "/user-id/.google_authenticator"file (y/n) y
Do you want to disallow multiple uses of the same authentication
token? This restricts you to one login about every 30s, but it increases
your chances to notice oreven prevent man-in-the-middle attacks (y/n) y
By default, tokens are good for30 seconds andin order to compensate for
possible time-skew between the client andthe server, we allow an extra
token before andafter the current time. If you experience problems with poor
time synchronization, you can increase the window from its default
size of 1:30min to about 4min. Do you want to doso (y/n) y
If the computer that you are logging into isn't hardened against brute-force
login attempts, you can enable rate-limiting forthe authentication module.
By default, this limits attackers to no more than 3 login attempts every 30s.
Do you want to enable rate-limiting (y/n) y

 

今日はここまでです。以上で構築完了です 。

今回の構築で,安全にどこからでもリモートできるようになりました。

 

Lancers では,徹底したユーザ第一主義を行動指針の一つに掲げ

発注者様、受注者様、運営メンバーを含めた三者にとっての

win-win-win を創り出すことを徹底的に第一に考えます。

見えにくい部分ではありますが,Lancers のバックエンドは

ユーザ第一主義に基づき,こうした小さな環境構築から

努力の積み重ね,日々,サービス品質の向上を目指しています。

 

以上,Lancers のバックエンドを支える,こじま からでした。

機会があればまた紹介させて頂きます!