「おや…ELBのようすが…?」という時に確認すること

私の経験上、「ELBがおかしいぞ!AWSしっかりしろや!」と思ったら、よくよく調べると実装がダメなだけだったというパターンがよくあるのでまとめたい。

あ、ELBと言いながら厳密にはALBの話をメインにします。

CASE 1. 「バックエンドは生きてるはずなのにヘルスチェックが失敗する!」

つまり以下のような症状が出る状況

  1. ヘルスチェックが失敗する
  2. バックエンドに直接アクセスしたら普通にうまくいく
  3. バックエンドのアクセスログ見たら、ヘルスチェックに200を返している

というパターン。
「バックエンドは生きてるしヘルスチェックにも200を返してる!それなのに失敗扱いなんてELBの不具合だ!」と思いたくなる気持ちはわかるが、まずは落ち着いてヘルスチエックの成否の基準を見直そう。

ターゲットグループのヘルスチェック – Elastic Load Balancing

ターゲットが応答タイムアウト期間内に応答するのを待ちます。

つまりバックエンドが200を返していようが、タイムアウトしていたらヘルスチェック的には失敗なのだ。
とりあえずバックエンドのアクセスログから処理時間を確認してみよう。まさか処理時間を出力するようにログフォーマットを設定してないなんて言わないよな?

ちなみにステータスコード200というのも注意が必要で、みんな大好きApacheのドキュメントにこんな記載がある

mod_log_config – Apache HTTP サーバ バージョン 2.4

%s ステータス。内部でリダイレクトされたリクエストは、元々の リクエストのステータス — 最後のステータスは %>s

すこぶる分かりにくい文章だが、要するに
・ %s -> リダイレクトが発生した際に3XXのコードを出力する
・ %>s -> リダイレクトが発生した際に3XXのコードを出力せず、リダイレクト後の処理の結果のコードを出力する

というわけだ。そのため、「200を返してるし、CPU使用率も上がってないから大丈夫なはず」と思ってたら実はリダイレクトしまくってタイムアウトしてた、というパターンもある。
そして、筆者の記憶が確かならApacheではデフォルトで%>sが設定されている。

というわけでこの症状の場合は、ELBの不具合とヘルスチェックのタイムアウト、どちらの方がありえそうか考えて調査をはじめてみよう。

CASE 2. 「HTTPCode_ELB_5XX_Countメトリクスが出てる!」

「5XXはサーバサイドのエラー…ELBが5XXエラーを出しているということは…ELBの不具合や!」と思いたくなる気持ちはわかるが、まあ落ち着いてほしい。
私も過去に502 Bad Gatewayに悩まされ、AWSにも問い合わせたりしたが、結局のところバックエンドの実装がクソだったのが原因だった。
だから落ち着いてまずはこれを見てほしい。

Application Load Balancer のトラブルシューティング – Elastic Load Balancing

うん、分かりにくいな。
5XX系のエラーに絞って、頑張って解説してみよう。

HTTP 502: Bad Gateway

そもそも502 Bad Gatewayというもの自体が分かりにくい。
Wikipediaによると

不正なゲートウェイ。ゲートウェイ・プロキシサーバは不正な要求を受け取り、これを拒否した。

これで理解できる人間はほぼいないだろう。
502 Bad Gatewayについてはこちらのページの解説が分かりやすい。

502Bad Getewayの原因と意味について | ぷろめし|プログラミングよりも飯が好き

ELBに当てはめて考えるなら、「ELBからバックエンドにリクエストを投げたが、解せないレスポンスが帰ってきた」という状況である。
つまり、ELBがイかれている可能性もあるが、バックエンドがイかれたレスポンスを返したり途中でコネクションをブッチしている可能性もあるのだ。

つまり、502 Bad Gatewayが現れたらバックエンドからのレスポンスがどうなってるかを見直した方がいいだろう。

HTTP 503: Service Unavailable

一時的に使えないというやつ。
上記のドキュメントにはターゲットグループにインスタンスが無いという場合しか書いてないが、実は他にも503が発生する可能性はある。

ELBはトラフィック量に合わせて自動でスケールするが、あまりに急激にトラフィックが増加した場合にはスケールが間に合わなくなることがある。そういう場合にはELBの処理能力が足りなくなって503が発生することになる。
ほっといたらそのうちELBがスケールして解決するが、「一瞬たりとも落とせないんだ!」という時は予めPre-warmingを申し込んでおこう。

Elastic Load Balancing の暖気申請について | Developers.IO

見積もりがガバガバだと「ほんまにPre-warming必要か?」と突っ込まれることもあるので、真面目に見積もろう。

HTTP 504: Gateway Timeout

これは分かりやすい。
ELB -> バックエンドの通信がタイムアウトしたということである。
バックエンドの処理を見直すか、タイムアウト時間を伸ばすかの二択だが、基本的にはバックエンドの処理を見直す方が健全である。

色々調べたが、どう考えても実装に問題はない時は…

AWS側の問題という可能性もあるので、問い合わせよう。

続きを読む

コピペで使えるELBのアクセスログ解析による事象分析 (ShellScript, Athena)

アクセスログ解析

ELBのアクセスログの事象分析について、ShellScriptとAthenaを用いた実行例についてまとめます。

ShellScript

CLB

No.1 : レスポンスが正常に受け取れていないELBのレスポンスコード毎のカウント

$ awk '$10 == "-"' * | awk '{print $9}' | sort | uniq -c

No.2 : ELBのレスポンスコード毎の数集計

$ awk '{print $8}' *.log | sort | uniq -c

No.3 : 504のレコード一覧

$ awk '$8 == 504'

No.4 : 504がどのELBノードから多く出力されているか

$ grep ' 504 ' *.log | awk '{print $3}' | sed 's/:.*//' | sort | uniq -c

No.5 : バックエンドから正常に応答が受け取れていない時

$ awk '{if (! int($5) < 0) {print $0}}' * | egrep '2018-01-2[45]'

No.6 : target_processing_time の3つの統計値(最小値、最大値、平均)と -1 の値を取った回数を表示する

$ awk '{ print $4,$8,$9,$6 }' * | sort | sed -e 's/ /!!/' -e 's/ /!!/' | awk '{if(count[$1]==0) min[$1]=100; count[$1]+=1; if(max[$1]<$2&&$2!=-1) max[$1]=$2; if(min[$1]>$2&&$2!=-1) min[$1]=$2; if($2!=-1)sum[$1]+=$2; else minus[$1]+=1;} END{for(k in count)print k,", count:",count[k],", max:",max[k],", min:",min[k],", avg:",sum[k]/count[k],", -1:",minus[k];}' | sort -k4nr

No.7 : response_processing_time の3つの統計値(最小値、最大値、平均)と -1 の値を取った回数を表示する

$ awk '{ print $4,$8,$9,$7 }' * | sort | sed -e 's/ /!!/' -e 's/ /!!/' | awk '{if(count[$1]==0) min[$1]=100; count[$1]+=1; if(max[$1]<$2&&$2!=-1) max[$1]=$2; if(min[$1]>$2&&$2!=-1) min[$1]=$2; if($2!=-1)sum[$1]+=$2; else minus[$1]+=1;} END{for(k in count)print k,", count:",count[k],", max:",max[k],", min:",min[k],", avg:",sum[k]/count[k],", -1:",minus[k];}' | sort -k4nr

No.8 : 最も多いリクエスト元のELBノードIPアドレスのリクエスト数

$ awk '{print $3}' * | awk -F ":" '{print $1}' | sort | uniq -c | sort -r| head -n 10 

