血と汗となみだを流す

クラウドエンジニアになるための修業の場

Amazon ECS(EC2 Container Service)のネットワークモードについて

概要

  • Amazon ECSのtask definitionを作るときに選択する「ネットワークモード」について調べた

ネットワークモード

none

  • 起動タイプ: EC2のみ
  • コンテナから外部へアクセスはできない
  • ポートマッピングは無効

bridge/default

  • 起動タイプ: EC2のみ
  • コンテナは仮想ブリッジdocker0を使って通信する
  • コンテナインスタンスの外と通信するときは仮想ブリッジを使ってコンテナインスタンスのNetwork Interfaceを使う
  • そのため、複数コンテナが起動しているとNetwork Interfaceを共有する
  • ポートマッピング有効
  • Windowsで唯一サポートされるモード

host

awsvpc

  • 起動タイプ: EC2/Fargate
  • task definitionにNetwork Interfaceを割り当てる
  • ポートマッピング有効

Developers.ioの記事を読んでやってみる「AWS Cogito + API Gateway」

対象

やってみる

前提

  • 機能を理解するのが目的なので、terraformは使わずにAWSコンソールからポチポチ
  • ローカル環境はMac

Angular SPA でログインし、API Gateway を呼び出す

手順

  • 認可不要の API を定義し、SPAからデータを取得してみる
  • Cognito User Pools を作成し、新しいユーザーを用意する
  • Cognito User Pools から払い出された IDトークンが必要になるよう API Gateway に制限をかける
  • SPA にサインイン機能を追加する
  • SPA から制限付きAPIをコールする

準備

ローカル環境でもSPA(Single Page Application)を検証できるようにする

$ brew install npm
  • angular-http-serverをインストール(グローバルインストールしたら ng new でプロジェクト作れなかったのでグローバルインストールはしなかった)
$ npm install angular-http-server
  • Angular CLIインストール
$ npm install -g @angular/cli
  • Anglura CLIバージョン確認
$ ng -v
  • 存在感がすごい
