EC2からFargateへの移行 ~shadow proxyとカナリアリリース~ | GREE Engineering
こんにちは、メディア事業でエンジニアをしている木村洋太です。 昨年のGREE Tech Conferenceでは「LIMIA」のフレームワーク移行プロジェクトにおけるコードの自動修正について話させていただきましたが、今回は同時に行ったインフラ移行について紹介いたします。 EC2からFargateへの移行例は多く存在しているとは思いますが、今回の移行では安全な移行のために、shadow-proxy環境での移行前のテストやEC2とFargateの同時稼働によるカナリアリリースなどさまざまな工夫を行いました。これらの中で得られた知見や失敗をまとめられたらと思っています。 インフラ移行の概要 フレームワーク移行プロジェクト フレームワーク移行プロジェクトでは、グリーが運営するメディアの一つである「LIMIA」のフレームワークをFuelPHPからLaravelへ移行することを目的としていました。 移
本番稼働を意識したECS Fargateを用いたFastAPIの環境構築（ALB、SSM、BlueGreenデプロイ） - Qiita
本番稼働を意識したECS Fargateを用いたFastAPIの環境構築（ALB、SSM、BlueGreenデプロイ）DockerECSCodeDeployFargateFastAPI 0. 背景 ECS Fargateは、2018年に東京リージョンでの提供街開始され、サーバーやクラスターを管理することなくコンテナを実行することができる、いわゆるサーバーレスの実行環境です。Fargateの特徴の詳細はこの記事では述べませんが、使ってみたい技術ではあるものの、コンテナにログインしてデバッグするなどができず、本番環境での利用は躊躇してきました。コンテナに入ることができないというのはセキュリティ面ではメリットであるものの、本番で再現したバグのデバッグなどは直接入ってデバッグしたいという思いは出てくるものです。きちんとテストした上でデプロイし、またログを適切に吐かせることでコンテナに入らなくてもデ
Self-Hosted Cluster から EKS への移行と Platform の Production Readiness - スタディサプリ Product Team Blog
こんにちは。SRE の @chaspy です。 Quipper では AWS 上で Kubernetes Cluster を運用してサービスを提供しています。 これまで kube-aws を用いて Kubernetes Cluster を Self Host してきましたが、このたび Managed Services である Amazon EKS に移行しました。（以下、 Amazon EKS を EKS と表記します） 本記事では、 Kubernetes Cluster の移行で遭遇した問題をどのように解決したかを説明します。また、数多くの Application が稼働している Platform を移行する際にどのような点を考慮するとよいのか、経験を通して学んだことを共有します。 EKS への移行を検討している方はもちろん、Platform Migration に携わる方にとって学びに
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
