はじめに AWS CodeBuildを用いてDocker build および EKSヘのデプロイを行うサンプルです。 GitHub Enterprise(GHI)へのPushをトリガーにCodeBuildをkickしてみます。 ※当初は、CodePiplelineでGHEへのPushトリガーを受けようと考えていたのですが、CodePipelineはGHEに対応していないらしく、CodeBuildのみでまかなうことにしました。 前提 Date : 2020/2 時点 EKS Kubernetes version: 1.14 ImageリポジトリはECRを利用し、かつセットアップ済み (ECRの設定は本記事には記載しない) EKSはセットアップ済み(EKSの設定は本記事に記載しない) GHEへアプリケーションソースコードおよびDockerfileを格納済み(すでに存在する前提) リポジトリ直下

こんにちは。てぃろです。 CloudFrontのキャッシュ（chache）をうまく使えてますか？ CloudFrontではWebアプリ配信のレスポンスをよくするためにキャッシュを使えます。しかし、アプリを新たにデプロイする時にはキャッシュをクリア（削除）しないと、古いアプリのまま使われてしまう恐れがあります。 そこで、アプリをデプロイするたびにCloudFrontのキャッシュを自動的にクリアできるようにしたいと思います。 CloudFrontのキャッシュ詳しい仕様は公式ドキュメントをご覧ください。 今回も自作のアプリフレームワークを題材に解説していきます。以下がフレームワークの概要説明の資料です。 CloudFrontのキャッシュクリアの操作をマネジメントコンソールで確認するまず、CloudFrontのキャッシュクリアの操作がどのようなものか見ていきます。 突然ですが、公式ドキュメントやマ

AWS DevOps Blog CI/CD on Amazon EKS using AWS CodeCommit, AWS CodePipeline, AWS CodeBuild, and FluxCD This post discusses how we can speed up the development of our Kubernetes infrastructure by using a continuous integration (CI) pipeline to build our Docker images and automatically deploy them to our Amazon Elastic Kubernetes Service (Amazon EKS) cluster using FluxCD and the GitOps philosophy as

はじめに おはようございます、もきゅりんです。 先日、EKSでWeave Fluxを使ってGitOpsしてみる によって、かなり楽にk8sでCI/CDを体験することができました。 しかし、実用の場面ではstg, prodといった複数の環境ごとに設定の調整することを考慮しなくてはなりません。 ということで、Kustomize *1 を使ったFluxでGitOpsを再びEKSでやってみました。 Using Flux with Kustomize を元に進めていきます。 このチュートリアルのシナリオとしては、staging と production と2つのk8s clusterがあり、それぞれに設定される最小のpod数がstgが1つ、prodが2つとなっていますが、この稿では、1clusterで2回デプロイすることで対応します。 環境について EKS Workshpの GETTING STAR

こんにちは、かたいなかです。 Kubernetesを仕事で触っていて、CodePipeline/CodeBuildとKustomizeを組み合わせての継続的デプロイを検証する機会があったので備忘録として記事にまとめてみます。 Kustomizeとは KustomizeはkubernetesのYAMLファイルをパッケージングするツールです。ベースの構成をもとにSTG/PRDなどの環境ごとに変えたい設定などを上書きすることができます。Kustomizeで生成されたYAMLを、kubectl applyする形で使用します。将来的にkubectlへの統合が前提に開発されているそうです。 今回はこのKustomizeをCodePipeline/CodeBuildと組み合わせて使用し、継続的デプロイできるようにしていきます。 パイプラインの構築 今回は以下の図のようなパイプラインを組んでいきます。 前

はじめに こんにちは、久住です。 静的WebコンテンツをS3で公開する際、「誤った資材を公開しない」、「バージョン管理を適切にしたい」、「承認プロセスをはさみたい」等、考慮事項が増えてくると思います。 今回はCodeCommitとCodePipelineを使った承認プロセスをはさんだ自動デプロイを試してみました。 構成 静的Webコンテンツ構成は一般的なCloudfront -> S3の構成にしています。 CloudfrontとS3間の通信はHTTPSとしたかったのでS3の静的Webサイトホスティングは無効にしています。 本構成は下記の流れをイメージしています。 エンジニアがローカルリポジトリで作業し、CodeCommitにpush（もしくはbranchからマージ） CodePipelineが検知してSNSで管理者に通知、承認レビュー 承認OKとなったらS3にデプロイ Cloudfront

CodeStarでさくさくCI/CD作りもいいのだが、とりあえず一旦はCodeCommitからDeployまでCodePipelineで連携する方法を理解しておこうと思ったので、軽く試してみた。 CloudFrontで配信するところまでやってみる。 やること CodePipelineを利用して、CodeCommit, CodeBuildを連携させ、ReactクライアントをS3にアップロードする（デプロイ）。 S3に配置されたReactクライアントをCloudFrontで配信する。 やる順番 CodeCommitでリポジトリを作成 CodeBuildでビルドの設定（テストの設定とかはしない） CodePipelineでCommitからDeployまでを一貫して行う(S3へビルドファイルをアップロード) CloudFrontでコンテンツを配信(細かい設定はしない) CodeCommitでリポジ

はじめに ある日、EKSで新しいServiceを作ろうとしたところ、Subnet内に利用可能なPrivateIPが足りずに失敗した。 Warning CreatingLoadBalancerFailed 7m12s service-controller Error creating load balancer (will retry): failed to ensure load balancer for service xxxxx: InvalidSubnet: Not enough IP space available in subnet-xxxxx. ELB requires at least 8 free IP addresses in each subnet. このSubnetのサブネットマスクは255.255.255.0なので、256弱のPrivateIPが使えるはずであるが、

2021年3月11日〜12日で開催の「CloudNative Days Spring 2021 Online」における発表資料です。 3月12日 15:20-16:00 Track B 「地雷を避けながら進むEKS - 俺の屍を超えていけ -」 https://event.cloudnativedays.jp/cndo2021/talks/491 ｰｰｰ サクッとK8sクラスターを作れるAmazon Elastic Kubernetes Service（以下EKS）ですが、ちょっと真面目に使おうとすると色々と「あるぇ？」ってなることにもポツポツ出くわします。 今回は、EKSが持つ機能もちょこちょこ紹介しつつ、地雷っぽいところ（私が踏み抜いたもの）とかTipsなんかをお話しします。主に初級〜中級あたりの視聴者をターゲットにしています。 これからちょっと本気出してEKS使っていくかぁ！っていう

お仕事でAWS環境を構築する機会がありましたので、今回はじめてCDKを使って構築してみました。CDKで環境構築する記事はたくさんありますので全体は割愛するとして、本記事ではCDKを使ったECS(Fargate) Serviceのデプロイフローにフォーカスしてご紹介します。 バージョン $ cdk version 1.32.0 (build 9766ad6) 全体構成 全体構成としては、以下の図のようにオーソドックスなWeb3層アプリケーションの構成です。 ECS Serviceに関連する主なリソース構成を以下の図に示します。 このリソース構成のうち、緑色の線で示したリソースはインフラ管理用のCDKで管理し、オレンジ色の線で示したリソースはECS Serviceデプロイ用のCDKとしてアプリケーションのリポジトリで管理しています。 デプロイフロー デプロイフローを以下の図に示します。 Git