[2017夏版] AWS Start-up ゼミ参考資料リンク集をマークダウンに起こしました

TL;DR

こんにちは。AWSリハビリ中のnntsuguです。

[AWS Start-up ゼミ] よくある課題を一気に解説!〜御社の技術レベルがアップする 2017 夏期講習〜

先日参加させていただいたAWS Stat-upゼミ、講師のSA塚田さんの資料がとても良かった。
AWS上でサービスを構築運用する上での勘所がユースケースベースで整理されていて、モヤモヤしていた部分がかなりスッキリししました。

資料内にある参考資料や動画へのLink、とても勉強になるのですが、

  • PDFやSlideShareだとスマホから参照しづらい
  • 未読管理をしやすくするため

マークアップに起こしました。

毎朝ジムで走りながら参考資料の動画を見て聞いています。とても捗ります。

参考資料は主にBlack Beltの資料&動画アーカイブ、AWS Summit/Dev Dayの資料で構成されています。

ユーザ動向を分析したい

CI/CDをちゃんとしたい

コンテナを使いたい

運用監視ちゃんとしたい

システム負荷下げたい

(モバイルアプリの)Growth Hackしたい

コスト下げたい

  • AWS Black Belt Online Seminar資料&動画

    • クラウドのためのアーキテクチャ設計-ベストプラクティス-(資料|動画)
    • Auto Scaling (資料 | 動画)
    • Amazon EC2 Spot Instances (資料 | 動画)
    • サーバーレスによるアーキテクチャパターンのご紹介 (資料 | 動画)
  • AWS Summit/Dev Day講演資料 (2016 | 2017)
    • AWS のコスト最適化入門 (2017)(資料 | 動画)
    • [インティメート・マージャー様] AWS Summit 2017 講演資料 Amazon ECS と SpotFleet を活用した低コストでスケーラブルなジョ
      ブワーカーシステム(資料 | 動画)
    • AWS Well-Architected フレームワークによるクラウド ベスト プラク
      ティス (2017) (資料 | 動画)

その他

IPOとBuy Out、デューデリジェンス

続きを読む

【AWS】ELB+Gitlabの構築・設定(Google認証付き)

目的

AWSでGitlabを構築するにあたり、ELBでHTTPSを受け付け、後段EC2のGitlabサーバにて処理。
それを実現するためのGitlab設定方法をまとめる。
併せて、Gitlabでoogle認証を行う場合の設定も記載。

全体概要はこんな感じ

  • ELBには「https://xxx」で通常443ポート開放
  • https://xxx/gitlab/」でアクセスした場合はGitlabサーバに「http://xxx/gitlab」で送る。
  • 他に「https://xxx/app1/」とした場合は別のサーバへ振り分けるイメージ

スクリーンショット 2017-08-06 16.51.02.png

やらないこと

  • ELB、EC2などのAWSの設定
  • 公式に載っているGitlabのインストール手順
  • google認証を行うためのgoogle側の設定

前提

Gitlabのバージョン:GitLab Community Edition 9.3.6
標準のgitlabのインストールを実行済み
公式インストール手順(CentOS6)
※AWSLinuxでも同様

gitlabへSSH通信は行わない。PushなどはHTTPSでの認証とする。

1. ELBとGitlabの連携

1-1. gitlab.rbの編集

==[ELBの連携まで]==
#cd /etc/gitlab/gitlab.rb
#diff gitlab.rb gitlab.rb.org

13,14c13
< external_url 'https://xxx/gitlab'
---
> external_url 'http://xxx'
807c806
< nginx['listen_port'] = 80
---
> # nginx['listen_port'] = nil
811c810
< nginx['listen_https'] = false #https通信の無効化
---
> # nginx['listen_https'] = nil
817c816
<  nginx['proxy_set_headers'] = {
---
> # nginx['proxy_set_headers'] = {
821c820
<   "X-Forwarded-Proto" => "https",
---
> #  "X-Forwarded-Proto" => "https",
825c824
<  }
---
> # }

1-2. 再起動

gitlab-ctl reconfigure
gitlab-ctl start

1-3. ELB連携のポイント

gitlab.rbのみ編集し、reconfigureで反映するため一番きれいな方法だと思います。
直接nginx.conf等修正するとreconfigure時に上書きされるので。