➜  spa ng -v

    _                      _                 ____ _     ___
   / \   _ __   __ _ _   _| | __ _ _ __     / ___| |   |_ _|
  / △ \ | '_ \ / _` | | | | |/ _` | '__|   | |   | |    | |
 / ___ \| | | | (_| | |_| | | (_| | |      | |___| |___ | |
/_/   \_\_| |_|\__, |\__,_|_|\__,_|_|       \____|_____|___|
               |___/

Angular CLI: 1.7.4
Node: 9.11.1
OS: darwin x64
Angular:
...
- プロジェクト作成

$ ng new cognitotest

- プロジェクトをbuild

$ cd cognitotest $ ng build

- HTTPサーバ起動

$ cd dist $ angular-http-server

- `http://localhost:8080/` にアクセスして確認
[f:id:Anorlondo448:20180425062759p:plain]

### TypeScriptインストール
- インストール

$ npm install -g typescript



## 認可不要のAPIを使ってDynamoDBのデータを取得する
- [Amazon DynamoDB のデータを API Gateway と Angular( D3.js ) でサーバーレス可視化する](https://dev.classmethod.jp/server-side/serverless/visualize-dynamodb-serverless/)を見ながら作る
### Angular + D3.js でデータ可視化の準備をする
- tsファイルを作成

$ cd cognitotest/dist $ touch data.ts $ touch vote-bar-chart.ts

- 実装(ソースコピペ)
- 

Tech-on MeetUp#01「開発現場に効くサーバーレス」に参加しました!

概要

このイベントでGETしてきたもの

  • lambdaのBlueprintsに「slack-echo-command-python」というのがある
  • ServerlessFramework
    • サーバレス関連のリソースを良い感じに管理してくれる
  • ローカルでサーバレスの検証をするため、lambdaのコードをWebサーバでも動くようにラップして可搬性を高める
  • 24/365という無敵のサービス

以下、概要メモ書き

Tech-onとは

  • ホンモノのナレッジは人と人との緩いつながりの中にこそある
  • テーマを特定の技術に限定しない
  • 開発の現場にいる技術者が登壇
  • slideshareで公開されるのでバシャバシャ撮影しなくてよし

NG

  • 製品紹介や広告は原則禁止

資料

明日から始めるちょい足しλ

  • 中丸 良@SUPINFさん
  • 開発現場に効くサーバレス
    • 改善策を探していたら、結果的に
  • AWS Lambdaは想像以上に難しい
  • メンテナンスし続けるコスト、まったくもって無視できない
  • 研究、PoC期間をちゃんと設けて小さめにスタート

社内の情報共有に

  • どこにどんな情報があるか
  • labmdaのBlueprintsに「slack-echo-command-python」というのがある

秘密情報の共有

  • デフォルトのBlueprintsになかったらOSSを探そう

Githubの歩き方

  • 調査段階でawesome-serverlessなどで探すのは有用

lambda@edge

  • AWSのCLoudFront上で動くlambda

運用プロセスも改善したい

  • 開発プロセス全般のソリューションとして使えるサーバレスがawesome-xxxにある
  • 安易に自作しようとしない
  • 新技術を研究する時間は別途とり、かつ成果は義務付けない

おすすめ

  • ks888/LambStatus
  • lambci/lambci
  • prismagraphql/chromeless
  • grycap/scar
    • lambdaでdocker動かす

運用のためのヒント

  • CI/CDパイプラインを組む
  • CloudWatchで監視

社内からの声

  • 「それサーバレスにした理由は?」を確認しよう

ローカル環境で気軽にはじめるサーバーレス

  • TatchNicolasさん

資料

サーバレスを始める時の悩み

  • 各種申請

身近で怒った悲劇

  • 無限ループによる高級請求
  • 定期実行の単位違い
  • ローカルで手軽に試したい・・・

ローカルで動かすには

擬似的なクラウド環境

  • AWS
    • SAM CLI
    • DynamoDB local
  • OSS

    • Serverless Framework
    • localstack
  • 擬似的なクラウド

    • dockerで起動
    • インターネットがないところでもサーバレスが検証可能

可搬性を高めるパターン

  • 任意のWebサーバで受けられるようにする
  • lambdaのコードをWebサーバでも動くようにラップして可搬性を高める
  • ラップする
  • 使えるツール、フレームワーク
    • awsgi
    • Zappa
  • Faas以外にも移動できる
    • ベンダーロックイン回避

QA

  • フレームワークにイベントを擬似的に発行できる機能がある
    • 連続してイベント発行は厳しい

KDDIとCI/CDの歩み

  • 廣田 翼@KDDIさん

概要

  • CI/CDをどのように浸透させて
  • どのような課題があって
  • どのように解決したのか

CI/CI概論

  • Continuous Integration
  • Continuous Delivery

CI/CDの効果

CI

  • 常に出荷可能な品質を維持できる

CD

  • 常にサービス提供/更新できる状態を保てる

導入

  • プロジェクト初期にCI/CD導入を目指す
  • プロジェクト/プロダクトの特性に応じたCI/CDを作っている

課題/対応

  • デプロイ作業が属人化
    • GithubEnterprise + Jenkins
  • CI/CDの設定自体もコード化
    • Jenkinsの設定をコード化
  • CI/CDに詳しい人材の不足
    • 詳しい人材を流動的にした

普及のポイント

  • 成功事例を作る
  • 理解している人材をプロジェクトに参加させる

QA

  • 県境毎にbranchがあり、そこにpushされたらデプロイが走る

StepFunctionsを一撃でデプロイする 〜 ServerlessFrameworkを用いたパッケージング 〜

  • 若松 剛志@アイレットさん

概要

  • サーバ管理サーバのサーバ管理はしたくない

ツール

  • Lambda
  • StepFunctions
  • ServerlessFramework
  • CodeDeploy

内容

とりあえずlambdaでやってみた

  • 制限が厳しい
  • 5分制限で落ちる

StepFunctionsがあるじゃん

  • 複雑に・・・
  • 1lambda1Functionになった
  • コケたポイントがわかる
  • リトライなどの制御が楽
  • JSONが辛い

ServerlessFramework

  • Serverlessに特化した構成管理ツール
  • YAMLで管理
  • 設定/コードが一箇所になった
  • JSONYAML変換が辛い
  • SF自体の改善点が多い
    • Role名で指定できないなど

監視

  • 24/365
  • lambdaのエラーハンドリングが難しい
  • エラーが起きる想定で対応するということで落ち着いた

結果

  • サーバの管理から開放された
  • 運用自体はなくならない
  • 構成管理が見える化した

課題

  • CI/CD
    • deployの均一化

多分日刊IT問題(DynamoDBの制限)

問題

  • 皆大好きDynamoDBの説明で、誤っているものはどれか?!

選択肢

  1. 読込/書込キャパシティの変更は無制限にできる
  2. AutoScaleを使ってScaleUpした後、リクエストがないとScaleDownしないまま同じキャパシティを保った状態になる
  3. 読込/書込キャパシティ/ストレージ容量/データ転送量で課金される
  4. 開発用のローカルバージョンがある

解答

  • 誤っているものは「1.読込/書込キャパシティの変更は無制限にできる」でした!

解説

1. 読込/書込キャパシティの「減少」には制限があります

  • なんと、増加は無制限なのですが、減少は1日に実行できる回数が決まっているんですよね・・・
  • 参考
  • AutoScalingを設定しているときも同じ制限が適用されるようです。
  • AutoScaleするから安心!とか思っていると、減少の制限に引っかかってキャパシティが下がらないまま!というのがあり得るよ!
  • キャパシティ管理は別途CloudWatch Alertを設定しておいたほうが良いかと思います。

2. AutoScaleを使ってScaleUpした後、リクエストがないとScaleDownしないまま同じキャパシティを保った状態になる

  • これも注意ポイントなのですが、ScaleInは、リクエストがトリガーとなって行われます。
  • つまり、ScaleUpしたあと、全然アクセスがないとUpしたキャパシティを維持し続けるので料金やべぇ!ってなるわけです。
  • Lambdaなどを使って定期的にping/pongさせてキャパシティをDownさせる仕組みが必要かも・・・

3. 読込/書込キャパシティ/ストレージ容量/データ転送量で課金される

  • 「キャパシティだけに料金がかかる」とずっと思っていましたが、テーブルが使用するディスク容量でも課金されるようです。(知らなかった)
  • 東京リージョンだと月額「1 GB あたり最低 0.25 USD」のため、そこまで気にしなくてもよいかもしれません。

4. 開発用のローカルバージョンがある

  • ローカル開発用のものがあります!
  • これを使えば、開発時の課金を気にしなくて済みますね!
  • ちなみに俺はローカル環境は常に読込/書込キャパシティを10000(MAX)にしていましたが、ローカルのキャパシティは設定しても無意味っぽいです。(速度は変わらず)

まとめ

  • 今回はDynamoDBでハマったポイントについて出題してみました!
  • マネージドサービスで便利は便利なのですが、いろいろと制限があるので、利用用途によっては使えなくなる可能性があります。
  • 用法・容量を守って使いましょう。

多分日刊IT問題(Private Subnetからインターネットへの通信)

問題

  • VPC内に図のような構成を作り、EC2(bastion)経由でEC2(application)にSSHログインし、yum installを行ったところインターネットとの通信ができませんでした。
  • EC2(application)からインターネットに通信するために修正が必要な箇所はどれか?!

構成図

f:id:Anorlondo448:20180622054125p:plain

選択肢

  1. InternetGateway
  2. EC2(bastion)
  3. ELB(CLB)
  4. NatGateway

解答

  • 修正が必要な箇所は「4.NatGateway」になります。

解説

  • 正解の構成は「NatGatewayをPublic Subnetに配置する」形になります。
  • VPCの外(インターネット)と通信するためにはInternetGatewayを経由する必要があります。
  • 構成図を見ると、EC2(application)はPrivate Subnetにいるため、InternetGatewayと直接通信することができません。
    • (Route Tableの通信先にInternetGatewayが指定されているSubnetをPublic Subnetと呼びます)
  • そのためPrivate Subnet外に通信する方法としてNatGatewayを経由する必要があります。
  • ですが、この構成図だとNatGateway自体もPrivate SubnetにいるためPrivate Subnetから外にでれません。
  • NatGatewayをPublic Subnetに配置し、Private SubnetのRoute TableにNatGatewayへの経路を指定するとEC2(application)→NatGateway→InternetGatewayという経路でインターネットへアクセスすることが可能になります。
    • (NatGatewayはPublic SunetのRoute Tableを見てInternetGatewayを外部への通信先として認識する)
  • NatGatewayをつい通信元と同じPrivate Subnetに置いてしまいがちですが、NatGatewayはPublic Subnetに配置しましょう!

構成図(正解)

f:id:Anorlondo448:20180622053955p:plain

まとめ

  • ということで、今回も俺(とチームメンバーほぼ全員)がハマったポイントを問題にさせて頂きました。
  • みなさん俺達と同じ落とし穴にはこれでもう落ちませんね!

参考リンク

【10 分間チュートリアル】仮想マシンへコードをデプロイするをやってみる

概要

やったやつ

内容

  • Get Start f:id:Anorlondo448:20180621065845p:plain

  • サンプルデプロイ選択 f:id:Anorlondo448:20180621070100p:plain

  • サンプルなのでインプレースデプロイを選択

  • ELB配下に複数EC2がついているときはBlue/Greenがよいのかな f:id:Anorlondo448:20180621070133p:plain

  • デプロイ先のEC2インスタンスを作成 f:id:Anorlondo448:20180621070536p:plain f:id:Anorlondo448:20180621070608p:plain f:id:Anorlondo448:20180621070627p:plain

  • デプロイするアプリケーションの設定 f:id:Anorlondo448:20180621070640p:plain f:id:Anorlondo448:20180621070717p:plain

  • デプロイグループの設定

  • デプロイ先のEC2の設定っぽい f:id:Anorlondo448:20180621070732p:plain

  • CodeDeploy用のIAMロール作成 f:id:Anorlondo448:20180621070811p:plain

  • デプロイ設定

  • デプロイグループに対して、どのような状態になれば成功かを定義 f:id:Anorlondo448:20180621070837p:plain f:id:Anorlondo448:20180621070912p:plain

  • デプロイ開始 f:id:Anorlondo448:20180621070927p:plain f:id:Anorlondo448:20180621070948p:plain f:id:Anorlondo448:20180621071001p:plain

  • チュートリアルはここまでで、あとは「EC2インスタンス消しとけよ」という手順のみ。

まとめ

  • ほんと触りをやるだけ
  • 10分じゃ終わらなかった
  • EC2のどこにデプロイされんの?
    • デプロイするリビジョンのルートに、設定ファイル(yml?)をおいておくっぽい?
  • 一部最新のリソースに対応していない箇所があった
    • デプロイ方法の洗濯など
  • 正直、「理解した!」とまで行かないかも。
  • 中身までしっかりやるにはDevelopers. IOを見たほうが良さそう。

AWS Certified Developer - Associateへの道①(リソース上限)

Q5. リソース上限