プラットフォームの上でものを作るということ Amazon EKS Advent Calendar 2019 の最終日です. みなさまご存知の通り、AWS には Amazon ECS と Amazon EKS という2つのコンテナオーケストレーションに関するサービスがあります. ECS は2014年に発表された AWS ネイティブなコンテナオーケストレータ、EKS は OSS のコンテナオーケストレータである Kubernetes をマネージドな形で提供するサービスで、2017年に発表されました. 今日はこの Amazon ECS と Amazon EKS という2つのサービスについての話を書こうと思います. // 読んでくださっているみなさまをミスリードしないための DISCLAIMER 本記事の著者は AWS に勤めています. また、この記事には僕個人の意見や想いも強くこもっています.
エージェンシー事業でリードアプリケーションエンジニアを行なっている大窄 直樹 (おおさこ)です. AWSのログ, サーバーのログってたくさん種類があって難しいですよね... 同じようなログがたくさんあるので, 何を取れば良いのかとか どのくらいの期間保持すれば良いのかとか またその後の, ログの実装や, 分析方法する方法も難しいですよね... 今回AWSに構築した商用アプリケーションのログを整備する機会があったので, このことについて書こうかなと思います. 概要 本題に入る前の準備 今回ログ実装するアーキテクチャ ログに関する法令 ログの取得箇所 設計 保管するログの決定 インフラのログ OSのログ アプリケーションのログ ログの保管 保管場所について 保管期間について バケット構造 アプリケーション, OSのログの転送 実装 アプリケーション, OSのログをfluentbitを用いてS3
Terraform, Dockerfile, KubernetesなどIaCの脆弱な設定をCI/CDで検知する - knqyf263's blog
概要 自分の所属企業であるAqua SecurityがTFsecというOSSを買収しました。 blog.aquasec.com TFsecはどういうツールかというとTerraformの静的解析スキャナーです。Terraformの設定ファイルを渡すことでセキュリティに関する設定ミスを主に検知してくれます。 github.com そのアナウンスに伴い、TFsecは自分が開発している脆弱性スキャナーであるTrivyに統合されました。TrivyではTerraformに加えDockerfileやKubernetesなど、いわゆるInfrastructure as Code（IaC）の設定ミスを検知するマネージドポリシーも提供しています。他にもJSONやYAMLなど一般的なファイルフォーマットに対応しているため自分でポリシーを書くことでそれらの検知にも使えます。CloudFormationやAnsib
監視・通知の仕組みの全体像また、弊社では Terraform を用いて IaC ( Infrastructure as Code ) を実現して、各AWSアカウント環境の状態をコードで一元管理していますが、 Datadog の監視項目も Provider が用意されているため、Terraform で管理をすることが可能です。現状はすべての Datadog の監視項目がコード化されているわけではないですが、こちらは随時対応を行っていきたいと思っています。 外形監視外形監視は、WebサイトやAPIエンドポイントが正常に動作していることを、定期的に特定のURLに対して問い合わせをして、期待されたステータスコードや要素を返すことを監視することを目的とします。 弊社では Datadog の Synthetic Monitoring という機能を利用して監視を行っていますが、この機能の特徴としては W
全然たいした話ではないのですが、へーって思ったので記録しておきます。 ALB にて外部からの不正アクセスを塞いだ話になります。 はじめに注意 ※追記３ この記事は、知識不足な状態で始まり、知識不足なまま初出した未熟な内容であり、外部の助力によりそれが解決に向かう、という流れになっています。 調査環境がAWSだったために、タイトルがこうなっていますが、実際はALB+ACM単独の問題ではなく、SSL/TLS としての仕様の話になっている、 ということを念頭において、読んでいただければと思います。 ※追記３ここまで 構成と問題点 手動で作成された ALB → EC2 環境があって、ワイルドカードなACM を使って 0.0.0.0:443 のみ開いており、EC2 は Global からのアクセスは遮断してありました。 にも関わらず、不正系なHostヘッダでアクセスされた形跡があり、コイツどこから来
Datadogの活用ノウハウを一挙に公開・それを支える全社管理者の工夫とは #datadog_japan_meetup - ZOZO TECH BLOG
こんにちは。ECプラットフォーム基盤SREブロックの高塚と巣立（@tmrekk_）です。 ZOZOTOWNはクラウド化・マイクロサービス化を進める中で、監視SaaSのDatadogを採用しました。この数年で多くの知見が蓄積され、今では様々なシーンでDatadogを活用しています。この記事ではそのノウハウを惜しみなく公開します。 ※本記事は、先日開催されたDatadog Japan Meetup 2022 Summerにて発表した内容を書き起こして再構成したものです。 当日の発表資料 speakerdeck.com 目次 当日の発表資料 目次 はじめに マイクロサービス基盤に必要な監視の要件 第1部 ZOZOTOWNにおけるDatadogの活用 1. どこで障害が起こっているのか分からない → APM 2. アラートやダッシュボードや外形監視が欲しい → Monitors, Dashboar
こんにちは、インフラ部の id:sue445 です。 先日ピクシブ社内で利用しているGitLabをオンプレミス環境からGCPに移行しました。 とても長いので全3回にわけて紹介したいと思います。 全体の構成 前編：前置きとアーキテクチャ検討 中編：環境構築 後編：実際の移行作業とその前後の対応。移行後の所感など 今回の目次 全体の構成 今回の目次 tl;dr; 移行の理由 筆者略歴 GitLab移行の時系列 やったこと1: アーキテクチャ検討 構成図 GitLabをクラウドに移行するための障壁をまとめた URLをどうするか Cloud IAP利用時の通信のオーバーヘッドをなくしたい 実際にGCP移行した後の構成 AWSでPoC環境を作った時の構成 LDAPからの依存をやめたい＆複数のログイン方法を統一したい ssh接続時にあるLDAP依存を不要にしたい 余談 AWS移行案 GCP移行案 Gi
新規プロダクトでKubernetesを中心にCloudNativeなアーキテクチャのインフラを導入した話 | Tech Blog
新規プロダクトでKubernetesを中心にCloudNativeなアーキテクチャのインフラを導入した話 Tech Blog 2019.08.26 はじめに アドテク本部Airtrackチームの横山（@nnao45）です。 チーム内ではScala書いたり〜K8Sと遊んだり〜AWSったり〜しています。 この度Airtrackチームの新規プロダクトでKubernetesを採用し、本番環境に投入したのでその知見を共有させた頂きます。 おしながき 目指したアーキテクチャ Kubernetes周り ミドルウェア CI/CD 監視 感想 目指したアーキテクチャ 妥協はしないが身の丈にあったコンテナプラットフォーム って感じですかね。 Kubernetes周り サービスレイヤひとまわり Airtrackチームで広告系完全新規プロジェクトの立ち上げに Kubernetes中心にクラウドネイティブなアーキテ
Migrating from AWS to Fly.io TL;DR It was a pleasure migrating from AWS to Fly.io (opens in a new tab) but it's not all rainbows and unicorns. Fly.io goes above and beyond to create an exceptional developer experience. It's super easy to hit the ground running. However, there are some rough edges that you might encounter. If you like managing your own infrastructure and can live without stellar su
はじめに アクセス数がすごい環境は大抵高負荷環境でもあるので対策としてApacheの設定やサーバ構成のセオリーをすぐ見つけられて実際試しても目に見えて良くなります。 アクセス数の多さで起こる問題は実際に負荷をかけてみないと表面化しません。 問題が分かったら設定やパラメータを調整して現状がましになるようにするだけです。 ですが限りあるリソースの中でTCPセッションを十分にコントロールしようとするとすぐ手詰まりです。 WEBサーバがしているやりとりの基礎が足りていないそんな気がしていたのでTCPに目を向けてみました。 行き着いた結果は 待ち受け側とリクエスト側ではボトルネックが違う リクエスト時はTCPのエフェメラルポートが上限 待ち受け時はTCPよりもファイルディスクリプタが上限 になりやすい という良く見かける設定を見直すということになりましたが、どうやってそうなっているのかが今回の成果だ
ALB経由で公開するAPサーバに(リバースプロキシ用の)Webサーバーを利用する意味はあるのか？立ち止まって考えてみた | DevelopersIO
まずは、リフト＆シフトのリフトだ。オンプレ環境の構成を変えずにAWSでリプレイスするぜ。 静的コンテンツの処理はWebサーバーに任せてアプリケーションサーバーの負担を減らす構成だな。 次はシフトだ。だが大きくは変えない。静的コンテンツを外だしするところから始めよう。 あれ？Webサーバー(Nginx)っているんだっけ？？ALBではログも取れるし最近はでできることも多いよね？ [新機能] HTTPヘッダーやクエリ文字列などなどでルーティングができちゃう!!AWS ALBで高度なリクエストルーティングが可能になりました! 待てよ待てよ。将来的にはSPAで実装する方法も検討しているんだった。その場合はいらないでいいよね？ ということを社内チャットで呟きました。いくつか意見が出てきたのでこのブログにまとめます。 先に結論 コンテンツ（html）をAppサーバーで作成する場合、あったほうが良さそう
N予備校のバックエンドは、2016年のリリース当初からマイクロサービスアーキテクチャを採用しています。 この記事では、N予備校のマイクロサービスアーキテクチャについて、主にアプリケーション側の観点からご紹介していきます！ 目次 目次 N予備校の全体構成 なぜマイクロサービスにしたか？ 採用しているマイクロサービスのデザインパターン Decomposition/サービスの分割 Data management/データ管理 External API/外部API, Orchestration/オーケストレーション Communication/コミュニケーション Deployment/デプロイ, Service discovery/サービスディスカバリ 利用しているフレームワーク/サービス マイクロサービスの運用の難しさと今後の展望 課題: 責務の分割へのハードル 今後の改善方針 We are hi
Backlogのコードメンテナンス性を向上させるために気をつけたこと【Backlog Play化プロジェクト】 | Backlogブログ
ヌーラボの江口です。約8年間Backlogの開発を担当しており、BacklogをJavaからScala / Play Frameworkに移行するプロジェクトには最初から最後まで関わりました（プロジェクトの概要は時系列でみる！4年の歳月をかけてPlay Frameworkで「大規模リプレイス」した話をご覧ください）。 本記事では、BacklogのScala / Play Framework化プロジェクトで「Backlogのサーバーサイドを進化させる“土台”を作る」をテーマに、どのようにBacklogのアーキテクチャを設計・実装したのかご紹介します。 はじめに 私は2012年の入社以来、Backlogの開発を担当しています。Backlogは10年以上続くサービスであるため、度重なる機能追加や修正を行うことで複雑化し、日頃開発をする上で様々な問題を感じていました。 今回のBacklogのSca
AWS Elastic beanstalkからAmazon EKSへ移行する - 一休.com Developers Blog
以前の記事でも簡単に紹介した通り、一休では、アプリケーションのAWS Elastic beanstalkからAmazon EKSへの移行を進めています。 user-first.ikyu.co.jp この記事では、その背景や、実際の設計、実際にAmazon EKSを活用してみて気付いた点、困った点、今後の展望を紹介したいと思います。 AWS Elastic beanstalkの辛い点 新しい環境の構築や運用が大変 一休ではAWSのリソースをTerraformを使って管理しています。新しくウェブアプリケーションを立ち上げて、Elastic beanstalkで動かす場合、以下の作業をする必要があります。 Terraformで、Elastic beanstalkの定義を作ってリリースする。 新しいアプリケーションのデプロイを通知するように自前で作ったAWS lambdaを修正。 アプリケーション
Terraform AWS Provider Version 4がリリースされました | DevelopersIO
2022/2/11に Terraform AWS Provider Version 4がリリースされました。2/22現在、もうVersion 4.2まででています。実際に触ってみて何が変わったのか確認したいと思います。 aws_s3_bucketの大規模リファクタリング 要は「aws_s3_bucketがデカくなりすぎて大変だから、細かく分けようぜ！」ということです。 御存知の通りS3は非常に多機能です。そしてTerraformではその機能の殆どをaws_s3_bucketのattributeで設定していました。 以下はaws_s3_bucketのコード例です。 resource "aws_s3_bucket" "v3" { bucket = local.bucket_name acceleration_status = "Enabled" acl = "private" cors_rul
Introducing the AWS Load Balancer Controller | Amazon Web Services
Containers Introducing the AWS Load Balancer Controller The AWS ALB ingress controller allows you to easily provision an AWS Application Load Balancer (ALB) from a Kubernetes ingress resource. Kubernetes users have been using it in production for years and it’s a great way to expose your Kubernetes services in AWS. We are pleased to announce that the ALB ingress controller is now the AWS Load Bala
入門 EKS on Fargate - Qiita
プロダクションで EKS on Fargate を(できるだけ)使うことを目標に EKS on Fargate に入門します。 Managed Node Groupとの使い分けなどについてもまとめます。 ※ 本記事は 2019/12/14 時点の情報に基づいています。 Fargate、EKS on Fargateとは FargateはAWS上で「仮想マシンの管理なしにコンテナをデプロイできるサービス」です。 元々はAWS独自のコンテナオーケストレーションシステムであるECSの一機能と思われていましたが、EKS on Fargateが登場した今では、「ECS・EKSどちらでも動く、コンテナ化されたワークロード向けのサーバレスコンピュートエンジン」という体でブランディングされているようです。Fargateの公式ページ冒頭でも以下のように紹介されています。 AWS Fargate is a se
こんにちは、ななです。 皆さんはTerraformを使っていますか？ちなみに私は最近、Terraformを触り始めました。 今回はTerraformのAWSプロバイダに関して本日2019年12月14日にアップデートがあったため、早速試してみた話を書いてみます。 はじめに Terraformとは、HashiCorpにより作成されたInfrastructure as a Codeを実現するためのオープンソースなツールを指します。 Application Load Balancer (ALB) とは AWSが提供するElastic Load Balancing (ELB) というサービスにおいてサポートされ、かつOSI参照モデルの第7層 (アプリケーション層) で機能するものです。 (図引用元： https://docs.aws.amazon.com/ja_jp/elasticloadbalan
この記事では、Mackerelを使ったSLI/SLOによるサービス運用を紹介します。 SLI/SLOとは何か SLIの実装 SLOの設定 エラーバジェットとは さらに詳しく知るには MackerelでのSLI/SLO運用 SLI/SLOを策定する 可用性の計測 レイテンシの計測 ダッシュボードで定期的に状況を確認する 式による監視でモニタリングする SLI/SLOを運用と開発に活用するためには まとめ SLI/SLOとは何か SLI(Service Level Indicator)とはユーザーに提供したいサービスのレベル(水準)を計測する指標であり、SLO(Service Level Objective)とはSLIの目標値です。 サービスレベルを適切に定め、その指標(SLI)を実装・計測し、設定した目標値(SLO)を満たしているかどうかを定期的に確認することで、サービスレベルを適切に改善す
お疲れさまです。SREの西田和史(@k_bigwheel)です。 僕が所属するDX事業本部の開発基盤グループは主にインフラが安定して高いパフォーマンスで動くことに責務を持っています。 今DX事業本部には3つの事業部があり、その中ではイエウール、ヌリカエ、ケアスル介護などのサービスを展開していますので、僕らはそれらのだいたい10サービス前後のインフラを日々増築・改善しています。 僕がSpeeeにジョインしたのが3年前の2019年11月なのですが、それからDX事業本部のインフラは様々なことが進化しました。3年前から変わらず残っているインフラコンポーネントは永続化層1ぐらいといえる程です。ここではその差分を振り返ってこんな良いインフラになったぞ！という部分を書いていきたいと思います。 レガシーインフラの脱却 いきなりですが、3年前に使っていたツール・サービスと今使っているツール・サービスの対応表
【Unit4 ブログリレー 1日目】 Viteは"ヴィート"と読みます♫ もう覚えましたね♫*1 こんにちは、エムスリーエンジニアリンググループの山田(@Satoki_1226)です。 本日より、Unit4でもブログリレーを行うこととなりました。Unit4は医療系ポータルサイト m3.com の開発・運営を担当するチームです。Unit4エンジニアがリレー形式でテックブログを執筆し、どんなメンバーがいるのか・どのような開発をしているのかなど、ご紹介できればと思います。 トップバッターである私からは、m3ラウンジというサービスのVite移行時に得られた知見をもとに、 Vite/Vitestへの移行によって感じた「速さ」 移行時の手順とポイント をお伝えできればと思います。Viteが気になっている方や、Vite移行の進め方に困っている方にとって少しでも参考になれば幸いです。なお掲載しているサンプ
はじめに エンジニアの @eiryu と申します。 突然ですが、皆さんは Groovy というプログラミング言語はご存じでしょうか？JVM言語の1つであり、Javaの豊富なライブラリが使え、動的言語でもあるためちょっとしたスクリプトやツールを作るには便利です。 この記事では、実際に私が業務で作ったGroovyスクリプトについて紹介していきたいと思います。 環境情報 この記事の内容は以下の環境にて確認しています。 $ groovy -v Groovy Version: 2.5.0 JVM: 1.8.0_181 Vendor: Azul Systems, Inc. OS: Mac OS X $ awslogs --version awslogs 0.10.0 業務で実際に使った例 awslogsを使ってCloudWatch Logsから並列でログを取得する @GrabConfig(system
この1年の Amazon EKS アップデートを振り返る Amazon EKS Advent Calendar 2019 の1日目です. アメリカ時間だとまだ12/1なので許して… 他の AWS サービス同様、Amazon EKS もこの1年間で多くのアップデートを発表してきました. 本記事では、ざっくりとこの1年間の主なアップデートを振り返りつつ、いよいよ本日から開催される re:Invent に備えていこうではありませんかという、そんな目論見がございます. 日付順にアップデートを追って書いていたんですが、なんだか読みにくかったのでカテゴリごとに分けて書いていきます. 目次です. Security & Reliability Regions & Versions Nodes Storage & Networking Tooling Machine Learning その他 まとめ Sec
AWS for Fluent Bit による Kubernetes ロギング | Amazon Web Services
Amazon Web Services ブログ AWS for Fluent Bit による Kubernetes ロギング 集中ログは、Kubernetes クラスターを大規模に実行および管理するための重要なコンポーネントです。開発者はアプリケーションのデバッグとモニタリングのために、運用チームはアプリケーションのモニタリングのために、セキュリティはモニタリングのために、それぞれログにアクセスする必要があります。これらのチームには、ログの処理と保存に関する異なる要求事項があります。このブログ記事では、Amazon CloudWatch と組み合わせた AWS for Fluent Bit を使用してログを集中管理するソリューションを紹介します。 AWS for Fluent Bit は Fluent Bit 上に構築されたコンテナであり、ログフィルター、パーサー、およびさまざまな出力
Amazon EKS on Fargate で ALB Ingress Controller を使用する | Amazon Web Services
Amazon Web Services ブログ Amazon EKS on Fargate で ALB Ingress Controller を使用する 2019 年 12 月、Amazon Elastic Kubernetes Service を使用して AWS Fargate で Kubernetes ポッドを実行できることを発表しました。Fargate を使用すると、Kubernetes アプリケーションの EC2 インスタンスを作成または管理する必要がなくなります。ポッドが起動すると、Fargate はそれらを実行するために計算リソースをオンデマンドで自動的に割り当てます。 Fargate は、マイクロサービスの実行とスケーリングに最適です。特に、スパイクが発生し、予測できないトラフィックパターンがある場合に役立ちます。Amazon Elastic Load Balancing A
kubernetesとhelmで作る最強のオレオレheroku，yadockeri - PartyIX
この記事は LAPRAS Advent Calendar 2019 の18日目です． 会社でWebサービスを開発していると，検証したりレビューしたりするときに専用の環境が欲しくなる．それは開発しているブランチごとに独立した環境であって欲しいし，なんなら本番っぽいデータが入っているとなお良い． そしてエンジニアだけでなくデザイナーやPOもアクセスできて欲しい．俺のローカル環境を立ち上げればいい？最初は確かにそうなんだけれど，開発メンバーが増えてきたときに，全員がそれをやらなきゃいけないというのはコストだ．レビューのたびにそれをやるとなると，かなりのコストだ． そいうわけで社内に検証環境を立ち上げるyadockeriというプロダクトを前職で作っていたんだけど，今の職場でも作りたくなってしまったのであった（3年ぶり2回目）． kubernetesで，helmで 本番環境は全部kubernetes
Amazon EKS を利用した、ステートレスなマルチリージョンアプリケーションの運用 | Amazon Web Services
Amazon Web Services ブログ Amazon EKS を利用した、ステートレスなマルチリージョンアプリケーションの運用 この記事は、Operating a multi-regional stateless application using Amazon EKS を翻訳したものです。 本投稿は、Sr Solutions Architect の Re Alvarez-Parmar と、Technical Account Manager の Avi Harari により寄稿されました。 AWS の上で運用を行う主な利点の一つは、お客様が AWS のグローバルフットプリントを利用して複数のリージョンでワークロードを実行することが、いかに簡単かという点です。ディザスターリカバリーをサポートするため、あるいはエンドユーザーとなるお客様の近くでアプリケーションを稼働させるためにマルチリ
Laravel + PPM をAmazon ECS(AWS Fargate)にデプロイしよう - OPTiM TECH BLOG
こんにちは。プラットフォーム技術戦略室の青木です。 今までLaravelのアプリケーションを nginx + PHP-FPM でデプロイしていて、ある人に「PPMの方がダントツに早いで！」と聞きましたので今回初めて触ってみようかと思います。*1 Laravel https://github.com/laravel/laravel PPM https://github.com/php-pm/php-pm Terraform https://github.com/hashicorp/terraform AWS Fargate https://aws.amazon.com/jp/fargate/ PPMって何？ PHP-FPM 改めてPPMについて 作ったアプリをDockerImage化する 1. Laravelの構築 2. Dockerfile作成 & Build 3. ローカルで起動し、動作
はじめに 株式会社Awarefyというメンタルヘルス領域のスタートアップでフロントエンドを中心に担当している @nitaking です 2023年4月頃に構築したWEBサイトの構築した際の構成の経緯、技術選定、トラブルシューティングを備忘録として記録しておきます。 すぐ陳腐化する技術の世界なので（もう半年経って状況変わっているし）スナップショットとして活用ください。 また社内ドキュメントにもしてしまおうの趣旨なので、その点をご留意ください 時期 2023年4月頃、Next.js AppRouter(appDir)がbetaだった時期 背景 メインプロダクトはモバイルアプリ（Flutter） バックエンド通信はgRPC 全社的にクリーンアーキテクチャを導入 基本構成 React, TypeScript, Next.js React React・Next.jsの方向性にやや懐疑的な点もあったの
Application Load BalancerのターゲットにLambda Functionを使用して高度なリダイレクトを行う方法 | DevelopersIO
Application Load BalancerのターゲットにLambda Functionを使用して高度なリダイレクトを行う方法 Application Load BalancerのターゲットグループにLambda Functionを使用して、標準機能では行えない高度なリダイレクトを行う方法を紹介します。 はじめに おはようございます、加藤です。 昔話から始まりますが、2018年7月のアップデートでAWS Application Load Balancer（以降、ALB）のリスナールールでリダイレクトを行えるようになりました。 当時は条件として以下をサポートしていました。 ホストヘッダー パスパターン [新機能]Webサーバでの実装不要！ALBだけでリダイレクト出来るようになりました！ ｜ Developers.IO その後、2019年3月にアップデートがあり、下記も条件としてサポート
AWS ALB の LCU の料金計算方法のメモ https://aws.amazon.com/jp/elasticloadbalancing/pricing/ から LCU の計算方法が個人的にわかりにくかった(僕の頭が悪いだけなのですが…)ので整理したメモ。 ただし、例 1 しか整理してない。 金額は アジア・パシフィック/東京 リージョンをベースにした。 例1の条件 (a) アプリケーションが 1 秒あたり平均 1 個の新しい接続を受信 (b) それぞれ 2 分間継続する (c) クライアントは毎秒平均 5 つのリクエストを送信 (d) リクエストと応答の合計処理バイト数は毎秒 300 KB (e) クライアントのリクエストをルーティングする 60 個のルールを設定 新しい接続(1秒あたり) LCU は 1 秒あたり 25 個の新しい接続を提供する ← 既定値 アプリケーションは 1
ChatworkのKubernetesを支えるツールたち(2020年版) - Chatwork Creator's Note
こんにちは。SRE部坂本です。毎年最低1回はフルマラソンに出ていますが、2020年はあえなく参加できずに終わりました。 2月にギリギリ行われたハーフマラソンではなんとか90分切り(89分台)を達成し、今年は3時間10分以内を目指してただけに残念ですが、仕方ありません。 特に部活等で走っていたわけでもなく、トラックの大会に参加するのはやや抵抗があり、年間の走行距離ぐらいしか目標がなく、これを書いている12月中旬で2591kmとなっています。昨年が2724kmだったので、なんとか更新したいなーというのが今の気持ちです。 さて、Chatworkでは2016年からKubernetesを導入しております。EKSもない時代ですので、kube-awsというツールを利用してEC2にホスティングして運用していましたが、今年EKSに移行しました。 aws.amazon.com そんなChatworkのKube
「Amazon EKSベストプラクティスガイド (セキュリティ編)」を読み解く (1)アイデンティティとアクセス管理 | DevelopersIO
みなさん、こんにちは！ AWS事業本部の青柳＠福岡オフィスです。 先月 (5/18) のことになりますが、AWSから「Amazon EKS Best Practices Guide for Security」という文書が公開されました。 この文書は文字通り「EKSを構築・運用する際のセキュリティ面におけるベストプラクティス」をまとめたガイダンスとなっています。 今回公開されたのはセキュリティに関するベストプラクティスですが、今後「パフォーマンス」「オペレーショナルエクセレンス (運用改善)」「コスト最適化」「信頼性」に関するものも公開される予定だそうです。 今回公開された「セキュリティ」に関するベストプラクティスガイドは、以下の10の章で構成されています。 アイデンティティとアクセス管理 (Identity and Access Management) ポッドセキュリティ (Pod Sec
Terraformを使ってAWS SSOのユーザにEKSクラスターのフルアクセス権限を与える | DevelopersIO
やりたいこと AWS SSOのユーザーに、特定のEKSクラスターのフルアクセス権限を付与する設定を、Terraformで行ないたいと思います。 詳細 厳密に言うと、SSOのユーザーは、アクセス権限セットで作成されるIAM Roleにスイッチロールして当該アカウントにログインしますので、フルアクセス権限を与えるエンティティもIAM Roleになります。このあたりの仕組みをよくご存じない方は以下のエントリを御覧ください。 AWS SSOを図解してみた | DevelopersIO また、「フルアクセス権限を付与する」というのも、厳密には当該IAM Roleをk8sクラスター内のsystem:mastersグループに追加するだけです。system:mastersグループがフルアクセス権限を持っているcluster-adminClusterRoleと紐付いています。 `$ kubectl get
Amazon EFS を利用して AWS Fargate 上の Amazon EKS でステートフルなワークロードを実行する | Amazon Web Services
Amazon Web Services ブログ Amazon EFS を利用して AWS Fargate 上の Amazon EKS でステートフルなワークロードを実行する この記事は、Running stateful workloads with Amazon EKS on AWS Fargate using Amazon EFS を翻訳したものです。 本投稿は、Container Specialist Solutions Architect の Re Alvarez-Parmar と Sr Technical Account Manager の Vikram Venkataraman により寄稿されました。 Amazon Elastic Kubernetes Service (EKS) では、EC2インスタンスまたは AWS Fargate で Kubernetes ポッドを実行するこ
こんにちは！コンサル部のinomaso(@inomasosan)です。 最近はAWSでWebサイトを構築する際、SSLサーバ証明書をACMの無料証明書(DV証明書)にて対応することが多かったです。 そこでサクッと構築できるように、Terraformでコード化を検証してみました。 この記事で学べること ACM証明書やALBの作成方法 Terraformでのコードの書き方 環境 今回実行した環境は以下の通りです。 macOS Catalina 10.15.7 Terraform 0.14.8 AWSプロバイダー 3.34.0 前提 Route53でドメイン登録等を実施し、ホストゾーン作成まで完了していること。 コード 1. ACM関連 ACMで無料証明書を作成し、Route53にACMのドメイン検証用レコードを追加します。 Route53のホストゾーンIDは手動入力しているので、ご自分の環境で
TerraformでDNSレコード,ACM証明書,ALBをプロビジョニングする際に入れておいたほうが良いコード | DevelopersIO
TerraformでDNSレコード,ACM証明書,ALBをプロビジョニングする際に入れておいたほうが良いコード 状況 ALBがフロントにあるWebアプリケーションです。https通信のためにACM証明書を作りALBにアタッチします。またクライアントがアクセスするFQDNに対応するDNSレコードはRoute53ホストゾーンに作成します。これらをすべてTerraformでプロビジョニングします。 こういった状況において、Terraformのコードに2点加えておいたほうがいいものがあることがわかりましたのでレポートします。 なお、ベースとなるコードは以下のエントリのものです。 TerraformとAWS Providerのバージョンは以下です。 Terraform: 0.14.9 AWS Provider: 3.31.0 1. aws_acm_certificateにcreate_before_
Introduction はじめまして、SRE G の渡邉です。今回のブログでは、以前の弊社 VP of Engineering佐藤によるコインチェックでの DX Criteria の活用 https://tech.coincheck.blog/entry/2021/12/13/115048 にあった「SLI/SLO/エラーバジェットの決定」の話をします。 コインチェックでは、策定にあたってこんなことを考えて、こんな 感じのものを策定した、を紹介しますので、皆様のSLO策定・改善の役に立てていただけると幸いです 策定の経緯 SREとしてトイル削減やアラート整理などは進めていたのですが、それがある程度落ち着いてきてからは、SLOの策定はやらないといけないとは思いつつもその必要性から説明をしてつくっていくのは相当なパワーを使うのでなかなか手を付けられていませんでした。 それが、2020年の末あ
Amazon EKS でWindowsコンテナを動かす - 一休.com Developers Blog
Amazon EKS Windows Container を使ってみる。 今年の10月に、Amazon EKSがWindows ワーカーノードのサポートを開始しました。 aws.amazon.com 一休では、今年の初めから、既存アプリケーションのEKS移行を行っており、夏には、ほぼすべてのLinux系アプリケーションをEKSへ移行することができました。 user-first.ikyu.co.jp これを踏まえ、Windows系のウェブアプリケーションもEKSへ移行できないか、技術検証を行っています。具体的な検証ポイントは以下のふたつです。 Amazon EKS で、Linuxコンテナ同様、Windows コンテナが動作するか。 既存のWindowsのWebアプリケーション(ASP.NETアプリケーションをDockerコンテナ化できるか。 2については、公開されている各種チュートリアルやサ
モチベーション 色んなアイコン使いたい。 AWS アイコン (2018 以降 ver.) 言語アイコン 一般的なサーバーアイコン etc. AWS アイコンのみの構成図サンプルは見つかるが、他はないの？ 細かい定義・仕様はいいから、コードで語れ。 という方向け。 要件 とある商品管理システム。 フロントエンドは、 AWS S3 + CloudFront でホスティングした SPA。 バックエンドは、Python + Flask on EC2。 どこかのレコメンドシステムにも接続しているらしい。 サンプル構成図 サンプルコード コード @startuml title 商品管理システム ' @see https://github.com/awslabs/aws-icons-for-plantuml/tree/v5.0 !includeurl https://raw.githubusercont
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
プラットフォームの上でものを作るということ
AWSでの法令に則ったログ設計及び実装/分析 - Adwaysエンジニアブログ
次世代デジタル保険を支える監視・通知の技術
AWS ALB+ACMの意外な落とし穴 | 外道父の匠
GitLab GCPに 移行した（前編） - pixiv inside
Flying away from AWS – Terrateam
WEBサーバのTCPコネクション数に上限はあるのか？ - Qiita
N予備校のマイクロサービス - ドワンゴ教育サービス開発者ブログ
TerraformでALBの高度なリスナールールがより簡潔に書けるようになった話 - Qiita
Mackerelを使ったSLI/SLOによるサービス運用の紹介 - Mackerel お知らせ #mackerelio
DX事業本部インフラの3年分の進化 (2019 ~ 2022) - Speee DEVELOPER BLOG
ViteとVitestで開発のリズムを上げる - エムスリーテックブログ
退屈なことはGroovyにやらせよう | Recruit Tech Blog
この1年の Amazon EKS アップデートを振り返る
【Next.js】AppRouter beta時代の技術構成・選定・トラブルシューティングログ
AWS ALB の LCU の料金計算方法の備忘録 - Qiita
【小ネタ】TerraformでACM証明書作成してALBに関連付ける | DevelopersIO
コインチェックでSLI/SLOを策定したときの話 - coincheck tech blog
アイコンよりどりみどりの PlantUML 構成図を書く - Qiita