AWS Fargateが7/4にTokyoリージョン対応!!
「夏のAWS Fargate & Amazon ECS/EKS 祭り」やります！AWSでのコンテナ利用に興味ある方はぜひご登録ください！ #aws https://t.co/I8wi0Kt7fT
— Atsushi Fukui (@afukui) July 20, 2018
というわけでコンテナお兄さんになれるようAWS主催である!!
夏の AWS Fargate & Amazon ECS/EKS 祭り
に行ってきたのでブログしやす(メモレベル)
■講演内容
https://pages.awscloud.com/AWSFargateAmazonECSEKSmatsuri20180803-jp.html
AWS Fargate,ECS,EKSなどの最新情報やデプロイ方法など
一貫して知見が高まるイベントとなります。(激アツか!)
■オフィス前の家系ラーメン
オフィスに行く前に我々(@kzm0211,@m_on_yu)は腹を空かしているので、
目黒の有名な家系ラーメン「麺屋 黒」にて満たしました。
野菜ラーメンは二郎並の量なので気をつけましょう！
にしてもうまい。オフィスへ向かいます！
移転したようでめちゃくちゃデカイしキレイだしなんなの
と言いたいくらいスケールのデカさにびびりました…21Fへ向かいます。
■ AWS Fargate & Amazon ECS/EKS 最新情報
AWSの@Keisuke69さんによるFargateやECS/EKSの概要のセッションでした。
初心者の方にもアーキテクチャなど分かりやすく学べやすっ。
- コンテナを利用した開発の実際ってどうなの
- なぜコンテナなのか→起動早い、繰り返しに強い、コスト効率
- コントロールプレーン→どこで動かす、いつ止める？
- デプロイ時にどういう風に配置すればいいのか→ECS/EKS
- データプレーン→実際にコンテナが可動する場所
- EC2→1台のサーバに入れるのは簡単 複数だと→どーすんの？ECSです
- cloudwatch logs連携可能/イベントが流れる
- アプリケーションの開発に集中したいからインフラエンジニアいらないよね？
- 7/4にFargateリリース
- インスタンス管理不要、バッチ管理がない
- タスクネイティブAPI→シンプルかつ強力で使いやすい新しいリソース消費モデル
- ECSのコントロールプレーンがそのまま使える
- タスクディフィニションにインスタンスタイプなどを定義する→terraformでも管理できる
- ネットワーキング→VPC
- Task ENI
- アウトバウンド/インバウンド
- ELBサポートしている
- クラスターパーミッション
- アプリケーションパーミッション
- ハウスキーピングパーミッション
- モニタリング
- cloudwatch logs/eventも可能
- ストレージ
- Fargate or EC2モード
- Fargateでは難しいもの↓
- windowsコンテナ対応してない
- docker ececのようなインタラクティブなデバック
- spotやRIベースの価格モデルの適用
- FargateよりLambdaを使うほうがいい場合↓
- イベントトリブン
- ミリ秒単位のコンピュート
- ランタイム管理をしたくない
- 分散バッチコンピューティング
- それ以外はFargate
- コンテナをauto scaleingさせる
- コントロールプレーンの課題
- データプレーンの課題
- メトリックスに対してターゲットの値を変更
- Fargate コンテナのみ
- EC2 インスタンス
- EKS 自前で構築するのは辛い
- Packer→AMI作るのもいいよ
■コンテナ化したアプリケーションをAWSで動かすためのベストプラクティス
AWSの@afukuiさんによるコンテナ内のアプリケーションの開発からのデプロイまでをCI/CDにフォーカスしたセッションでした。
にしてもよくECSを使ってる会社さんなどデプロイが超大変と聞きましたが、AWS CodePipelineを使えば超楽な印象でした。
- アプリのステートレス化
- レジストリ
- コントロールプレーン/データプレーン
- CI
- 12facter app
- レジストリ→ECR
- コントロールプレーン ECS
- データプレーン Fargate
- CI AWS codepipeline codebuild
- ECR→ライフサイクルポリシーの自動クリーンアップ
- ECS→task Definitionから起動
- Blue/Greenデプロイ
- ELBと連携可能
- Auto scalingも可能
- IAM Role task単位で権限のAWS認証が可能
- VPCネットワークモード
- わかりやすいネットワークモードで設定可能
- ベストプラクティス
- コンテナのauto scaling
- メトリックスベースで実施できる
- target trackingとの連携
- CPU50%以上ならなど
- fargetなら自動でコンテナが増える
- CI/CDパイプラインが重要なのか
- 誰がやってもデプロイ可能
- 差別化を産まない重労働
- codepipeline
- アプリケーションのすばやく信頼できるアップデートを可能にする継続的デリバリサービス
- 見える化
- githubとの連携も可能→まさにデプロイはこれだな
- AWS codebuild↓
- コンパイル、テスト、パッケージの生成
- 同時複数ビルドの実行
- VPCエンドポイントをサポートした
- AWS codecommit↓
- バックエンドはs3
- gitソース管理
- まとめ↓
- コンテナを利用することはメリットが多い
- コンテナへのCI/CDを簡単に実現可能
- Fargateはインスタンスの管理を不要として理想的なオートスケールも実現可能でアプリケーションに集中できる
- codepipelineを利用することでdockerイメージをaws fargateにノンコーティングでデプロイ可能
■日本のお客様によるAWS Fargate & Amazon ECS/EKS活用事例紹介
・サイボウズ
Kintone on EKS
サイボウズインフラエンジニアの@nojimaさんによるkintoneでのEKS活用方法のセッションでした。
- 0から環境が作れるよう自動化している
- オンプレも運用しているからkubernetesがよかった
- 手順をそのまま自動化すると脆いシステムになる→ロバストな自動化のためには理想状態への収束が必要
- EKSとCloudFormationを使ってフルスタックで理想状態への収束を行う
- git pushするたびにCIで変更を開発環境に適用kubernetesはオンプレでも使えるしkuberctlが便利
- ECSはAWSとのインテグレーションが強いのがメリット
- コントロールプレーンが無料
・エムスリー株式会社
AWS FargateでElixirのコンテンツ配信システムを運用してみた
エムスリーでアプリケーションエンジニアをやられている@ryoryoryoheiさんによるFargate化を行ったセッションでした。というかもうFagate使ってるとか早い！！
- ElasticBeanstalkからFagateへ
- アプリケーションからデプロイまで10分
- プラットフォーム変更にかかる時間が2分
- ローカル環境でテスト可能
- オーバヘッドがない
- CIはGitlab
- eb deployコマンドでデプロイ
- しかしビルドに40分
- AWS環境をコード化→terraform
- PlatformArnがサポートされてないのでツライ
- FagateでS3を起点としてCodePipelineによるデプロイを確立
- ビルド短縮
- コンテナはシングルプロセスなので監視検討中
・Datadog
EKS, Fargate, コンテナの運用監視は今までと何が違うのか？ よくある課題とその対策
https://www.datadoghq.com/docker-adoption/
コンテナの監視といえばDatafogが熱い！ライブコンテナモニタリングを使って、
コンテナ毎に2秒周期でメトリクスが更新されてリソースの状況確認できるといったことが話題になりましたね。
コンテナについてのレポートについては上記のURLを参考に！
■まとめ
よし!とりあえず概要など理解できたので、
AWS Fargate使ってこのブログリプレイスしようかな…
よりも実家にあるdockerサーバにkubernetes入れないとな..
次はAWSにあるボルダリングにチャレンジしよう！w
0件のコメント