AWSコンテナ系アーキテクチャの選択肢を最適化する | 外道父の匠
これまでもコンテナ関連の記事はそれなりに書いてきましたが、改めて最新事情に合わせて練り直したり見渡してみると、大きなところから小さなところまで選択肢が多すぎると感じました。 コンテナ系アーキテクチャを丸っと他所の構成で真似することって、おそらくほとんどなくて、参考にしつつ自分流に築き上げていくでしょうから、今回は築くにあたってどういう選択肢があるのかにフォーカスした変化系で攻めてみようと思った次第です:-) 目次 今年一発目の長いやつです。半分は学習教材用、半分は道楽なテイストです。 はじめに 基盤 インスタンス or コンテナ ECS or EKS on EC2 or FARGATE X86 or ARM64 ロードバランサー メンテナンス：ALB or ECS Service 共有 or １環境毎 アクセスログ：ALB or WEBサーバー ECS / EKS デプロイ：Blue/Gr
クラウドネイティブの基盤要素、コンテナの今と未来
https://event.cloudnativedays.jp/cndf2023/talks/1910
Docker＋Wasm Tchnical Preview 2がリリース。Wasmをコンテナとして扱える業界標準「runwasi」採用でWasmランタイムを選択可能に
Docker Desktopを提供するDocker社は、Docker DesktopにWebAssemblyランタイムを統合したDocker DesktopのTechnical Preview 2をリリースしたと発表しました。 Technical Preview 2での最大の変更点は、runwasiを採用したことでWebAssemblyランタイムが選択できるようになったことです。 Technical Preview 1ではWasmEdgeのみに対応していた 2022年10月に発表されたTechnical Preview 1では、Docker DesktopにWebAssemblyランタイムを統合する手段として、WebAssemblyランタイムをまるでコンテナランタイムのように見せかけるための仕組みを持つ「containerd-wasm-shim」と呼ばれるソフトウェアを開発し、組み込んでい
Linuxコンテナの「次」としてのWebAssembly、の解説
はじめに WASMをブラウザの外で動かすトレンドに関して「Linuxコンテナの「次」としてのWebAssemblyの解説」というタイトルで動画を投稿したのですが、動画では話しきれなかった内容をこちらの記事で補完したいと思います。 2022年もWebAssembly(WASM)の話題が多く発表されましたが、そのひとつにDocker for DesktopのWASM対応があります。FastlyやCloudflareもエッジ環境でWASMを動かすソリューションを持っていますし、MSのAKS(Azure Kubernetes Service)でもWASMにpreview対応しています。WASM Buildersでも2023年のWASMの予想としてWASMのアプリケーションランタイム利用に関して言及されました。 WASMといえば元々ブラウザ上で高速にC++のコードなどを実行するところから始まっている
Generating SBOMs for Your Image with BuildKit | Docker
The latest release series of BuildKit, v0.11, introduces support for build-time attestations and SBOMs, allowing publishers to create images with records of how the image was built. This makes it easier for you to answer common questions, like which packages are in the image, where the image was built from, and whether you can reproduce the same results locally. This new data helps you make inform
技術書典#13向けに「Amazon CloudWatch [本格]入門」を執筆しました - How elegant the tech world is...!
はじめに お久しぶりです。最近は疎かになっていましたが、久々のブログ投稿となります。 今回はタイトルの通り、技術書典#13向けに「Amazon CloudWatch [本格]入門」を執筆しました。 本ブログにて少しご紹介できればと思います🚀 techbookfest.org 今回も表紙がかなりかわゆい感じになっていますが、内容はガチガチの技術書です。 書籍の位置付け 技術書典はかれこれ2019年にオンライン開催された技術書典8が初参加です。 その時はコンテナ(Amazon ECS / AWS Fargate)+CI/CDを主テーマにした「クラウドネイティブファーストストーリー」を執筆しました。 2年後の技術書典11にて、同じくクラウドネイティブシリーズ第2弾として「比べてわかる！IaCの選びかた」を世に送り出しました。 booth.pm booth.pm 今回の書籍は、そのクラウドネイテ
![技術書典#13向けに「Amazon CloudWatch [本格]入門」を執筆しました - How elegant the tech world is...!](https://cdn-ak-scissors.b.st-hatena.com/image/square/eca7b4ab7b1d47a757330bf1f21e8f2a08c25534/height=288;version=1;width=512/https%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Fi%2Fiselegant%2F20220910%2F20220910000216.png)
コンテナ／Kubernetesの脆弱性、機密情報、設定間違いが分かるOSS「Trivy」徹底解説～もうイメージスキャンだけとは言わせない
コンテナ／Kubernetesの脆弱性、機密情報、設定間違いが分かるOSS「Trivy」徹底解説～もうイメージスキャンだけとは言わせない：Cloud Nativeチートシート（17） Kubernetesやクラウドネイティブをより便利に利用する技術やツールの概要、使い方を凝縮して紹介する連載。今回は、コンテナ／Kubernetesの脆弱性、機密情報、設定間違いを診断、検出するOSS「Trivy」を紹介する。 OSパッケージやライブラリ、アプリケーションで発見される脆弱（ぜいじゃく）性は日々増え続けていますが、皆さんのアプリケーション、システムは大丈夫でしょうか？ 日々最新のバージョンに修正して脆弱性を対処していれば問題ありませんが、インターネット上に転がっているサンプルなどを参考して実装した場合、「記事で利用されている古いバージョンをそのまま使用して脆弱性が混入してしまっている」なんてこと
実践 Docker - ソフトウェアエンジニアの「Docker よくわからない」を終わりにする本
------------------------------------------------------ 2024 年 1 月更新 本書がきっかけで「なんとか Docker を使えるようになりたい」というプログラマの方向けの入門書を秀和システム様から出版させていただけることになりました 開発系エンジニアのためのDocker絵とき入門 https://www.amazon.co.jp/dp/4798071501 紙書籍と電子書籍、どちらもございます この書籍と執筆経験は、みなさまからの驚くほどの高評価があればこそ得られた機会でした いつも本当にありがとうございます 書籍化に際しまして、この場で次のとおり説明させていただきます 1️⃣ 本書 ( Zenn ) は有料化しません 2️⃣ 本書 ( Zenn ) は今後更新しません 3️⃣ 本書 ( Zenn ) と出版される絵とき入門の違い
Container security best practices: Comprehensive guide
There will be cases like the serverless compute engine ECS Fargate, Google Cloud Run, etc., where some of these pieces are out of our control, so we work on a shared responsibility model. The provider is responsible for keeping the base pieces working and secured And you can focus on the upper layers. Prevention: 8 steps for shift left security Before your application inside a container is execute
「コンテナ」「Kubernetes」はコスト削減のためではない――ガートナーが語る“誤解と真実”
「コンテナ」「Kubernetes」はコスト削減のためではない――ガートナーが語る“誤解と真実”：最も重要なのは「組織変革」（1/2 ページ） 2021年6月21～22日にガートナーが開催した「アプリケーション・イノベーション＆ビジネス・ソリューション サミット」で、ガートナー ジャパンの桂島 航氏が「コンテナとKubernetesをITリーダーはどのように活用すべきか」と題して講演した。その内容をレポートする。 コンテナは、ほとんどの企業が利用するテクノロジーの一つに アジャイルなど開発手法の進化と、マイクロサービスアーキテクチャの進展で、アプリケーションやインフラに求められる要件は変わりつつある。その潮流の中で大きな役割を果たしているのがコンテナ技術とオーケストレーション技術のKubernetesだ。 2021年6月21〜22日にガートナーが主催した「アプリケーション・イノベーション＆
[レポート]JAWS-UGコンテナ支部 #19に参加してきました #jawsug_ct | DevelopersIO
2021年6月28日(月)に開催されたJAWS-UGコンテナ支部 #19に参加してきました！今回もYouTube Liveの限定公開にて開催されました。各セッションのレポートをまとめています。 2021年6月28日(月)に開催されたJAWS-UGコンテナ支部 #19に参加してきました！今回もYouTube Liveの限定公開にて開催されました。各セッションのレポートをまとめています。 前回からもう半年。re:Inventも挟みアップデート内容含めて今回も内容が盛りだくさんです！ ※前回ブログものせておきます。 当日Youtube Liveはアーカイブでも見ることができます 1. AWS コンテナサービスアップデート(youtube 00:07:10 ~) 登壇者 by 苅野秀和 - ソリューションアーキテクト / アマゾン ウェブ サービス ジャパン株式会社 内容 2020年12月～のアッ
![[レポート]JAWS-UGコンテナ支部 #19に参加してきました #jawsug_ct | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/6547ca3360d00870c109085482ff5cf49c1ca7fe/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2020%2F06%2Fjaws_container.png)
Dockerfileのベストプラクティス Top 20
本文の内容は、2021年3月9日にÁlvaro Iradierが投稿したブログ(https://sysdig.com/blog/dockerfile-best-practices/)を元に日本語に翻訳・再構成した内容となっております。 Dockerfileのベストプラクティスのクイックセットをイメージビルドに適用することで、セキュリティ問題を防ぎ、コンテナ化されたアプリケーションを最適化する方法を学びます。 コンテナ化されたアプリケーションやマイクロサービスに精通している人なら、自分のサービスがマイクロサービスであることに気づいているかもしれません。しかし、脆弱性の検出、セキュリティ問題の調査、デプロイ後の報告や修正など、管理のオーバーヘッドがマクロな問題になっています。 このオーバーヘッドの多くは、セキュリティをシフトレフトし、開発ワークフローの中で可能な限り早く潜在的な問題に取り組むこ
軽量Dockerイメージに安易にAlpineを使うのはやめたほうがいいという話 - inductor's blog
はじめに やめろ、ではなく、やめたほうがいい。です。自分のユースケースに合ってるか今一度確認することを推奨します。基本的にはAlpineは避けたほうが良い、というのが2021年時点での私の認識です。 なんで？ libcに一般的な互換性が不足しているからです。Ruby、Python、Node.jsなどでNativeモジュールをバンドルしているアプリケーションの場合、パフォーマンスの劣化や互換性の問題にぶち当たる場合があります。 superuser.com あとは他のベースイメージの軽量化もそれなりに進んできていて、Alpineが定番軽量イメージと言う認識は2018年頃には消えつつあったかなという認識でいます。 どうすりゃええねん ※Debian Slimがあるやんってツッコミ結構もらったんですが、Slimは当たり前過ぎてもう紹介しなくていいかなっていう甘えで省略していました。よろしくおねがい
スタディサプリENGLISHの基盤をECSからEKSに移行しました | Recruit Tech Blog
こんにちは、スタディサプリ ENGLISH SREグループの大島です。 オンライン英語学習サービスであるスタディサプリ ENGLISHは2015年10月のリリース1)当時は英語サプリという名前でリリースしていましたから5年が経ち、おかげさまでサービスを拡充させることができています。リリース当初からインフラにはコンテナを採用し、長い間AWSのコンテナオーケストレーションサービスのAmazon Elastic Container Service（以下、ECS）で運用してきましたが、この度ECSからAmazon Elastic Kubernetes Service（以下、EKS）に移行しました。 今回の記事では、その歴史の変遷となぜEKSにしたのかというところを書いていきたいと思います。 コンテナと歩んできた5年間 まず、ECSからEKSに移行しようと思ったきっかけの前に、インフラの歴史を少し振
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
やっぱりEKSの運用は大変なのか 〜EKSを2年間運用して得た知見とコンテナセキュリティ〜 - DMM inside
アプリケーション開発者は Amazon ECS あるいは Kubernetes をどこまで知るべきか #AWSDevDay / You build it, you run it
ECS×Fargateで実現する運用コストほぼ0なコンテナ運用の仕組み/ ecs fargate low cost operation