No.9 : 時間毎のリクエスト数

grep中の二重引用符内は適宜日付等を入れて絞り込み

grep -r "" . | cut -d [ -f2 | cut -d] -f1 | awk -F: '{print $2":00"}' | sort -n | uniq -c

No.10 : 分単位でのリクエスト数

grep中の二重引用符内は適宜日付等を入れて絞り込み

$ grep "" * | cut -d [ -f2 | cut -d ] -f1 | awk -F: '{print $2":"$3}' | sort -nk1 -nk2 | uniq -c | awk '{ if ($1 > 10) print $0}'

No.11 : ユーザーエージェント毎のランキング

$ awk '{split($0, array, """); agent=array[4]; print agent}' * | sort | uniq -c | sort -nr | head

No.12 : TLSでクライアントが最も使った暗号スイートのランキング

$ awk '{split($0, array, """); afterUserAgent=array[5]; print afterUserAgent}' * | awk '{print $1}' | sort | uniq -c | sort -nr | head -5

No.13 : TLSでクライアントが最も使ったTLSバージョンのランキング

$ awk '{split($0, array, """); afterUserAgent=array[5]; print afterUserAgent}' * | awk '{print $2}' | sort | uniq -c | sort -nr | head

No.14 : TLSでクライアントが最も使ったプロトコルと暗号スイートのランキング

$ awk '{split($0, array, """); proto=array[1]; afterUserAgent=array[5]; print proto afterUserAgent}' * | awk '{print $1 " " $13}' | sort | uniq -c | sort -nr | head

ALB

No.1 : target_processing_time の3つの統計値(最小値、最大値、平均)と -1 の値を取った回数を表示する

 $ awk '{ print $5,$9,$10,$7 }' * | sort | sed -e 's/ /!!/' -e 's/ /!!/' | awk '{if(count[$1]==0) min[$1]=100; count[$1]+=1; if(max[$1]<$2&&$2!=-1) max[$1]=$2; if(min[$1]>$2&&$2!=-1) min[$1]=$2; if($2!=-1)sum[$1]+=$2; else minus[$1]+=1;} END{for(k in count)print k,", count:",count[k],", max:",max[k],", min:",min[k],", avg:",sum[k]/count[k],", -1:",minus[k];}' | sort -k4nr

No.2 : response_processing_time の3つの統計値(最小値、最大値、平均)と -1 の値を取った回数を表示する

$ awk '{ print $5,$9,$10,$8 }' * | sort | sed -e 's/ /!!/' -e 's/ /!!/' | awk '{if(count[$1]==0) min[$1]=100; count[$1]+=1; if(max[$1]<$2&&$2!=-1) max[$1]=$2; if(min[$1]>$2&&$2!=-1) min[$1]=$2; if($2!=-1)sum[$1]+=$2; else minus[$1]+=1;} END{for(k in count)print k,", count:",count[k],", max:",max[k],", min:",min[k],", avg:",sum[k]/count[k],", -1:",minus[k];}' | sort -k4nr

Athena

以下、全て CLB を前提とします。
また、以下のような、デフォルトで生成されている sampledb データベースの elb_logs テーブルを使用します。

CREATE EXTERNAL TABLE `elb_logs`(
  `request_timestamp` string COMMENT '', 
  `elb_name` string COMMENT '', 
  `request_ip` string COMMENT '', 
  `request_port` int COMMENT '', 
  `backend_ip` string COMMENT '', 
  `backend_port` int COMMENT '', 
  `request_processing_time` double COMMENT '', 
  `backend_processing_time` double COMMENT '', 
  `client_response_time` double COMMENT '', 
  `elb_response_code` string COMMENT '', 
  `backend_response_code` string COMMENT '', 
  `received_bytes` bigint COMMENT '', 
  `sent_bytes` bigint COMMENT '', 
  `request_verb` string COMMENT '', 
  `url` string COMMENT '', 
  `protocol` string COMMENT '', 
  `user_agent` string COMMENT '', 
  `ssl_cipher` string COMMENT '', 
  `ssl_protocol` string COMMENT '')
ROW FORMAT SERDE 
  'org.apache.hadoop.hive.serde2.RegexSerDe' 
WITH SERDEPROPERTIES ( 
  'input.regex'='([^ ]*) ([^ ]*) ([^ ]*):([0-9]*) ([^ ]*):([0-9]*) ([.0-9]*) ([.0-9]*) ([.0-9]*) (-|[0-9]*) (-|[0-9]*) ([-0-9]*) ([-0-9]*) \"([^ ]*) ([^ ]*) (- |[^ ]*)\" ("[^"]*") ([A-Z0-9-]+) ([A-Za-z0-9.-]*)$') 
STORED AS INPUTFORMAT 
  'org.apache.hadoop.mapred.TextInputFormat' 
OUTPUTFORMAT 
  'org.apache.hadoop.hive.ql.io.HiveIgnoreKeyTextOutputFormat'
LOCATION
  's3://athena-examples-us-west-2/elb/plaintext'
TBLPROPERTIES (
  'transient_lastDdlTime'='1480278335');

HTTPステータスコードが200のレコード一覧

SELECT * 
FROM elb_logs
WHERE elb_response_code <> '200'
ORDER BY request_timestamp;

ELB毎のリクエスト数

SELECT elb_name,
         count(*) AS request_count
FROM elb_logs
GROUP BY elb_name
ORDER BY request_count DESC;

ELB毎のリクエスト数(期間指定)

SELECT elb_name,
         count(*) AS request_count
FROM elb_logs
WHERE request_timestamp >= '2014-01-01T00:00:00Z'
        AND request_timestamp < '2016-01-01T00:00:00Z'
GROUP BY elb_name
ORDER BY request_count DESC;

ELB毎のリクエスト数(期間+ELB 指定)

SELECT elb_name,
         count(*) AS request_count
FROM elb_logs
WHERE elb_name LIKE 'elb_demo_008'
        AND request_timestamp >= '2014-01-01T00:00:00Z'
        AND request_timestamp < '2016-01-01T00:00:00Z'
GROUP BY elb_name
ORDER BY request_count DESC;

ELB毎の5XXエラーのリクエスト数

SELECT elb_name,
         backend_response_code,
         count(*) AS request_count
FROM elb_logs
WHERE backend_response_code >= '500'
GROUP BY backend_response_code, elb_name
ORDER BY backend_response_code, elb_name;

ELB毎の5XXエラーのリクエスト数(ELB指定)

SELECT elb_name,
         backend_response_code,
         count(*) AS request_count
FROM elb_logs
WHERE elb_name LIKE 'elb_demo_008'
        AND backend_response_code >= '500'
GROUP BY backend_response_code, elb_name
ORDER BY backend_response_code, elb_name;

ELB毎の5XXエラーのリクエスト数(期間+ELB 指定)

SELECT elb_name,
         backend_response_code,
         count(*) AS request_count
FROM elb_logs
WHERE elb_name LIKE 'elb_demo_008'
        AND backend_response_code >= '500'
        AND request_timestamp >= '2014-01-01T00:00:00Z'
        AND request_timestamp < '2016-01-01T00:00:00Z'
GROUP BY backend_response_code, elb_name
ORDER BY backend_response_code, elb_name;

ELB毎の5XXエラーのリクエスト数(期間+ELB+URL 指定)

SELECT count(*) AS request_count,
         elb_name,
         url,
         elb_response_code,
         backend_response_code
