4年間のEKS移行の取り組みを振り返って | gihyo.jp
『家族アルバム みてね』（以下、みてね）では、サービス開始当初よりAWS OpsWorksをオーケストレーションツールとして利用してきました。 しかし、サービスや組織の拡大に伴い、AWS OpsWorksによる運用上の課題が生じてきました。そこで、2018年ごろにAWS OpsWorksからAmazon EKSに移行するという意思決定を行いました。 その後、たくさんの試行錯誤や紆余曲折、回り道を経て、2021年にAmazon EKSへの移行が完了しました。 この記事では、4年近くに渡ったEKS移行の取り組みを時系列を追って紹介していきます。 その過程には、後に取りやめることになった設計や意思決定も多く含まれています。 記事の最後でEKS移行プロジェクトを振り返り、そこから得た学びをまとめます。 図 『家族アルバム みてね』のEKS移行のタイムライン AWS OpsWorksの課題とEKS
メルペイのマイクロサービスの構築と運用 / CloudNative Days Tokyo2019
メルペイのマイクロサービスの構築と運用 2019.07.22 に CloudNative Days Tokyo2019 で発表した内容です。 なぜメルペイがマイクロサービスアーキテクチャを選択したか、メルペイのマイクロサービスの構築と運用をどのように行ったか、などを話しました。
SpotifyがミスによりKubernetesの本番クラスタを二度も削除。しかし顧客へのサービスにほとんど影響しなかったのはなぜか？
SpotifyがミスによりKubernetesの本番クラスタを二度も削除。しかし顧客へのサービスにほとんど影響しなかったのはなぜか？ 今年、2019年5月20日から3日間にわたりスペイン バルセロナで開催されたKubeCon＋CloudNativeCon Europe 2019の基調講演では、SpotifyがミスによってKubernetesのクラスタを消去してしまった経験を振り返るという非常に興味深いセッション「Keynote: How Spotify Accidentally Deleted All its Kube Clusters with No User Impact - David Xia」（基調講演：SpotifyはいかにしてKubernetesクラスタの全削除というミスにもかかわらず顧客への影響を引き起こさなかったのか？）が行われました。 障害が起こることをあらかじめ計画とし
Terraformを使ってEKSを作成してみた | DevelopersIO
はじめに おはようございます､加藤です｡Terraformを使ってEKSを作成してみました｡ やってみた 解説 コードはGitHubにアップしています｡すぐにデプロイしたい場合はクローンして使用してください｡ vpc.tf data "aws_availability_zones" "available" {} resource "aws_vpc" "vpc" { cidr_block = "${var.vpc_cidr_block}" enable_dns_hostnames = true enable_dns_support = true tags = "${merge(local.default_tags, map("Name", "${local.base_name}-vpc"))}" } resource "aws_subnet" "subnet" { count = "${va
Terraformを使ってEKSを構築する - APC 技術ブログ
始めに 先進サービス開発事業部の山岡です。 Terraformを使ったEKSの構築を試してみる機会があったのでEKSに関する解説とコード、注意が必要と思ったポイントについて書きたいと思います。 EKSの解説 EKSは何をしてくれるのか？ EKSはKubernetesのマスターノードを管理してくれるサービスです。一度やってみるとすぐわかるかと思いますが、自分でマスターを構築・運用するのはかなりの手間でありそれを省くことができます。また、AWSの各種サービスと連携させることができるため、その作り込みに必要な手間も削減することができます。 EKSでマスターを作成するとkubectlで使用する認証情報、マスターのエンドポイントが発行され、内部の実体がどのようなものであるかは隠蔽された形になっています。感覚としてはRDSの扱いに近いでしょう（EKSの場合インスタンスサイズやディスク容量の指定はありま
TerraformでKubernetesのリソース(ConfigMapやSecretなど)を管理する - Qiita
TerraformはAWSなどのIaaS上でインフラを構築、管理するためのツールとしてよく使われてます。 一方、公式プラグインとしてKubernetesのリソースを管理するためのProviderが提供されており、これを使ってKubernetesのリソースを管理すると結構便利だったので紹介します。 kubectlでリソースを直接いじるのに比べると、 terraform planでDryRunできる その際、もちろん既存のリソースとの差分を見ることができる リソース同士の参照(Docker RegistryのSecretをPodから見るとか)をコード上で表現でき、参照が壊れてると実行前にエラーにできる 変数や関数、モジュールを使用して定義を共通化できる terraform destroyで全部なかったことにできる あたりがメリットでしょうか。 では、以下Mac上にインストールしたminikub
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