ブラウザからの画面表示(リンクやPOSTのパス)はHTTPSにする必要がありつつ、
gitlabサーバ自体をHTTPで処理させるのが面倒でした。

2. GitlabでGoogle認証を設定する場合

2-1. gitlab.rbの編集

==[GoogleAuthまで]==
#cd /etc/gitlab/gitlab.rb
#diff gitlab.rb gitlab.rb.org

221c220
< gitlab_rails['omniauth_enabled'] = true
---
> # gitlab_rails['omniauth_enabled'] = false
223d221
< gitlab_rails['omniauth_allow_single_sign_on'] = ['google_oauth2']
230,239c228,235
< gitlab_rails['omniauth_external_providers'] = ['google_oauth2']
< gitlab_rails['omniauth_providers'] = [
<   {
<     "name" => "google_oauth2",
<     "app_id" => "各自のapp-id",
<     "app_secret" => "各自のシークレット",
<     "args" => { "access_type" => "offline", "approval_prompt" => "",
<     "hd" =>  "許容ドメイン(hoge.com)" }
<   }
< ]
---
> # gitlab_rails['omniauth_providers'] = [
> #   {
> #     "name" => "google_oauth2",
> #     "app_id" => "YOUR APP ID",
> #     "app_secret" => "YOUR APP SECRET",
> #     "args" => { "access_type" => "offline", "approval_prompt" => "" }
> #   }
> # ]

2-2. 再起動

gitlab-ctl reconfigure
gitlab-ctl start

2-3. google認証のポイント

特定のドメインのみ許可したい場合は、hdオプションを利用することです。
google認証側で特定ドメインのみ対応してくれます。
特定ドメインが不要であればオプション外せば大丈夫なはずです。

おまけ

Gitlab, Redmine, Jenkinsなど利用しますが、どれも/配下やHttps->Httpの切り替え方法が異なるので、
いちいち調べるのが面倒。なんかいい方法ないかなぁ。

参考

似たような対応として下記の記事を参考にさせて頂きましたが、Reconfigureをすると、
設定が変更されてしまうためメンテナンスする際に面倒なため、/etc/gitlab/gitlab.rbのみで対応できる方法を書きました。
http://qiita.com/morozumi_h/items/128d3254fd2eb4671966

続きを読む

[localstack] ローカル環境にAWSサービスのモックを作り開発をする

AtlassianのLocalStackを使ってみてなんとなく理解するまでのお話 の通りなのですが本家のgithubを見るとこんな感じになってたので現行どうするかを備忘録としてメモします。

 
 スクリーンショット 2017-08-02 16.33.49.png

Atrasian/localstack -> localstack/localstack に変更になってます。

前提

  • Mac(macOS Sierra)
  • Docker Commnity Edition (Version: 7.06.0-ce-mac19)

  • dockerコマンドがコンソール上で実行可能であること

  • AWS CLIの設定が完了していること

イメージの準備

pull
docker pull localstack/localstack

起動

run
docker run -it -p 4567-4582:4567-4582 -p 8080:8080 localstack/localstack

起動させたらコンソールは放置

確認

ブラウザを立ち上げ

http://localhost:8080/

へアクセス

こんな画面が立ち上がってれば安心して大丈夫

エンドポイント

githubから転記してきましたが、変わってる可能性があるので必ず本家で確認して下さい。
https://github.com/localstack/localstack

サービス名 エンドポイントURL
API Gateway http://localhost:4567
Kinesis http://localhost:4568
DynamoDB http://localhost:4569
DynamoDB Streams http://localhost:4570
Elasticsearch http://localhost:4571
S3 http://localhost:4572
Firehose http://localhost:4573
Lambda http://localhost:4574
SNS http://localhost:4575
SQS http://localhost:4576
Redshift http://localhost:4577
ES (Elasticsearch Service) http://localhost:4578
SES http://localhost:4579
Route53 http://localhost:4580
CloudFormation http://localhost:4581
CloudWatch http://localhost:4582

AWS CLI

CLIコマンドを発行する場合
--endpoint-url で上記のエンドポイントを指定して使用します。
デフォルトのリージョンをconfigで指定していない場合、コマンドで--region を指定する必要があります。

