レスポンシブの実装が今までと変わる！ CSSの新機能コンテナクエリと:has()疑似クラス、最初に理解しておきたい基礎知識を解説
CSSの新機能コンテナクエリ（@container）と:has()疑似クラスが、いよいよChrome 105（8月末、来週リリース予定）でサポートされます。 コンテナクエリとは今までのメディアクエリがビューポートに依存していたのとは異なり、親要素（コンテナ）のサイズに対してスタイルを適用できます。:has()疑似クラスは指定した要素を含んでいる場合にスタイルを適用できます。 レスポンシブの実装この2つの新機能は単独でも強力ですが、組み合わせるとさらにすごいパワーを発揮します。この2つの新機能の最初に理解しておきたい基礎知識を紹介します。 container and :has(): two powerful new responsive APIs landing in Chromium 105 by Una Kravets 下記は各ポイントを意訳したものです。 ※元サイト様のライセンスにもと
エンプラに Kubernetes を 導入してみて分かった 4つの Lessons Learned
1. エンプラに Kubernetes を 導入してみて分かった 4つの Lessons Learned September 24th, OPENSHIFT.RUN 2020, Daiki Kawanuma 3. エンタープライズにおける Kubernetes 導入あるある Kubernetes 導入のモチベーション • リソースの抽象化 Declarative Configuration • 自己回復性 Self Healing • 自動スケーリング Auto Scaling https://www.datadoghq.com/ja/container-report/ ビジネスのアジリティーを高めること Kubernetes の本質的な価値 For instance, average container lifetimes exceed 30 days in 3 percent of K
SREチームの長田です。 今回はカヤックで運用している「まちのコイン」というプロダクトのアプリケーション基盤を Amazon EKS(以下EKS)からAmazon ECS(以下ECS)に移行したはなしをします。 まちのコインとは coin.machino.co www.kayac.com まちのコインはカヤックが運営している、デジタル地域通貨を使ってその地域のコミュニティを活性化させるサービスです。 2019年11月から実証実験を開始し、翌年2月から正式リリースされました。 2022年9月現在、20の地域に導入されています。 一般ユーザーが使用するクライアントアプリと、導入地域の運営団体が使用するブラウザ用の管理画面、 それらにAPIを提供するRailsサーバーアプリがあります。 データベースはAmazon Aurora PostgreSQL、 その他AWSのマネージドサービスを組み合わせ
Datadog メトリクスモニター作成入門
Datadog はモニタリング関連の SaaS ではおそらく最も利用されているサービスでしょうが、公式ドキュメントが豊富にある割には何から読み始めれば良いかわかりにくく、慣れるまでの道が険しい印象です。 本エントリーでは、Datadog が既に導入されている組織で、Datadog モニターを使って監視をしたいけど、モニターの設定方法がよくわからないといった方を対象に、メトリクスモニターの作成に焦点を絞って解説していきます。なお、あくまで Datadog の使い方についての解説であり、どのようなモニターを設定すべきかについては触れません。 メトリクスの収集についても触れたかったんですが、力尽きたので、メトリクスの収集については気が向いたら別エントリーを書きます。 アジェンダ メトリクスモニターの作成方法の基本 クエリの定義について クエリの評価期間・評価方法・アラート条件の指定 クエリの結果
AWS、コンテナ特化で瞬時に起動する軽量VM「Firecracker」オープンソースとしてバージョン1.0に到達。AWS LambdaやAWS Fargateで利用
Amazon Web Services（AWS）がオープンソースとして開発し、コンテナの実行に特化した軽量な仮想マシン「Firecracker」がバージョン1.0に到達しました。 Firecrackerは2018年11月に行われたAWSのイベント「AWS re:Invent 2018」でオープンソース化が発表されました。コンテナのために作られた仮想化技術で、同社が「マイクロVM」と呼ぶセキュリティにフォーカスして設計されたスリムな仮想マシンです。 AWS Lambdaのような高速なサーバレス環境を実現するために同社が開発しており、実際にAWS LambdaやAWS Fargateで利用されていると説明されています。 基本的な特徴として、小さなメモリフットプリントとオーバーヘッドに加えて、外部から攻撃可能な部分を最小限にするなどのセキュリティ対策を実装しています。 速度にもフォーカスしており
初めてFargateを触ったので、運用保守の観点で構築時に設定しておいた方が良いポイントをまとめました。 デプロイの自動化と書いているのにデプロイの話薄めになってしまいました…。 こちらはJAWS-UG朝会 #28で発表したものになります。
コンテナでログをどう取得すればいいの？そもそもどういうログがあるのか？ ログの取得パターンから活用方法まで、 @prog893 が選定のためのヒントとサンプルアーキテクチャで紹介します。
日本ではKubernetesやCI/CDなどが幻滅期に、インダストリクラウドやインフラ自動化は過度な期待。「日本におけるクラウド・プラットフォームのハイプ・サイクル」2024年版発表
日本ではKubernetesやCI/CDなどが幻滅期に、インダストリクラウドやインフラ自動化は過度な期待。「日本におけるクラウド・プラットフォームのハイプ・サイクル」2024年版発表 調査会社のガートナージャパンは、「日本におけるクラウド・プラットフォームのハイプ・サイクル：2024年」を発表しました。 ハイプサイクルとは ガートナーのハイプサイクルは、技術の登場から安定までを5つのステージに分けて説明したものです。5つのステージは、「黎明期」から始まり、「『過度な期待』のピーク期」「幻滅期」「啓発期」「生産性の安定期」まで。この途中で消えていく技術もあります。 同社はグローバルだけでなく国別などさまざまな切り口でハイプサイクルを発表しています。今回発表されたのは日本のクラウドプラットフォームにおけるハイプサイクルです。横幅の関係上、図を2つに分割しました。まずは前半部分。 黎明期にはFi
AWS DevDay Japan 2022 に「AWS CDKでECS on FargateのCI/CDを実現する際の理想と現実 」というタイトルで登壇しました #AWSDevDay | DevelopersIO
はじめに CX事業本部の佐藤智樹です。 先日AWS DevDay Japan 2022 というイベントで「AWS CDKでECS on FargateのCI/CDを実現する際の理想と現実」というタイトルで登壇しました。 今回は上記の登壇で使用した資料の公開と発表の補足を記載いたします。 登壇動画 登壇資料 発表理由 1年前に上記の構成を始めた際に、思っていたよりは理想の状態にできないことが多々あり、情報も多くないように感じたので少しでも参考になるように実践例をベースにまとめました。同じような構成を試される際は参考になるかと思います。また発表の1ヶ月以内(2022/09~10)に結構更新があったので、昔同じ構成試してダメだった部分があったかたも参考になる部分あるかと思うのでみてもらえると嬉しいです。 最後に 本当は資料90ページぐらいになってタイトルと関連性の薄い内容（ECS on Farg
Developers Summit（デブサミ）2024で登壇したセッションの資料です。 - https://event.shoeisha.jp/devsumi/20240215 - https://event.shoeisha.jp/devsumi/20240215/session/4777 …
最近実際に開発現場にコンテナを導入してきた経験から、公式ドキュメントに記載されているベストプラクティスに実際どうなんだということを言ってみようと思います。公式に書いてあることを間違ってると指摘という意図はありません 発言は個人の見解に基づくものであり、所属組織を代表するものではありません。 2023/12/3更新: 燃えかけてるのでタイトルを変えました。 補足: こちらの環境は下記を想定しています。 Java CICD/本番環境イントラネット内に整備 WF開発 マルチステージ・ビルドを使う マルチステージビルドの目的 公式ドキュメントには、下記のように記載があります。 マルチステージ・ビルド は、中間レイヤとイメージの数を減らすのに苦労しなくても、最終イメージの容量を大幅に減少できます。 つまり、最終イメージの容量を減らすことが目的であって、その一つの手段としてマルチステージビルドを進めて
AWS×コンテナで基本的なDevSecOpsアーキテクチャをデザインしたお話 - How elegant the tech world is...!
はじめに 先日、僕が担当する業務でECS/Fargate利用を前提にDevSecOpsアーキテクチャをデザインし、社内のAWS勉強会にて登壇する機会をいただきました。 本ブログでも内容をかいつまんでご紹介できればと思います。 AWSによらず、コンテナを利用されている方にとって、一つのプラクティス例としてご参考になれば幸いです。 ※コンテナ自体の説明や必要性に関する内容は省略していますm(_ _)m そもそもDevOpsとは？ DevSecOpsの導入意義をお伝えするた前に、まず軽くDevOpsの意義をお伝えします。 ※とは言え、この記事をご訪問されている方にとっては「何をいまさら...」な内容かもしれませんし、ググればDevOps自体の情報はたくさん見つかりますので、重要なポイントのみ述べることにします。 DevOpsとは、一言で述べれば、開発チームと運用チームが協力してビジネス価値を高め
コンテナセキュリティ
「コンテナセキュリティ - Forkwell Library#26」の資料です。 https://forkwell.connpass.com/event/287259/
Googleの「Cloud Run」が正式サービスに。KnativeベースでDockerコンテナをサーバレスとして実行
Cloud RunはHTTPでアクセス可能なステートレスなサービスを提供するコンテナを、サーバレス環境で実行可能なサービスです。 すなわち、負荷がない場合にはサービスはまったく起動されず、負荷に応じて自動的にスケール。Dockerコンテナであれば、どんな言語で作られたサービスであっても関係なく利用できます。 課金もおよそ100ミリ秒ごとに、起動しているサービス数などによって計算されます。 また、Cloud RunはKubernetes上でサーバレスコンピューティング環境を実現するフレームワークとしてGoogleがオープンソースとして開発しているKnativeをベースにしています。 Anthos Cloud Runによりマルチプラットフォーム上でサーバレス Googleは、Kubernetesをクラウド基盤の抽象化レイヤとして用いることで、コンテナ化したアプリケーションをオンプレミスとクラウ
いまやWebアプリの開発やデプロイにおいて、コンテナは欠かせないものになってきました。 コンテナ実行環境にも色々ありますが、その中でも支配的なのがDockerでしょう。 ですがDockerは、その構造上いくつかの問題も抱えています。 今回はDockerと互換性を持ちながらも、よりセキュアに運用できるPo…
「そのコンテナ、安全ですか？」〜AWS x DevSecOpsで実践するコンテナセキュリティ〜 / Is that container safe?
2020-10-20 AWS DevDay Online Japanでの登壇資料になります。 https://aws.amazon.com/jp/about-aws/events/2020/devday/ # AWSご担当者様より承諾頂いた上でアップロードしています
【DevelopersIO 2024】AI 半可通なのにエッジ AI 機能を全力で解説してみる 〜Cloudflare の場合〜
あなたの組織に最適なコンテナデプロイ方法とは？〜ECSにおけるデプロイ最新機能てんこ盛り〜
AWSにおけるコンテナワークロード運用のデファクトスタンダードの地位を確立したECS。 デプロイ方法も進化を続け、CodeDeployとALBで連携したB/Gデプロイやカナリアリリースにも対応し、そのデプロイにおける柔軟性はEKSに勝るとも劣りません。 そんなECSですが、手段が豊富になったこともあり現…
技術書典#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)
えにしテック15周年記念カンファレンスの発表資料です。 https://enishi-tech-15th-anniv-conf.peatix.com/ 資料中で参照しているURLは以下です: https://github.com/rails/rails/milestone/87 https:…
概要 ソーシャル経済メディア「NewsPicks」SREチームの中川です。 皆さんはバッチ処理基盤はどうされていますでしょうか。 NewsPicks では少し前まではそれらをEC2、cronの組み合わせで動作させていました。 何年も前からこの仕組みだったのですがSREとしてはEC2の面倒見るのも手間ですし、それ以上にcronを変更する際のオペレーションミスが目立ったのが懸念点でした。 その為、まずはAWSマネージド化するための基盤を整備し、その後バッチアプリを載せ替えていくようにしました。 対応前の基盤構成 同じSREチームの安藤さんが CloudNative Days Tokyo 2023 で登壇されたときの資料をお借りします。 ご覧の通り、大体のサービスはマネージド化していましたがバッチ基盤だけは旧来のままEC2インスタンスを利用していました。 10年モノのサービスのインフラを漸進的
DockerとAWSのコラボによりdocker ecsコマンドが爆誕したので使ってみた | DevelopersIO
Docker社とAWSがコラボレーションするという驚きとともに、新しくdockerコマンドに組み込まれたdocker ecsの使い心地を試してみました。 「docker ecsコマンド？なにこれ？」 先日、突如、DockerのECSインテグレーションなるものが発表されました！ AWS and Docker collaborate to simplify the developer experience | Containers 従来あるdockerコマンドに、なんとdocker ecsコマンドが追加され、docker-composeファイルを利用したECSへのデプロイがAWS CLIなどのAWS製ツールを使わずに、全てdockerコマンドだけで完結するという、ちょっと想像がつかないアップデートです。 まだDocker社ではベータ版の扱いということですが、なかなかにおもしろいアプローチだった
EC2やFargateが最大72%割引となる新しい料金モデル「Savings Plans」がリリースされました | DevelopersIO
AWSチームのすずきです。 2019年11月7日、AWSのEC2やFargateのオンデマンド料金が 最大72%割引で利用できる新しい料金モデル 「Savings Plans」 がリリースされました。 その概要と、従来のリザーブドインスタンス(RI)との比較について紹介させていただきます。 New – Savings Plans for AWS Compute Services 概要 1年、または3年間の期間で、1時間あたりの利用費をコミットする事により、 コミット分を割引価格で利用する事が可能になりました。 AWSコンソール EC2ダッシュボードに、「Savings Plans」のメニューが追加されています。 コミットメント 1時間あたりの利用費を登録します。 購入コミットメントの最小単位は「$0.001」。 最小コミットのSavings Plans を「期間3年」「全額前払い」で購入し
InfraStudy 2nd #2 の発表資料です
Docker ComposeのAmazon ECSデプロイを試してみた - SMARTCAMP Engineer Blog
スマートキャンプ、エンジニアの入山です。 2020年7月にDockerとAWSのコラボレーションにより、単一コマンドでDocker ComposeのyamlファイルからAmazon ECS上に各コンテナをデプロイできる機能追加が発表され、非常に注目を集めました！ From Docker Straight to AWS - Docker Blog AWS and Docker collaborate to simplify the developer experience | Containers ローカルでDockerを利用して開発を行っている方々は、ほぼ間違いなくDocker Composeを利用してアプリの動作に必要な各コンテナを一括管理しているかと思いますが、このECS Pluginを利用するとAmazon ECSへの各コンテナのデプロイとECSの動作に必要な各AWSリソースを一括し
Amazon Web Services ブログ AWS Copilot のご紹介 Amazon Elastic Container Service (Amazon ECS) をご利用中、あるいはご利用を検討されている皆さまへ 本記事でご紹介する AWS Copilot は Amazon ECS CLI の後継に当たるものです。日本はこの ECS CLI を多くのお客様にご利用いただいている地域の1つであることに加え、ECS でのコンテナ実行をもっと簡単に行えるようにしたい、シンプルなワークフローを実現したいというリクエストを多数いただいていることから、本記事を英語記事と同じタイミングで公開することにしました。 Amazon ECS でのコンテナ実行に新たな体験を提供する AWS Copilot の紹介記事です。お楽しみください！ −トリ (皆さまからの Copilot へのフィードバック、
CloudNative Days Tokyo 2021の発表資料です。 https://event.cloudnativedays.jp/cndt2021/talks/1207 補足資料 https://git.io/operator-bestpractice
Kubernetes / GKE ファンの皆様こんにちわ。Google Cloud の Kazuu (かずー) です。GKE Autopilot が GA になりました。弊社公式ブログに続きまして、GKE Autopilot を日本語で解説していきたいと思います。 本記事は以下、3 部構成となります。 GKE Autopilot 概要GKE Autopilot を試してみるGKE Autopilot がハマりそうなユースケースは？ 1. GKE Autopilot 概要GKE Autopilot は GKE の新しいモードです。Control Plane に加えて、Node が完全マネージドになります。これまでの GKE では Node はユーザー自身が必要台数分作成し、以後の Day 2 オペレーション (e.g. アップグレード) 等も気に掛ける必要がありました。GKE Autopil
Canonicalの軽量Kubernetes「MicroK8s」がWindowsとMacに対応。インストーラーで簡単に導入可能に
Kubernetesの機能は損なわず、PCやRaspbery Piといったエッジの環境へ簡単に導入し運用することにフォーカスしつつ、サービスメッシュのIstio、Linderd、サーバレスのKnative、分散トレーシングのJeager、メトリクス収集のPrometheusなどもバンドルされています。 NvidiaのGPUを用いたGPGPUにも対応。MicroK8sの自動アップデートも可能。導入や構成がシンプルなことから、MicroK8sはローカルの開発環境などによく用いられています。 そのMicroK8sがWindowsとMacに対応したことが発表されました。 #MicroK8s is now available natively on @Windows and #macOS via the command line, as if you were using on Linux. Lea
Read this article in English. はじめに 見つけやすく、インストールしやすいソフトウェアパッケージは、開発者にとって使いやすいです。React、Ruby on Rails、Airflow のような有名な OSS は良い事例です。しかし、社内の非公開のコードは、企業秘密として世間から隠されることが多いです。権限を持っている人のみ見ることができて、オープンソースのように npm gem や pip で簡単にインストールすることもできません。 その結果、社内のコードがうまく再利用されなくなる（あるいはできなくなる）ことがあります。各チームはそれぞれ独立したコードベースを持ち、他のチームにコードを共有したくても、満足がいく解決策を導き出すことが難しかったりします。戦略を立てないままでは、それぞれの独立したコードベースを充実させ続け「社内共通のライブラリー」が遠い夢のよう
docker composeのserviceをグループ化
docker composeではserviceごとにprofilesという属性を指定できて、起動時にこれを指定することで関連する一連のserviceだけを起動させられる。 どういうシーンで使えるのか。例えばとあるRailsアプリでは、一部の開発者はMySQLやRedisなどのデータストアだけdocker composeで起動して開発し、他の開発者は加えてRubyもdocker composeで起動して開発している。osxfsが遅すぎて、ファイルへの読み書きが頻発する処理がmacOSのDockerでは使い物にならないからだが、この話は今回どうでもいい。さてこのとき、データストア用のserviceに適当な名前のprofileを割り当てておくことで、個々のserviceの名前を逐一指定しなくても起動でき、将来の変更にも強くなって嬉しい。 # profile導入前 docker compose u
ちょいとした用途において、カジュアルにFargateの起動／停止を繰り返して、気ままに負荷全開かけていたら、あまりの違和感にCPU割り当てについて調査することにしました。 最近こんなことばっかやってる気がしますが、気に食わんかったからムカムカ解消に書くしかないんや。半分くらいブラックボックス与太話な感じで夜露死苦です。 はじまり とある処理を全開でFargateにやらせて、cpu=1024(100%), 2048(200%), 4096(400%) でどのくらい RPS (requests per second) でるかを計測していると、想定通りならほぼ比例でRPSが伸びるはずが、全然そうならないパティーンに遭遇。 並列過剰やエラー・バグ起因ではないことをほぼ確させた上で、まさかCPUガチャじゃあるまいなと試したら、まんまCPUガチャでしたということで、EC2からある話ではありますが、現在
概要 Docker コンテナの原則として「1コンテナ1プロセス」1というものがありますが、あえてこの原則を破りたいときがあるかもしれません。 公式: Run multiple services in a container 有志翻訳: コンテナー内での複数サービス起動 上記ドキュメントのラッパースクリプトを利用する方法には重大な問題があり、本番環境で使用するべきではありません。 (よりによって「本番環境でのアプリ運用」の項目にある) 公式ドキュメントに書かれているのに、死ぬというのはおかしいじゃないか それが罠だという証拠 ちなみに supervisord を利用する方法は問題ありません。 また、コンテナ向けに最適化された s6-overlay2 を利用する方法もあります。 ラッパースクリプトの問題点 プロセスの graceful shutdown が実行されない(プロセスに SIGKIL
Docker DesktopとAmazon ECS（Elastic Container Service）が連係可能に。DockerとAWSが協業
Docker DesktopとAmazon ECS（Elastic Container Service）が連係可能に。DockerとAWSが協業 WindowsやMacでDocker環境を利用できる「Docker Desktop」と、Amazon Web Services（AWS）のコンテナ環境であるAmazon ECS（Elastic Container Service）との連係が、DockerとAWSから発表されました（Dockerの発表、AWSの発表）。 From Docker Straight to AWS? Why, yes you can. Read about our collaboration with @AWSCloud https://t.co/Hy1Nvq3m0r #AWS #Docker #Containers #Cloud pic.twitter.com/92gL
ラズパイでもAmazon ECSを動かせる、「Amazon ECS Anywhere」が正式リリース。ラズパイやオンプレミスのコンテナ環境をAWSから集中管理可能
ラズパイでもAmazon ECSを動かせる、「Amazon ECS Anywhere」が正式リリース。ラズパイやオンプレミスのコンテナ環境をAWSから集中管理可能 Amazon Web Services（AWS）は、AWS上のコンテナ基盤サービスである「Amazon ECS（Elastic Container Service）」を、オンプレミスなど任意のサーバなどで実行可能にする「Amazon ECS Anywhere」の正式リリースを発表しました。 With Amazon ECS Anywhere, you can run and manage container-based applications on customer-managed infrastructure, including on-premises on your own virtual machines and bar
はじめに アプリケーションログは、アプリケーションの動作状況をログファイルに記録するプロセスです。アプリケーションよって、この動作状況は1つ以上のファイルに記録することが多いです。このログファイルは、セキュリティとパフォーマンスの分析の実行、アプリの問題のトラブルシューティングなどに役立ちます。この記事では、ログ、ログの種類およびAWSのCloudwatLogsサービスについて説明したいと思います。 各個人によって好きなAWSサービスがそれぞれだと思います。これが正解という訳ではありませんが、参考にしてただければと思います。 対象者 AWSでログの記録に興味がある方。 AWSでワークロードを運用している担当者。 ログレベル ログレベルについて皆さんご存じだと思いますが、主に３種類のログがあります。 レベル 説明
AWS導入～スケールまでの変遷を事例に学ぶ - コンテナ化のために「みてね」が選んだ構築戦略 - エンジニアHub｜Webエンジニアのキャリアを考える！
AWS導入～スケールまでの変遷を事例に学ぶ - コンテナ化のために「みてね」が選んだ構築戦略 これからAWSを導入する、AWSに入門するといった方に向け、AWSの導入のための基本的な戦略や考え方を事例で紹介します。多岐にわたるAWSの機能をいかに活用するか。サービス立ち上げから、その後のスケールまで、実際の現場でどのようにAWSを活用しているかを、株式会社ミクシィで「みてね」のインフラをリードする清水勲さんが語ります。 今や全世界のWebを支えるクラウドとして欠かせない存在となったAWS（Amazon Web Services）。さまざまな規模、目的のWebで活用されている中、持続的・永続的なサービス設計・開発・運用をするには、日々の情報収集と、時代に合わせたアップデートが求められます。 今回、株式会社ミクシィが提供する「家族アルバム みてね」でのAWS活用事例をもとに、AWS活用のヒント
仕事でPythonコンテナをデプロイする人向けのDockerfile (1): オールマイティ編 | フューチャー技術ブログ
BusterとかStretchという名前が見慣れない方もいるかもしれませんが、これはLinuxディストリビューションとしてシェアの大きなDebianのコードネームです。 Debianバージョンが少し古いStretchの方がちょびっとサイズが小さかったりはしますが、まあ実用的にはサポートが長い方がいいですよね。slimを使ってGCCとかのコンパイラを自前でダウンロードしている記事とかもたまに見かける気がしますが、マルチステージビルドであれば、そんなにケチケチしなくていいのと、パッケージダウンロードは逐次処理なので遅く、処理系が入ったイメージのダウンロードの方が高速です。並列で処理されるし、一度イメージをダウンロードしてしまえば、なんどもビルドして試すときに効率が良いです。また、多くのケースでネイティブのライブラリも最初から入っており、ビルドでトラブルに遭遇することはかなり減るでしょう。 Py
App Engine VS Cloud Run
Cloud Run CPU 0.08 ~ 8 Core (2nd gen は最小 0.5~) Memory 128 MiB ~ 32 GiB (2nd gen は最小 512MiB~) Deploy App Engine は Deploy (gcloud app deploy) を実行すると Cloud Build が暗黙的に動いて Deploy が行われるが、これがなかなか時間がかかる。 開発環境だと CI でとりあえず main branch に merge されたら、Deploy したりするけど、Deploy を Skip してもよいような時でも CI 回してると Deploy を待つことになって、ちょっとめんどうに感じる。 更にこの仕組みは成果物は Deploy しないと生まれないので、CI と CDを分離しづらい。 Cloud Run は Container Registry a
こんにちは、Sally社 CTO の @aitaro です。 マーダーミステリーアプリ「ウズ」とマダミス制作ツール「ウズスタジオ」、マダミス情報サイト「マダミス.jp」を開発しています。 はじめに この記事ではウズの開発当初から利用していた Docker Compose をやめることにした背景についてご紹介します。 Docker Compose は各マシンの開発環境での差異を吸収するというメリットがあり、多くの開発現場で導入されていますが、Docker Composeの抱えているデメリットを勘案して、最終的に一部を残して辞める決断をしました。 Docker Composeの特徴 Docker Composeは、複数のコンテナを定義し、管理するためのツールです。ウズの開発環境では、バックエンド、フロントエンド、データベースなどをそれぞれコンテナ化して、Composeで一括管理していました。こ
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
EKSからECSに移行して開発運用コストの削減を図る - KAYAC engineers' blog
Fargateの運用 ～デプロイ自動化や監視等～
AWS Startup Tech Meetup #3: かんたんコンテナロギング選手権
アーキテクチャから学ぶKubernetesの全体像
コンテナのベストプラクティスに対しておこがましくも言ってみる - Qiita
Docker互換のセキュアなコンテナ実行環境「Podman」超入門
Dockerで始めるAWS Lambda開発
2024年のRailsと自由について考える
EC2とcronで動いていたバッチ基盤をマネージド化した - Uzabase for Engineers
VM時代からコンテナ時代へストレージ管理の移り変わり
AWS Copilot のご紹介 | Amazon Web Services
Kubernetesオペレータのアンチパターン＆ベストプラクティス
完全マネージドな k8s ! GKE Autopilot を解説する
社内コードを公開せずに内部で共有する方法 - Qiita
AWS ECS Fargate のCPU性能と特徴 | 外道父の匠
1コンテナ複数プロセスはやめておいた方が良い話 - Qiita
AWSにおけるアプリケーションのログ記録のベストプラクティス - Qiita
モノレポの開発環境でDocker ComposeをやめてTaskfileを導入した話
www.saishinkai.com
www.nichepcgamer.com
news.yahoo.co.jp
hiru-den.com
zenn.dev/statstat
www.bbc.com