FROM elb_logs
WHERE elb_name LIKE 'elb_demo_008'
        AND backend_response_code >= '500'
        AND url LIKE 'http://www.example.com/jobs/%'
        AND request_timestamp >= '2014-01-01T00:00:00Z'
        AND request_timestamp < '2016-01-01T00:00:00Z'
GROUP BY elb_name,url,elb_response_code,backend_response_code
ORDER BY request_count DESC limit 10;

ELB毎の5XXエラーのリクエスト数(期間+ELB+URL+UserAgent 指定)

SELECT count(*) AS request_count,
         elb_name,
         url,
         elb_response_code,
         backend_response_code,
         user_agent
FROM elb_logs
WHERE elb_name LIKE 'elb_demo_008'
        AND backend_response_code >= '500'
        AND url LIKE 'http://www.example.com/jobs/%'
        AND user_agent LIKE '%Mozilla/5.0%'
        AND request_timestamp >= '2014-01-01T00:00:00Z'
        AND request_timestamp < '2016-01-01T00:00:00Z'
GROUP BY elb_name,url,elb_response_code,backend_response_code,user_agent
ORDER BY request_count DESC limit 10;

送信元IPのリクエスト数ランキング

SELECT request_ip,
         url,
         count(*) AS request_count
FROM elb_logs
WHERE elb_name LIKE 'elb_demo_008'
        AND request_timestamp >= '2014-01-01T00:00:00Z'
        AND request_timestamp < '2016-01-01T00:00:00Z'
GROUP BY request_ip,url
ORDER BY request_count DESC limit 5;

日付ごとのリクエスト数

SELECT date(from_iso8601_timestamp(request_timestamp)),
         count(*)
FROM elb_logs
WHERE url LIKE '%/jobs/%'
        AND date(from_iso8601_timestamp(request_timestamp)) >= date('2014-12-01')
GROUP BY  1
ORDER BY  1;

直近1年の500エラー発生のリクエスト数

SELECT elb_response_code,
         count(*)
FROM elb_logs
WHERE from_iso8601_timestamp(request_timestamp) >= date_add('day', -365 * 1, now())
        AND elb_response_code >= '500'
GROUP BY  1
ORDER BY  1;

レスポンスに1.0s以上時間がかかっているリクエスト

SELECT url,
         count(*) AS count,
         backend_processing_time
FROM elb_logs
WHERE backend_processing_time >= 1.0
GROUP BY  url, backend_processing_time
ORDER BY backend_processing_time DESC;

任意のエントリ取得(期間+リクエスト元IP 指定)

SELECT *
FROM elb_logs
WHERE request_ip = '245.85.197.169'
        AND request_timestamp >= '2014-01-01T00:00:00Z'
        AND request_timestamp <= '2016-01-01T00:00:00Z';

あるページからの遷移先ページ傾向

SELECT d.*
FROM 
    (SELECT b.request_ip,
         min(b.request_timestamp) AS request_timestamp
    FROM 
        (SELECT *
        FROM elb_logs
        WHERE url LIKE '%/jobs/%') a
        JOIN elb_logs b
            ON a.request_timestamp < b.request_timestamp
        GROUP BY  1 ) c
    JOIN elb_logs d
    ON c.request_ip = d.request_ip
        AND c.request_timestamp = d.request_timestamp
ORDER BY  d.request_timestamp;

参考

ELB アクセスログ

Classic Load Balancer のアクセスログ – Elastic Load Balancing
https://docs.aws.amazon.com/ja_jp/elasticloadbalancing/latest/classic/access-log-collection.html#access-log-entry-syntax
Application Load Balancer のアクセスログ – Elastic Load Balancing
https://docs.aws.amazon.com/ja_jp/elasticloadbalancing/latest/application/load-balancer-access-logs.html#access-log-entry-syntax

Athena

Querying Classic Load Balancer Logs – Amazon Athena
https://docs.aws.amazon.com/ja_jp/athena/latest/ug/elasticloadbalancer-classic-logs.html
Querying Application Load Balancer Logs – Amazon Athena
https://docs.aws.amazon.com/athena/latest/ug/application-load-balancer-logs.html

Amazon AthenaでELBのログを調査するときに使ったSQL
https://dev.classmethod.jp/cloud/amazon-athena-sql-for-elb/
Amazon AthenaでELBログをSQLで解析する #reinvent
https://dev.classmethod.jp/cloud/aws/amazon-athena-sql-elb-log-reinvent/
Amazon Athenaではじめるログ分析入門
https://qiita.com/miyasakura_/items/174dc73f706e8951dbdd

続きを読む

AWS Fargate

AWS ECS Fargate とは Docker コンテナを動かすための仕組み。Docker コンテナを起動して外から URL でアクセス出来るようになるまでやってみた。

  • コンテナは 8001 (WebSocket) と 8002 (HTTP) の2つのポートを受け付ける。
  • 外から両方のポートを使いたい。

AWS ECS には Clusters, Task Definitions, Repository の3つの設定項目がある

  • Clusters:

    • 複数の Service をまとめて動作させる箱。
    • Service:
      • 複数の Task をまとめて動作させる箱。
  • Task Definitions:
    • Task とは、Docker コンテナの動作単位。使う Docker image は AWS の Repositories から取ってきても良いし、他の Docker repository を使っても良い。
  • Repositories:
    • AWS 用の Docker Repository. Docker image を保存する場所。

作業手順は次のようになる。

  1. Repositories に Docker image を登録
  2. Task Definition に Docker repository を指定
  3. Cluster を作成
  4. Application Load Balancer を作成
  5. Cluster 内に Service と Task を作成
  6. Security Group の設定

AWS Fargate First run

  • https://qiita.com/riywo/items/b223bdad2b3ae3bebf55 の通りに First runチュートリアル試した。
  • 次へ次へと押すだけ
  • Unable to assume the service linked role. Please verify that the ECS service linked role exists というエラーが出る。
  • 二回目同じ事をやると何故か問題なく完了した。
  • Cluster : default > sample-app-service
  • AWS Console > Elastic Container Service > Clusters : default > Tasks > Task をクリック
  • IP が割り当てられている事を確認。

AWS Cluster を削除する時の注意点

  • The vpc ‘vpc-xxx’ has dependencies and cannot be deleted. のエラーが出て消せなかった。
  • EC2 security group が参照していたので消したら OK。

AWS ECS Repositories に Docker image を登録

AWS FargateでFlaskを動かしてみる を参考に作業。

  • Console で Region N. Virginia を選択
  • AWS Console > Elastic Container Service (ECS) > Repositories
  • Create repository
  • Repository name: hoge-websocket-server
  • Repository URL: xxx.dkr.ecr.us-east-1.amazonaws.com/hoge-websocket-server

画面に表示されるコマンドを実行してログイン

$ aws ecr get-login --no-include-email --region us-east-1
docker login -u AWS -p eyJwYXlsb2...
$ docker login -u AWS -p eyJwYXlsb2... (表示された長いコマンドをそのまま実行)

先程出来た Docker image にタグを追加

$ docker tag hoge-websocket-server:latest xxx.dkr.ecr.us-east-1.amazonaws.com/hoge-websocket-server:latest

Docker image を Registory に追加

$ docker push xxx.dkr.ecr.us-east-1.amazonaws.com/hoge-websocket-server:latest
file integrity checksum failed for "usr/lib/x86_64-linux-gnu/libjpeg.a"

Docker image が大きいと上のようなエラーが出た。小さい node のイメージを使ってイメージをダイエットすると成功。

Task Definition に Docker repository を指定