サンプル(SQS)
aws sqs create-queue 
        --queue-name 'SAMPLE' 
        --region ap-northeast-1 
        --endpoint-url http://localhost:4576 
        --profile $myProfile

SDK(nodejs)

サンプル
'use strict';

const AWS = require('aws-sdk');
const endPoint = new AWS.Endpoint('http://localhost:4578');
const region = 'ap-northeast-1';
const s3 = new AWS.S3({ endpoint: endPoint, region: region });

基本的にはエンドポイントに上記URLを指定するだけでAPIをリクエストすることが出来ます。
ElasticSerchはすでに使用可能な状態のElasticSerchが動いています。ESの方はドメイン作成とかのAPI用のモックって感じですね。
開発の際に特にデータ系は何かレスポンスが必要なので地味に使えるツールですね

続きを読む

AWSでWOWZAサーバ構築に使用するAMI

探したのでメモ

Version 4.6.0* released 04/18/2017

Region AMI ID
Asia Pacific (Mumbai) ami-ccc9baa3
EU (London) ami-61c5d105
EU (Ireland) ami-34f1f552
Asia Pacific (Seoul) ami-811fcdef
Asia Pacific (Tokyo) ami-a6a689c1
South America (Sao Paulo) ami-6ddbb901
Canada (Central) ami-82d569e6
Asia Pacific (Singapore) ami-de3a83bd
Asia Pacific (Sydney) ami-8a343de9
EU (Frankfurt) ami-c38d50ac
US East (N. Virginia) ami-4cd0405a
US East (Ohio) ami-9c9fbbf9
US West (N. California) ami-6695b006
US West (Oregon) ami-18fd6078

Version 4.5.0 released 06/29/2016

Region AMI ID
Asia Pacific (Mumbai) ami-6d94fe02
EU (Ireland) ami-91960ce2
Asia Pacific (Singapore) ami-8025f7e3
Asia Pacific (Sydney) ami-c391b9a0
Asia Pacific (Seoul) ami-6577bc0b
EU (Frankfurt) ami-62dc370d
Asia Pacific (Tokyo) ami-8e0ffeef
US East (N. Virginia) ami-969f56fb
US East (Ohio) ami-75356e10
US West (N. California) ami-901c5bf0
South America (Sao Paulo) ami-3952c755
US West (Oregon) ami-8b3ff9eb

Version 4.4.1 released 03/18/2016

Region AMI ID
EU (Ireland) ami-5995102a
Asia Pacific (Singapore) ami-6039f203
Asia Pacific (Sydney) ami-8f0b2bec
Asia Pacific (Seoul) ami-08935a66
EU (Frankfurt) ami-0515f26a
Asia Pacific (Tokyo) ami-a0aaa1ce
US East (N. Virginia) ami-68f7f402
US West (N. California) ami-6a5d2f0a
South America (Sao Paulo) ami-6cd95500
US West (Oregon) ami-cb5db4ab

Version 4.3.0 released 11/05/2015

Region AMI ID
EU (Ireland) ami-c0a77eb3
Asia Pacific (Singapore) ami-4566a126
Asia Pacific (Sydney) ami-51520c32
Asia Pacific (Seoul) ami-269d5348
EU (Frankfurt) ami-b52c3fd9
Asia Pacific (Tokyo) ami-ee183f80
US East (N. Virginia) ami-ae473bc4
US West (N. California) ami-a65639c6
South America (Sao Paulo) ami-b148f3dd
US West (Oregon) ami-86e7f0e7

Version 4.2 released 08/10/2015

Region AMI ID
EU (Ireland) ami-d03f74a7
Asia Pacific (Singapore) ami-7c3b392e
Asia Pacific (Sydney) ami-23c48219
EU (Frankfurt) ami-c81b1ed5
Asia Pacific (Tokyo) ami-0652e506
US East (N. Virginia) ami-1370ad78
US West (N. California) ami-1fb4495b
South America (Sao Paulo) ami-9f77f882
US West (Oregon) ami-b1686481

参考:Wowza Streaming Engine 4: Pro Edition (HVM)

続きを読む

Amazon Linux上にインストールしたGitLab CEにLet’s Encryptを適用する方法

対象環境

