Local cluster for EKS on AWS Outpostsについて紹介 - NTT Communications Engineers' Blog
はじめに こんにちは、イノベーションセンターの鈴ヶ嶺です。 本記事では、自社データセンター等でAWSサービスを利用可能なAWS OutpostsにおけるElastic Kubernetes Service(EKS)で新たに追加されたLocal clusterの概要や通信切断検証の結果について紹介します。 以前記事にした2022年3月17日時点では、ワーカーノードはAWS Outposts上で実行し、KubernetesコントロールプレーンはAWS Cloud上で実行する構成でした。この構成がLocal clusterによってKubernetesコントロールプレーンもAWS Outposts上で実行可能になりました。これによりAWS CloudとAWS Outposts間の通信切断などによるアプリケーションのダウンタイムのリスクを軽減することが可能となりました。 engineers.ntt.
[DevOpsプラットフォームの取り組み #7] 独自のKubernetesカスタムオペレーターを用いたCI/CDエンジン - NTT Communications Engineers' Blog
DevOpsプラットフォームの取り組みを紹介する7回目の記事です。 Qmonus Value Stream 開発チームの奥井（ @HirokiOkui ）です。 連載第7回では、Qmonus Value Streamの中核を担うコンポーネントであるAssemblyLineについて深堀りします。 第2回 および 第6回 で解説したとおり、Qmonus Value Streamでは、AssemblyLineという独自のリソースを定義してCI/CDパイプラインを構成します。 AssemblyLineは、 Tekton と同様にKubernetesのカスタムオペレーターとして実装されています。 AssemblyLineは、Tekton Pipelineを実行するワークフローエンジンとしての責務に加えて、柔軟性の高いCI/CDパイプラインを構成・実行するために必要な様々な機能を有しています。 本記事
![[DevOpsプラットフォームの取り組み #7] 独自のKubernetesカスタムオペレーターを用いたCI/CDエンジン - NTT Communications Engineers' Blog](https://cdn-ak-scissors.b.st-hatena.com/image/square/2f6ffb293f07e5c63222cfd9c762437543954b40/height=288;version=1;width=512/https%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2FN%2FNTTCom%2F20220916%2F20220916161541.png)
[DevOpsプラットフォームの取り組み #4] CUE言語の紹介 - NTT Communications Engineers' Blog
はじめに DevOpsプラットフォームの取り組みを紹介する4回目の記事です。 Qmonus Value Streamの開発チームの會澤です。 連載4回目では、Qmonus Value Streamの重要な構成要素であるCUE言語についてご紹介します。 前回の記事では、Infrastructuer as Code (以下IaC)の課題と、Cloud Native AdapterというQmonus Value Streamチームの独自技術について解説しました。 Cloud Native Adapterは、「インフラストラクチャの構成」と「ワークフロー」をCUE言語を使って宣言します。 CUE言語は、複雑なシステム構成をスケーラブルに管理できることから、近年注目を集めているデータ記述言語です。 前回の記事でご紹介したとおり、KubeVelaやDaggerなど最近リリースされたIaCソリューション
![[DevOpsプラットフォームの取り組み #4] CUE言語の紹介 - NTT Communications Engineers' Blog](https://cdn-ak-scissors.b.st-hatena.com/image/square/aa86d9ff6e0194620b0a9a7b3d4526c76487bbd4/height=288;version=1;width=512/https%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2FN%2FNTTCom%2F20220802%2F20220802094547.png)
GitHub Actions Self-hosted Runner と Gatling による負荷試験 - スタディサプリ Product Team Blog
こんにちは。SRE の @int128 です。 先日の「負荷試験、Gatling を使ってやってみた」で紹介したように、スタディサプリではユーザ体験の改善や本番障害の予防を目的に負荷試験を行っています。 本稿では、SRE と Product Team がどのようにして一緒に負荷試験に取り組んでいるか、考え方や仕組みを紹介します。 背景 SRE では新しいマイクロサービスの開発や機能追加の契機で Production Readiness Check を行っています。 具体的には、Product Team がテンプレートにしたがって Production Readiness Checklist を記入して、SRE と一緒にレビューを行っています。 その際に、トラフィックが多い、あるいは、レイテンシが厳しい、といったリスクがある場合に負荷試験を行うことにしています。 負荷試験は以下の流れで実施し
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