ここで Docker image の場所や使いたいリソースを定義する。

  • AWS Console > ECS > Task Definitions > Create a new definition

    • 1: Select launch type compatibility

      • FARGATE
    • 2: Configure task and container definitions
      • Task Definition Name: hoge-websocket-server
      • Task memory (GB): 0.5GB
      • Task CPU (vCPU): 0.25 vCPU
      • Add container
        • Container name: hoge-websocket-server
        • Image: xxx.dkr.ecr.us-east-1.amazonaws.com/hoge-websocket-server:latest
        • Port mappings
          • 8001
          • 8002
      • Create

Cluster を作成

  • AWS Console > ECS > Clusters > Create Cluster

    • 1: Select cluster template

      • Networking only
    • 2: Configure cluster
      • Culster name: hoge-cluster
      • Create VPC: チェック (意味はよくわからない)
        • 作成されるネットワーク情報に目を通しておく。
        • デフォルトで2つのサブネットが定義されるようだが、そのままにしておいた。
    • View Cluster

これで Cluster 本体の他、色々な Cluster Resources が作成される。これらの大事な情報を後から参照する方法が分からなかったので必ずメモっておく。

Load Balancer の作成

このままだと起動停止のたびに IP アドレスが変わってしまうので、Application Load Balanceer (ALB) を使ってドメイン名を割り当てる。

  • AWS Console > EC2 > Load Balancers
  • Application Load Balancer > Create
  • 1: Configure Load Balancer
    • Name: hoge
    • Scheme: internet-facing
    • IP address type: ipv4
    • Listeners
      • HTTP: 8001 (Websocket も HTTP で良い)
      • HTTP: 8002 (HTTP 用の Listener は ECS Service 設定時に出来るのでここで作らなくて良い)
    • Availability Zones
      • VPC (Create Cluster で設定した VPC)
      • 下の Subnet は2つとも選択する
    • Tag
      • project : hoge
  • 2: Configure Security Settings
    • 設定なし
  • 3: Security Groups
    • Create a new security group
    • Security group name: hoge-security-group
    • 使いたいポート番号を設定
    • あとで AWS Console > ECS > Clusters > hoge-cluster > Tasks > Task : a44f… から編集出来る。
  • 4: Configure Routing
    • ヘルスチェックの設定らしい
    • Name: hoge-8002
    • Port: 8002
  • 5: Register Targets
    • 何も設定しない