GitLab Community Edition 9.0.4
certbot 0.13.0(Let’s EncryptのCLIクライアント)

原理

Let’s Encryptの「webroot」モードを利用する。
webrootモードはサーバに .well-known ディレクトリが置かれていることを認証基準としてSSL証明書を発行する。
GitLabのログインを回避して .well-known をLet’s Encryptに発見させ、SSL証明書を発行するのが本記事の目的である。

手順

※ GitLabはインストールが完了しており、既に稼働しているものとする。

1. GitLabが利用しているNginxの設定を変更する

GitLabのログインを回避して .well-known の存在を確認させるためにNginxのリダイレクト設定を変更する。
まずは設定ファイルを新規作成。

$ sudo vim /etc/gitlab/custom_gitlab_server_config.conf
/etc/gitlab/custom_gitlab_server_config.conf
location ^~ /.well-known {
    alias /var/letsencrypt/.well-known;
}

その後、設定ファイルを適用。

$ sudo vim /etc/gitlab/gitlab.rb
/etc/gitlab/gitlab.rb
nginx['custom_gitlab_server_config'] = "include /etc/gitlab/custom_gitlab_server_config.conf;"

最後に、Let’s Encryptに発見させる用のディレクトリを作成しておく。
.well-known は作成しなくてよい。

$ sudo mkdir /var/letsencrypt

2. GitLabに設定を適用して再起動

$ sudo mkdir /var/letsencrypt

3. Let’s Encryptをインストール

絶対に最後の --debug を忘れないように。
Amazon Linux限定の手法なので他のOSの場合は不要。

$ sudo mkdir /usr/local/letsencrypt
$ sudo chown `whoami` /usr/local/letsencrypt
$ cd /usr/local/letsencrypt
$ git clone https://github.com/letsencrypt/letsencrypt .
$ sudo ./letsencrypt-auto --debug

4. SSL証明書を取得

[gitlab.example.com] の部分はGitLabに適用しているドメインを指定する。

$ sudo ./letsencrypt-auto certonly --webroot --webroot-path /var/letsencrypt -d [gitlab.example.com]

エラーが出た場合

エラーの場合はこんな表示が出る。

IMPORTANT NOTES:
 - The following errors were reported by the server:

   Domain: gitlab.example.com
   Type:   unauthorized
   Detail: Invalid response from

Typeが unauthorized の場合

  • ログインが回避できていないので、1の手順が正しく完了しているか確認する

Typeが unconnected の場合

  • AWSのセキュリティグループを確認し、80番と443番のポートを開ける
  • 勢い余って /etc/gitlab/gitlab.rbexternal_url をhttpsにしていないか確認する(証明書取得まで禁止!)

5. SSL証明書が自動更新されるよう設定

$ sudo crontab -u root -e
00 05 01 * * /path/to/letsencrypt/letsencrypt-auto renew --force-renew && gitlab-ctl restart

5. SSL証明書をGitLabに適用

external_url をHTTPSに変更する。
[gitlab.example.com] の部分はGitLabに適用しているドメインを指定する。

redirect_http_to_https をtrueにしておくと、HTTPでアクセスされてもHTTPSにリダイレクトされる。
証明書の再発行の際はHTTPによる .well-known の確認が走らないので、HTTP接続を潰してしまってよい。
同じくAWSのセキュリティグループレベルでも80番ポートを潰してしまってよい。

$ sudo vim /etc/gitlab/gitlab.rb
/etc/gitlab/gitlab.rb
nginx['external_url']                = "https://[gitlab.example.com]"
nginx['redirect_http_to_https']      = true
nginx['ssl_certificate']             = "/etc/letsencrypt/live/[gitlab.example.com]/fullchain.pem"
nginx['ssl_certificate_key']         = "/etc/letsencrypt/live/[gitlab.example.com]/privkey.pem"

6. GitLabを再起動

$ sudo gitlab-ctl reconfigure

参考文献

GitLab Omnibus package の SSL 証明書を Let’s Encrypt で取得する
http://qiita.com/yuuAn/items/09a434d3f6cffa31101e

アクセス制限のかかったGitLabをLet’s Encryptをつかってhttps化する
https://gist.github.com/mamemomonga/a36a194f8a80ce5fa49bf950e092c604

続きを読む