Cluster 内に Service を作成

  • AWS Console > ECS > Clusters > hoge-cluster > Services > Create

    • 1: Configure service

      • Launch type: FARGATE
      • Task Definition: (作成した Task)
      • Service name: hoge-service
      • Number of taksk: 1
    • 2: Configure network
      • Cluster VPC: (Create Cluster で設定した VPC)
      • Subnets: (Create Cluster で設定した subnet)
      • Security groups > Edit
        • Assigned security groups: Select existing security group
        • Load Balancer で作った hoge-security-group を選択
      • Load balancing
        • Load balancer type: Application Load Balancer
        • Load balancer name: hoge
      • Container to load balance
        • ここで設定すると、コンテナの IP が変わっても自動的に一つのポートだけ Load Balancer に割り当てられる。
        • hoge-websocket-server:8002 > Add to load balancer
          • Listner port: 8002:HTTP
          • Path pattern: /*
          • Evaluation order: 1
          • Health check path: /
        • hoge-websocket-server:8002
    • 3: Set Auto Scaling
      • デフォルトのまま
    • 4: Review
      • 特に VPC Id と Subnets に気をつける。間違うとややこしい事になる。
    • Create Service

コンテナに割り当てられた IP アドレスの確認

  • AWS Console > ECS > Clusters > hoge-cluster > Tasks > Task : a44f… を選択
  • Private IP と Public IP が表示される。

もう一つのポート Port 8001 の設定

ECS Service の作成時に Load Balancer を割り当てると、IP が変化しても Load Balancer が勝手に面倒を見てくれる。ただしポート番号は一つしか設定出来ない!!!!この例のように2つ目のポートを Load Balancer に見せるには、手動で IP を指定した Target Groups を作る必要があった。なので、更新の際にはこの IP をわざわざ再入力する必要がある。

  • AWS Console > EC2 > LOAD BALANCING Target Groups

    • Target group name: hoge-8001
    • Protocol: HTTP
    • Port: 8001
    • Target type: ip
    • VPC: Cluster の VPC
    • Create
  • AWS Console > EC2 > LOAD BALANCING Target Groups > hoge-8001
    • Targets > Edit
    • Task の IP を登録
  • AWS Console > EC2 > LOAD BALANCING Load Balancers > hoge > Listeners
    • HTTP:8001 > View/edit rules
    • THEN に hoge-8001 を登録

Docker image の更新

  • AWS Console > ECS > Clusters > hoge-cluster > hoge-service > Update

    • Force new deployment: Check
    • 次へ次へ。。。
  • しばらく待つと新しいコンテナが起動して古いコンテナが停止する。
  • IP アドレスが変わっているので Load Balancer の Target Group も更新する。

Task 削除

Task は service が管理するので、直接止められないらしい。Service の Update で Number of tasks を 0 にすると止められた。

  • AWS Console > ECS > Clusters > hoge-cluster > hoge-service > Update
  • Number of tasks: 0
  • 次へ次へ

やりたかった事は node 一つの単純なサーバをテストしたいだけだったんだけど、随分大げさな構成になってしまった。

続きを読む

[AWS] ELBとEC2の tag:Name の仕様の違いについて

細かい点ですが、EC2とELBの所謂「Nameタグ」の仕様に違いがあったのでまとめておきます。

EC2の場合

コンソールでEC2を確認すると、一覧と「タグ」タブ内に2つ”Name”が確認できます。EC2では、この2つは同じものです。

image.png

これは実体としてはタグで、describe-instancesコマンドで確認できます。

$ aws ec2 describe-instances --region eu-west-3 | jq -r '.Reservations[] .Instances[] .Tags[]'
{
  "Value": "bastion-ec2",
  "Key": "Name"
}

更新したい場合は、create-tagsコマンドで(少々違和感がありますが)上書きできます。

$ aws ec2 create-tags --region eu-west-3 --resources i-02axxxxxxxxxxxxx --tags Key=Name,Value=name-update-test

コンソールでは両方更新されることが確認できます。

image.png

ELBの場合

コンソールでELBを確認すると、一覧の方に”名前”が、「タグ」タブの方に”Name”が表示されています。EC2と似た表示ですが、ELBではこれらは別物です。

image.png

“名前”の方はロードバランサ名(LoadBalancerName)でdescribe-load-balancersコマンドで確認できます。”Name”の方がタグで、describe-tagsコマンドで確認できます。

$ aws elb describe-load-balancers --region eu-west-3 | jq -r '.LoadBalancerDescriptions[] .LoadBalancerName'
internal-elb
$ aws elb describe-tags --region eu-west-3 --load-balancer-names internal-elb
{
    "TagDescriptions": [
        {
            "Tags": [
                {
                    "Value": "this-is-name-tag",
                    "Key": "Name"
                }
            ],
            "LoadBalancerName": "internal-elb"
        }
    ]
}

ロードバランサ名(LoadBalancerName)の方は、作成後には更新できません。タグの方はEC2と同様にadd-tagsコマンドで上書きできます。

$ aws elb add-tags --region eu-west-3 --load-balancer-names internal-elb --tags Key=Name,Value=tag-update-test
$ aws elb describe-tags --region eu-west-3 --load-balancer-names internal-elb
{
    "TagDescriptions": [
        {
            "Tags": [
                {
                    "Value": "tag-update-test",
                    "Key": "Name"
                }
            ],
            "LoadBalancerName": "internal-elb"
        }
    ]
}

コンソールでもタグの方だけ更新されたことが確認できます。

image.png

ALBまたはNLBの場合

ALB(Application Load Balancer)またはNLB(Network Load Balancer)の場合も同様の動作となります。awscliはelbv2コマンドで確認できます。

名前とタグの確認:

$ aws elbv2 describe-load-balancers --region ap-northeast-1 | jq -r '.LoadBalancers[] .LoadBalancerName'
internal-elb
$ aws elbv2 describe-tags --region ap-northeast-1 --resource-arns arn:aws:elasticloadbalancing:ap-northeast-1:xxxxxxxxxx:loadbalancer/net/internal-elb/xxxxxxxxxx
{
    "TagDescriptions": [
        {
            "ResourceArn": "arn:aws:elasticloadbalancing:ap-northeast-1:xxxxxxxxxx:loadbalancer/net/internal-elb/xxxxxxxxxx",
            "Tags": [
                {
                    "Value": "this-is-name-tag",
                    "Key": "Name"
                }
            ]
        }
    ]
}

タグの変更:

$ aws elbv2 add-tags --region ap-northeast-1 --tags Key=Name,Value=tag-update-test --resource-arns arn:aws:elasticloadbalancing:ap-northeast-1:xxxxxxxxxx:loadbalancer/net/internal-elb/xxxxxxxxxx
$ aws elbv2 describe-tags --region ap-northeast-1 --resource-arns arn:aws:elasticloadbalancing:ap-northeast-1:xxxxxxxxxx:loadbalancer/net/internal-elb/xxxxxxxxxx
{
    "TagDescriptions": [
        {
            "ResourceArn": "arn:aws:elasticloadbalancing:ap-northeast-1:xxxxxxxxxx:loadbalancer/net/internal-elb/xxxxxxxxxx",
            "Tags": [
                {
                    "Value": "tag-update-test",
                    "Key": "Name"
                }
            ]
        }
    ]
}

まとめ

EC2の場合は特に意識せず「Nameタグ」を使っていましたが、ELBの場合は名前(LoadBalancerName)とタグ(tag:Name)が別々に設定できるので混同しないよう注意が必要です。違う値を設定した場合はどちらを意図しているのかきちんと確認するようにしましょう。

続きを読む

Amazon Fargate でコンテナを動かす

スクリーンショット 2018-01-03 10.08.09.png

もくじ

  1. ALBの作成
  2. Fargateタスクの作成
  3. Fargateクラスターの作成
  4. Fargateサービスの作成
  5. アクセス確認

事前準備

事前にnginxのコンテナイメージをリポジトリに登録しておきます。

Amazon ECS を利用する前にローカルでコンテナを動かす – Qiita

1. ALBの作成

事前にサービスで利用するALB(Application Load Balancer)を作成しておきます

補足:ECSとの違い
FargateではALBに割り当てるターゲットグループのターゲットの種類ipが指定されてないと、サービス作成時に指定することができませんでした。

elb01.png
elb02.png
elb03.png
elb04.png
elb05.png
elb06.png
elb07.png
elb08.png
elb09.png

2. Fargateタスクの作成

Fargate用のタスクを作成します。

補足:ECSとの違い
Task SizeのCPUとメモリが必須パラメータになってました
ポートマッピングでホストポートの指定が不要になってました

task01.png
task02.png
task03.png
task04.png

task05.png
task06.png

3. Fargateクラスターの作成

Fargate用のクラスターを作成します。

補足:ECSとの違い
EC2インスタンスの設定が不要になってました

cluster01.png
cluster02.png
cluster03.png
cluster04.png

4. Fargateサービスの作成

Fargate用のサービスを作成します。

sv01.png
sv0.png
sv02.png
sv03.png

注意点:ターゲットグループ名
ターゲットの種類ipが指定されてないターゲットグループはプルダウンの選択候補として表示されない

sv04.png
sv05.png
sv06.png

5. アクセス確認

タスクの前回のステータスREADYになったことを確認する。

ac01.png

ターゲットグループの登録済みターゲットで状態healtyになってることを確認する。

ac02.png

ALBのDNS名を確認してブラウザからアクセスできることを確認。

ac03.png
ac04.png

続きを読む

AWS Certificate Manager で証明書を発行してALBに割り当てる

全体の流れ

  1. ドメインを取得する
  2. ドメインにALBを割り当てる
  3. HTTPS化する ←今回の投稿

もくじ

  1. 証明書を発行
  2. セキュリティグループでHTTPSを許可
  3. ALBでリスナーにHTTPSを追加
  4. アクセス確認

前提条件

  • ALB(Application Load Balancer)は事前に作成済み
  • Route53でドメイン取得済み
  • Route53でALBへのDNSレコードを設定済み

1. 証明書を発行

AWS Certificate Manager で証明書を発行します。

https01.png
https02.png
https03.png
https04.png
https05.png
https06.png
https07.png
https08.png
https09.png

2. セキュリティグループでHTTPSを許可

ALBに割り当てているセキュリティグループでインバウンドのルールにHTTPSを許可する。

https13.png
    https12.png

3. ALBでリスナーにHTTPSを追加

ALBでリスナーにHTTPSを追加する。

https10.png
https11.png

4. アクセス確認

ブラウザからHTTPS化したURLにアクセスする。

https14.png

続きを読む

Amazon Route53 でドメインにALBを割り当てる

全体の流れ

  1. ドメインを取得する
  2. ドメインにALBを割り当てる ←今回の投稿
  3. HTTPS化する

もくじ

  1. ドメインにALBを割り当て
  2. アクセス確認

参考

ドメイン名を登録する方法 – アマゾンウェブサービス

前提条件

  • ALB(Application Load Balancer)は事前に作成済み
  • ドメインは事前に取得済み

1. ドメインにALBを割り当て

Route 53のコンソールでドメインにALBを割り当てます。

elb01.png
elb02.png
elb03.png

補足:
Alias TargetテキストボックスをクリックするとALBの一覧が表示される

elb04.png

elb05.png

2. アクセス確認

ブラウザで登録したURLにアクセスする。

elb06.png

続きを読む

Amazon ECSでコンテナをクラスタリングする

ecs01.png

全体の流れ

  1. ローカルでコンテナを動かす
  2. ECSでコンテナを動かす
  3. ECSでコンテナをクラスタリングする ←今回の投稿
  4. ECSのログをCloudWatchで収集する
  5. HTTPS化する

もくじ

今回の投稿ではコンテナをクラスタリングします。

  1. Application Load Balancerの作成
  2. セキュリティグループの作成
  3. ECSのリポジトリにコンテナイメージを登録する
  4. ECSのタスク定義を作成する
  5. ECSのクラスターを作成する
  6. ECSのサービスを作成する
  7. アクセス確認

ecs200.png

デプロイするコンテナについて

以前の投稿で作成したnginxのコンテナイメージをデプロイします。

1. Application Load Balancerの作成

コンテナへのロードバランシングを行うApplication Load Balancer(ALB)を作成します。

ec02.png
lb.png
lb01.png
lb02.png

lb03.png

補足:アベイラビリティゾーン
ECSでクラスターを作成する際にはここで選択したVPCを利用するようにします。

lb04.png
lb05.png

lb06.png

lb07.png
lb08.png
lb09.png
lb10.png

2. セキュリティグループの作成

ECSでクラスターを作成する際にEC2インスタンスに割り当てるセキュリティグループを作成しておきます。

sg.png
sg01.png
sg02.png

補足:VPC
ALBを作成する際に選択したVPCを選択する

補足: セキュリティグループのルール
ALBからEC2インスタンスへのアクセスを許可させる必要があるため、
ポート範囲にはコンテナのホストポートを指定する
ソースにはALBに割り当てられているセキュリティグループを指定する

補足:コンテナのホストポートについて
ホストポートを動的割当にした場合は32768 - 61000が利用される
参考:タスク定義パラメーター – Amazon Elastic Container Service

sg03.png

3. ECSのリポジトリにコンテナイメージを登録する

repo01.png
repo02.png
repo03.png
repo04.png
repo05.png
repo06.png

補足:リポジトリのURI
タスク定義で必要になるためメモしておく

4. ECSのタスク定義を作成する

task01.png
task02.png
task03.png

補足:イメージ
リポジトリのURIを指定する

補足:ポートマッピング
ホストポート0を指定することで、ポートが動的に割り当てられる

補足:コンテナのホストポートについて
ホストポートを動的割当にした場合は32768 - 61000が利用される
参考:タスク定義パラメーター – Amazon Elastic Container Service

task04.png
task05.png
task06.png

5. ECSのクラスターを作成する

cl01.png
cl02.png
cl03.png
cl04.png

補足:VPC、サブネット
1. Application Load Balancerの作成で指定したVPC、サブネットを指定する

補足:セキュリティグループ
2. セキュリティグループの作成で用意したセキュリティグループを指定する

cl05.png
cl06.png

6. ECSのサービスを作成する

sv01.png
sv02.png
sv03.png

補足:ELB名
1. Application Load Balancerの作成で作成したALBを指定する

sv04.png

補足:ターゲットグループ名
1. Application Load Balancerの作成の際に作成したターゲットグループを指定する

sv05.png
sv06.png
sv07.png

7. アクセス確認

ECS

ECSのコンソールで実行中のタスクステータスが確認できる。

sv08.png
sv09.png

EC2インスタンス

EC2インスタンスのコンソールでクラスターで利用しているEC2インスタンスが確認できる。

ac01.png

ターゲットグループ

ターゲットグループのコンソールでサービスで登録したタスクのヘルスチェックの状況が確認できる。

ac02.png

ALB

ALBのコンソールで表示されるDNS名にブラウザからアクセスする。

ac03.png

ac04.png

補足

【備忘録】ECSでデプロイしたコンテナにアクセス出来ない時に見直すこと – Qiita

続きを読む

【備忘録】ECSでデプロイしたコンテナにアクセス出来ない時に見直すこと

問題点

ブラウザからECSでデプロイしたコンテナにアクセス出来ない。

ecs35.png

状況

デプロイ前

ECSにコンテナをデプロイする前の設定(原因と思われる箇所のみ抜粋)

タスク定義

  • ホストポートは動的割当に(ホストポートに0を指定)していた

ecs34.png

サービス

ALBを利用するように設定していた

ecs43.png

デプロイ後

コンテナデプロイ後の動作

ターゲットグループ

状態がunhealtyのままとなり、healtyにならない。

ecs30.png

タスク

タスクがSTOPされ、前回のステータスにTask failed ELB health checks in xxxと表示される。

ecs31.png

原因

コンテナのヘルスチェックに失敗するため、ロードバランサーがコンテナにリクエストを送信していなかった。

見直し・解決方法

ロードバランサーのヘルスチェックがコンテナへ到達できるようにALBやEC2の設定を見直す。

Application Load Balancer

  • ALBとコンテナをデプロイするEC2インスタンスが同じVPCに配置されてるか?
  • コンテナをデプロイするEC2インスタンスのアベイラビリティゾーンが含まれているか?

などを確認する。

ecs37.png

ecs36.png

ALBをコンテナをデプロイするEC2インスタンスと異なるVPCに配置していた場合は、VPCやアベイラビリティゾーンの設定に注意してALBを作成する。

ecs32.png

セキュリティグループ

  • EC2インスタンスに割り当てられているセキュリティグループがロードバランサーからのアクセスを許可しているか?

などを確認する。

ecs38.png

ecs40.png

公式ドキュメントのタスク定義パラメーターによると、Docker デーモンは /proc/sys/net/ipv4/ip_local_port_range の一時ポート範囲 (最新の Amazon ECS 最適化 AMI では 32768 ~ 61000) を読み取ろうとします。とあるので、EC2インスタンスに割当られているセキュリティグループにロードバランサーのセキュリティグループからポート32768 – 61000へのアクセスを許可するルールを追加する。

ecs39.png

アクセス確認

ALBやEC2の設定を見直したところ、ヘルスチェックが通るようになり、ブラウザからコンテナへアクセスすることができるようになった。

ecs41.png

ecs42.png

続きを読む

ALB Ingress Controller を使う

この記事では、 ALB Ingress Controller について書きます。

zalando-incubator/kube-ingress-aws-controller については、 Kubernetes2 Advent Calendar 2017 7日目 @mumoshu 先生の記事で、 書かれていますので、そちらを参照して下さい :bow:

WHY

Kubernetes on AWS で運用している場合、 Kubernetes の Service を作成すると、 AWS の Classic Load Balancer が作成されます。 Classic Load Balancer 以外に Application Load Balancer を利用したい場合が以下のような時にあります。

  • http2 を利用したい
  • /blog などリソース毎に向き先を区切る

Kubernetes on AWS を利用する方は既に AWS を使いだおしている方が大半だと思います。既存のアプリケーションを Kubernetes へ移行しようとした際に、 既に ALB(Application Load Balancer) を利用していたのが、 Kubernetes へ移行したら ELB (Classic Load Balancer) になって http2 無くなりましたというのはパフォーマンスにも影響を与えます。

そこで ALB Ingress Controller を利用することで、 ALB が使えます。

ALB Ingress Controller

The ALB Ingress Controller satisfies Kubernetes ingress resources by provisioning Application Load Balancers.

ALB Ingress Controller は、 Kubernetes の ingress を作成したタイミングで、 Application Load Balancer を作成します。

Design

image.png

The following diagram details the AWS components this controller creates. It also demonstrates the route ingress traffic takes from the ALB to the Kubernetes cluster.

Design に ALB が作られるまでの流れと、トラフィックの流れが書かれています。

Ingress Creation

Kubernetes 上に ingress を一つ作った時の流れ

[1]: The controller watches for ingress events from the API server. When it finds ingress resources that satisfy its requirements, it begins the creation of AWS resources.

[1] ALB Ingress Controller は、 Kubernetes の API Server からの Event を監視し、該当の Event を検知したら AWS のリソースを作成し始める。

[2]: An ALB (ELBv2) is created in AWS for the new ingress resource. This ALB can be internet-facing or internal. You can also specify the subnets its created in using annotations.

[2] ALB を作成する。 annotation を指定することで、サブネットやインターネット向けか内部向けかも決めることができる。

[3]: Target Groups are created in AWS for each unique Kubernetes service described in the ingress resource.

[3] ALB の向き先となるターゲットグループは、 ingress に記述された Service ごとに AWS で作成。

[4]: Listeners are created for every port detailed in your ingress resource annotations. When no port is specified, sensible defaults (80 or 443) are used. Certificates may also be attached via annotations.

[4] リスナは、 ingress の annotation で指定したポート用に作成されます。ポートが指定されていない場合、80または443を使用。 ACM も使用することもできる。

[5]: Rules are created for each path specified in your ingress resource. This ensures traffic to a specific path is routed to the correct Kubernetes Service.

[5] 入力リソースで指定された各パスに対してルールが作成され、特定のパスへのトラフィックが正しい Kubernetes の Service にルーティングされる。

Ingress Traffic

This section details how traffic reaches the cluster.

As seen above, the ingress traffic for controller-managed resources starts at the ALB and reaches the Kubernetes nodes through each service’s NodePort. This means that services referenced from ingress resource must be exposed on a node port in order to be reached by the ALB.

ALB から始まり、各サービスの NodePort を通じて Kubernetes ノードに到達するようになっている。 ALB を使ったサービスを公開するためには、 ingress と NodePort を使った Service の二つが必要になる。

How it Works

  • alb-ingress-controller 用の IAM を作成
  • ALB 作る際に、 sg と subnet を自動でアサインされるように、 subnet にタグの設定
  • AWS の IAM 情報と CLUSTER_NAME を secrets に入れる
  • default サーバーという一旦 target group アサインできるテンポラリのサービスを建てる
  • alb-ingress-controller を deploy する

alb-ingress-controller 用の IAM を作成

Role Permissions

AWS を操作するため、専用の IAM が必要になります。必要になるリソースは例と以下に記載されています。

IAM Policy

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "acm:DescribeCertificate",
                "acm:ListCertificates"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "ec2:AuthorizeSecurityGroupIngress",
                "ec2:CreateSecurityGroup",
                "ec2:CreateTags",
                "ec2:DeleteSecurityGroup",
                "ec2:DescribeInstances",
                "ec2:DescribeSecurityGroups",
                "ec2:DescribeSubnets",
                "ec2:DescribeTags",
                "ec2:ModifyInstanceAttribute",
                "ec2:RevokeSecurityGroupIngress"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "elasticloadbalancing:AddTags",
                "elasticloadbalancing:CreateListener",
                "elasticloadbalancing:CreateLoadBalancer",
                "elasticloadbalancing:CreateRule",
                "elasticloadbalancing:CreateTargetGroup",
                "elasticloadbalancing:DeleteListener",
                "elasticloadbalancing:DeleteLoadBalancer",
                "elasticloadbalancing:DeleteRule",
                "elasticloadbalancing:DeleteTargetGroup",
                "elasticloadbalancing:DescribeListeners",
                "elasticloadbalancing:DescribeLoadBalancers",
                "elasticloadbalancing:DescribeRules",
                "elasticloadbalancing:DescribeTags",
                "elasticloadbalancing:DescribeTargetGroups",
                "elasticloadbalancing:DescribeTargetHealth",
                "elasticloadbalancing:ModifyListener",
                "elasticloadbalancing:ModifyLoadBalancerAttributes",
                "elasticloadbalancing:ModifyRule",
                "elasticloadbalancing:ModifyTargetGroup",
                "elasticloadbalancing:RegisterTargets",
                "elasticloadbalancing:RemoveTags",
                "elasticloadbalancing:SetSecurityGroups",
                "elasticloadbalancing:SetSubnets"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "iam:GetServerCertificate",
                "iam:ListServerCertificates"
            ],
            "Resource": "*"
        }
    ]
}

ALB 作る際に、 sg と subnet を自動でアサインされるように、 subnet にタグの設定

Subnet Selection

ingress の annotation か auto-detection で、 各ALBを作成するサブネットを決定。

  • annotation: alb.ingress.kubernetes.io/subnets に、 subnet ID または NAME タグを使用して指定
  • auto-detection: annotation の指定はなく、自動検出で ALB を作成

auto-detection を有効にするためには、以下の tag を追加します。 ALB を作る際に subnet が二つ必要なため、二つ tag をつける。

  • kubernetes.io/role/alb-ingress=
  • kubernetes.io/cluster/$CLUSTER_NAME=shared

    • $CLUSTER_NAMEalb-ingress-controller.yamlCLUSTER_NAME 環境変数と一致させる必要がある

設定例

image

AWS の IAM 情報と CLUSTER_NAME を Secrets に入れる

namespace name key description
kube-system alb-ingress-controller AWS_ACCESS_KEY_ID credentials of IAM user for alb-ingress-controller
kube-system alb-ingress-controller AWS_SECRET_ACCESS_KEY credentials of IAM user for alb-ingress-controller
kube-system alb-ingress-controller CLUSTER_NAME cluster name
  • 登録方法

k8sec を使って Sercrets に登録します。

$ k8sec set alb-ingress-controller KEY=VALUE -n kube-system
  • 確認
$ k8sec list alb-ingress-controller -n kube-system
NAME            TYPE    KEY         VALUE
alb-ingress-controller  Opaque  AWS_ACCESS_KEY_ID   "hoge"
alb-ingress-controller  Opaque  AWS_SECRET_ACCESS_KEY   "fuga"
alb-ingress-controller  Opaque  CLUSTER_NAME        "Ooops"

ingress に必要になる Default backend サービスを建てる

kubectl Deployments

alb-ingress-controller を使うために必要になる Default backend サービスを建てる。 alb-ingress-controller を利用する ingress は、全て Default backend を指す。

$ kubectl create -f https://raw.githubusercontent.com/coreos/alb-ingress-controller/master/examples/default-backend.yaml

alb-ingress-controller を deploy する

  • alb-ingress-controller manifest ファイルをダウンロードする
$ wget https://raw.githubusercontent.com/coreos/alb-ingress-controller/master/examples/alb-ingress-controller.yaml
  • Secrets に追加したものを manifest file に反映する
        envFrom:
        - secretRef:
            name: alb-ingress-controller
  • AWS_REGION を設定する
- name: AWS_REGION
  value: ap-northeast-1
  • Deploy alb-ingress-controller
$ kubectl apply -f alb-ingress-controller.yaml  
  • log で起動できているか確認できる。
$ kubectl logs -n kube-system 
    $(kubectl get po -n kube-system | 
    egrep -o alb-ingress[a-zA-Z0-9-]+) | 
    egrep -o '[ALB-INGRESS.*$'
[ALB-INGRESS] [controller] [INFO]: Log level read as "", defaulting to INFO. To change, set LOG_LEVEL environment variable to WARN, ERROR, or DEBUG.
[ALB-INGRESS] [controller] [INFO]: Ingress class set to alb
[ALB-INGRESS] [ingresses] [INFO]: Build up list of existing ingresses
[ALB-INGRESS] [ingresses] [INFO]: Assembled 0 ingresses from existing AWS resources

上手く動かない場合ははここを true にすると良い。 AWS の制限で止められている可能性もありえる。

        - name: AWS_DEBUG
          value: "false"

これで ALB Ingress Controller の準備は完了

実際に ALB 作成してみる

alb-ingress-controller にある echo server を元にやってみる。基本的に以下、二点を抑えるだけで ALB
を利用できる。

  • ingress と NodePort を使った Service
  • ingress の annotation の設定

echoservice

alb-ingress-controller にある sample を元に echoserver を建ててみる。

$ kubectl apply -f https://raw.githubusercontent.com/coreos/alb-ingress-controller/master/examples/echoservice/echoserver-namespace.yaml &&
kubectl apply -f https://raw.githubusercontent.com/coreos/alb-ingress-controller/master/examples/echoservice/echoserver-service.yaml &&
kubectl apply -f https://raw.githubusercontent.com/coreos/alb-ingress-controller/master/examples/echoservice/echoserver-deployment.yaml

Namespace を切って、 NodePort で開放する Service と Deployment が作られる。

$ kubectl get all -n echoserver
NAME                             READY     STATUS    RESTARTS   AGE
po/echoserver-2241665424-xm1rt   1/1       Running   0          10m

NAME             TYPE       CLUSTER-IP     EXTERNAL-IP   PORT(S)        AGE
svc/echoserver   NodePort   100.65.13.23   <none>        80:31509/TCP   10m

NAME                DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
deploy/echoserver   1         1         1            1           10m

NAME                       DESIRED   CURRENT   READY     AGE
rs/echoserver-2241665424   1         1         1         10m
  • ingress file を取得する
wget https://raw.githubusercontent.com/coreos/alb-ingress-controller/master/examples/echoservice/echoserver-ingress.yaml
  • annotation の設定(オプション)

Annotations に全部使える ALB の option が書いてある。

alb.ingress.kubernetes.io/scheme: internet-facing # or 'internal'
alb.ingress.kubernetes.io/connection-idle-timeout: # Defauflt 60
alb.ingress.kubernetes.io/subnets: # subnet ID か Name 
alb.ingress.kubernetes.io/security-groups: # sg ID か Name Default 0.0.0.0/0 
alb.ingress.kubernetes.io/listen-ports: '[{"HTTP":80,"HTTPS": 443}]' # Default 80
alb.ingress.kubernetes.io/certificate-arn: arn:aws:acm:ap-northeast-1:hoge:certificate/UUID # ACM 利用する場合
alb.ingress.kubernetes.io/healthcheck-path: # Default "/"
alb.ingress.kubernetes.io/healthcheck-port: # Default Traffic port
alb.ingress.kubernetes.io/healthcheck-interval-seconds: # Default 15
alb.ingress.kubernetes.io/healthcheck-protocol: # Default HTTP
alb.ingress.kubernetes.io/healthcheck-timeout-seconds: # Default 5
alb.ingress.kubernetes.io/healthy-threshold-count: # Default 2
alb.ingress.kubernetes.io/unhealthy-threshold-count: # Default 2
alb.ingress.kubernetes.io/successCodes: # Default 200
alb.ingress.kubernetes.io/tags:  # Tag を入れる
  • ingress を建てる
$ kubectl apply -f echoserver-ingress.yaml

とりあえず default のままでいい場合は下記のコマンド

$ kubectl apply -f https://raw.githubusercontent.com/coreos/alb-ingress-controller/master/examples/echoservice/echoserver-ingress.yaml
  • ALB が作成された log を確認して見る
$ kubectl logs -n kube-system 
  $(kubectl get po -n kube-system | 
  egrep -o alb-ingress[a-zA-Z0-9-]+) | 
  egrep -o '[ALB-INGRESS.*$' | 
  grep 'echoserver/echoserver'
[ALB-INGRESS] [echoserver/echoserver] [INFO]: Start ELBV2 (ALB) creation.
[ALB-INGRESS] [echoserver/echoserver] [INFO]: Completed ELBV2 (ALB) creation. Name: hogefuga-echoserver-ech-2ad7 | ARN: arn:aws:elasticloadbalancing:ap-northeast-1:0000:loadbalancer/app/hogefuga-echoserver-ech-2ad7/17fd1481cb40fcc2
[ALB-INGRESS] [echoserver/echoserver] [INFO]: Start TargetGroup creation.
[ALB-INGRESS] [echoserver/echoserver] [INFO]: Succeeded TargetGroup creation. ARN: arn:aws:elasticloadbalancing:ap-northeast-1:0000:targetgroup/hogefuga-31509-HTTP-c3a0606/9914a217042c4006 | Name: hogefuga-31509-HTTP-c3a0606.
[ALB-INGRESS] [echoserver/echoserver] [INFO]: Start Listener creation.
[ALB-INGRESS] [echoserver/echoserver] [INFO]: Completed Listener creation. ARN: arn:aws:elasticloadbalancing:ap-northeast-1:0000:listener/app/hogefuga-echoserver-ech-2ad7/17fd1481cb40fcc2/0fe42e9436e45013 | Port: 80 | Proto: HTTP.
[ALB-INGRESS] [echoserver/echoserver] [INFO]: Start Rule creation.
[ALB-INGRESS] [echoserver/echoserver] [INFO]: Completed Rule creation. Rule Priority: "1" | Condition: [{    Field: "host-header",    Values: ["echoserver.example.com"]  },{    Field: "path-pattern",    Values: ["/"]  }]
[ALB-INGRESS] [echoserver/echoserver] [INFO]: Fetching Targets for Target Group arn:aws:elasticloadbalancing:ap-northeast-1:0000:targetgroup/hogefuga-31509-HTTP-c3a0606/9914a217042c4006
[ALB-INGRESS] [echoserver/echoserver] [INFO]: Fetching Rules for Listener arn:aws:elasticloadbalancing:ap-northeast-1:0000:listener/app/hogefuga-echoserver-ech-2ad7/17fd1481cb40fcc2/0fe42e9436e45013
[ALB-INGRESS] [echoserver/echoserver] [INFO]: Ingress rebuilt from existing ALB in AWS
  • URL を確認
$ kubectl describe ing -n echoserver echoserver
Name:             echoserver
Namespace:        echoserver
Address:          hogefuga-echoserver-ech-2ad7-126540505.ap-northeast-1.elb.amazonaws.com
Default backend:  default-http-backend:80 (100.96.27.7:8080)
Rules:
  Host                    Path  Backends
  ----                    ----  --------
  echoserver.example.com  
                          /   echoserver:80 (<none>)
Annotations:
Events:
  Type    Reason  Age   From                Message
  ----    ------  ----  ----                -------
  Normal  CREATE  2m    ingress-controller  Ingress echoserver/echoserver
  Normal  CREATE  2m    ingress-controller  hogefuga-echoserver-ech-2ad7 created
  Normal  CREATE  2m    ingress-controller  hogefuga-31509-HTTP-c3a0606 target group created
  Normal  CREATE  2m    ingress-controller  80 listener created
  Normal  CREATE  2m    ingress-controller  1 rule created
  Normal  UPDATE  2m    ingress-controller  Ingress echoserver/echoserver

ここからさらに踏み込んで external DNS の設定がありますが今回は、ALB までで閉じます。
最後に cURL で確認して終了です。

$ curl hogefuga-echoserver-ech-2ad7-126540505.ap-northeast-1.elb.amazonaws.com
CLIENT VALUES:
client_address=10.1.93.88
command=GET
real path=/
query=nil
request_version=1.1
request_uri=http://hogefuga-echoserver-ech-2ad7-126540505.ap-northeast-1.elb.amazonaws.com:8080/

SERVER VALUES:
server_version=nginx: 1.10.0 - lua: 10001

HEADERS RECEIVED:
accept=*/*
host=hogefuga-echoserver-ech-2ad7-126540505.ap-northeast-1.elb.amazonaws.com
user-agent=curl/7.43.0
x-amzn-trace-id=Root=1-5a2d4e2f-5545b75b74003cd80e5134bb
x-forwarded-for=192.168.100.10
x-forwarded-port=80
x-forwarded-proto=http
BODY:
-no body in request-
  • 最後は、削除
$ kubectl delete ns echoserver
namespace "echoserver" deleted

ALB も削除される。

$ curl hogefuga-echoserver-ech-2ad7-126540505.ap-northeast-1.elb.amazonaws.com
curl: (6) Could not resolve host: hogefuga-echoserver-ech-2ad7-126540505.ap-northeast-1.elb.amazonaws.com

続きを読む