ECSタスクのコンテナ異常終了を検知する3つの方法 | DevelopersIO
以降、それぞれの検知方法を紹介していきます。 検知方法①：サービスのランニングタスク数をメトリクスから検知 一番代表的な方法です。ECSコンテナエージェントは、タスク内のコンテナの状態をモニタリングしています。構成①と②においては、essential=trueのコンテナのみ含まれているので、コンテナの停止は即ECSタスクの停止となります。 あとは、ECSサービスにおけるDesiredTask Count（期待するタスク数）をしきい値としたランニングタスク数のCloudWatchメトリクスを用意しておき、しきい値を下回った時=タスクが異常終了したときにアラームを発火します。 一点、CloudWatch Alarmはある一定期間のメトリクスの状態からアラームを検知するものなので、検知までいくらかのタイムラグが有ることは注意しておきましょう。 基本的にECSのサービス運用においては、そのDesi
GitHub - docker/awesome-compose: Awesome Docker Compose samples
Icon indicates Sample is compatible with Docker Dev Environments in Docker Desktop version 4.10 or later. Icon indicates Sample is compatible with Docker+Wasm. ASP.NET / MS-SQL - Sample ASP.NET core application with MS SQL server database. Elasticsearch / Logstash / Kibana - Sample Elasticsearch, Logstash, and Kibana stack. Go / NGINX / MySQL - Sample Go application with an Nginx proxy and a MySQL
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
Dockerで未使用オブジェクトを消す「prune」オプションの整理 - Qiita
概要 Docker で不要なものを消すガベージコレクション（garbage collection ）は、prune 系のオプションを使う。 prune 系オプションを使うと、使っていない Docker オブジェクト（コンテナ、イメージ、ネットワーク、ボリューム）をまとめて削除できる。コンテナが停止してからの時間を指定できる --filter "until=24h" の指定で、更に活用しやすくなる。あるいは --filter "until=2020-06-01" のように、日時の指定も可能。 なお「prune」の意味とは、不要なものや余分なものを、削る、刈り取る、取り除くといったもの。 停止して24時間経過したコンテナと、使っていないイメージおよびネットワークを消す $ docker system prune -a --filter "until=24h" ... Are you sure
第61回 GitHub ActionsとAmazon ECSを使ったDockerアプリケーションの自動デプロイ（3） | gihyo.jp
Perl Hackers Hub 第61回GitHub ActionsとAmazon ECSを使ったDockerアプリケーションの自動デプロイ（3） （1）はこちら、（2）はこちらから。 GitHub Actions── ビルドとデプロイプロセスの自動化 （3）では、先ほど作成したECS環境に、GitHub Actionsを用いて自動的にアプリケーションをビルドしてデプロイするしくみを構築します。 GitHub Actionsとは、GitHubがgithub.comに統合した形で提供するCI（Continuous Integration、継続的インテグレーション）/CD（Continuous Delivery、継続的デリバリ）環境です。GitHub Actionsには、ソースコードのpullやPull Requestのアサインといった豊富な機能（アクション）が用意されています。ユーザー
DockerとRemote Containersでの開発環境が最高過ぎる - Sweet Escape
この投稿がきっかけでソフトウェアデザインに寄稿しています。この投稿の加筆修正ですが、自分のパート以外にもVS Code全般の特集となってますので興味あるかたはぜひそちらも！ ソフトウェアデザイン 2021年6月号 作者:tsutsu,吉岩 正樹,中村 充志,西谷 圭介,erukiti(佐々木 俊介),結城 洋志,上田 隆一,八田 昌三,サリチル酸,結城 浩,山川 正美,大串 肇,松本 直人,清水 洋治,広田 望,松田 佳希,田中 宗,中島 明日香,くつなりょうすけ,高橋 永成,金谷 拓哉,佐藤 雄飛,梶原 直人,髙濱 暢明,星川 真麻,八木澤 健人,けんちょん(大槻 兼資),職業「戸倉彩」,森若 和雄,大隈 峻太郎,小野 輝也,河野 哲治,古川 菜摘,石井 将直,杉山 貴章,Software Design編集部技術評論社Amazon はじめに Remote Containers Docke
令和時代のRails運用
https://shuuu-mai.connpass.com/event/173794/
magicpak: 静的リンクなしで小さなDockerイメージを作る - molecular coordinates
おはようございます！！！coord_eです、よろしくどうぞ。 実行に必要なファイルだけをうまく集めれば、静的リンクせずとも小さなDockerイメージを作ることができます。本記事では、その作業を自動で行ってくれるツール magicpak を作ったので、紹介します。 Dockerイメージ縮小オタク２（ツー） coordination.hatenablog.com ☝️前編です。実行に必要なファイルだけをうまく集めれば別に静的リンクしないでも小さなDockerイメージが作れるよねって話です。 本記事では、上の記事でやったこと（実行に必要なファイルを集める）を自動でやってくれるツール magicpak を紹介します*1。 magicpak: Build minimal docker images without static linking github.com magicpakは、対象の実行可能
CloudMapperをDockerで動かして、AWSのネットワーク構成を可視化しよう。 - Qiita
こんにちは。 AWSいいですよね。 でも、AWSって一つ一つのサービスがしっかり役割分担されているので、いざ一つのシステムとしてネットワーク構成図がどうなっているのかをみようとすると頭がこんがらがっちゃうんです、私。 そんなときCloudMapperにお世話になりたくなります。READMEを読んでいただければですが、現在のAWSのネットワーク構成図を自動生成してくれるやつです。 ただ、何度かチャレンジしているのですが、いつも何かが足りなくてうまく動かないんです、私。最近は何をやるにもDockerでやっちゃっているのでローカル環境もあんまり汚したくなくて... CloudMapper公式や他の方々もDockerで動くようにソースコードを公開していたりするんですが、なんでかうまく行かなかったりしたので、今回は自分でDockerfileから作ってみようという記事です。 前提 AWSアカウントがあ
First Docker GitHub Action is here! | Docker
We are happy to announce that today Docker has released its first Github Action! We’ve been working with GitHub, looking into how developers have been using GitHub Actions with Docker to set up their CI/CD workflows. The standard flows you’ll see if you look around are what you’d expect: building an image, tagging it, logging into Hub, and pushing the image. This is the workflow we’ve aimed to sup
DockerでCloudGoat環境を構築し秒速でAWSセキュリティに入門する | DevelopersIO
AWSを愛する皆さま、こんにちは。コンサルティング部の西野（@xiyegen）です。 CloudGoatを使用するためにはTerraformやAWS CLIの実行環境が必要なので、 「AWSセキュリティに今すぐ入門したい！」 とお考えの皆さまは環境構築を手間に感じるかもしれません。 そんな皆さまの願望を満たすよくばりセットDockerイメージが公式から提供されています。 こちらを使用し、秒速でCloudGoat環境を構築しましょう。 目次 おさらい CloudGoatとは https://github.com/RhinoSecurityLabs/cloudgoat CloudGoatはRhino Security Labs社によって開発されたAWSセキュリティ学習環境構築ツールです。 概要を下記のブログで紹介しておりますのでこちらもご参照ください。 ゆるふわIAM userのadmin権限
Go製ソフトウェアのCIやリリースをGithubActionsで行う
Go で書いた CLI ツールのリリースは GoReleaser と GitHub Actions で個人的には決まり を読んで、自分もどうやっているのか書いておこうと思ったので書く。 CIでテストを実行する これはまあ、素朴にやる。テスト自体はMakefileに隠蔽しておくと手元でもCIと同じテストを実行できて便利。 --- name: CI on: [push] jobs: run_test: name: Go Test runs-on: ubuntu-latest steps: - name: Set up Go 1.13 uses: actions/setup-go@v1 with: go-version: 1.13 id: go - name: Check out code into the Go module directory uses: actions/checkout@v
golangとDockerとOOM — KaoriYa
golangで書いたプログラムをDockerで動かしOOMが発生した際になるべく情報を残して殺される方法を紹介します。 2020/08/16追記: この記事の内容はgolangに関してはやや現実的ではなくなってしまいました。 詳しくは続編を参照してください。 TL;DR golang製のプログラムは仮想メモリ(VSZ)の確保に失敗するとgoroutineのダンプを吐いて死ぬ DockerのOOMはRSSベースで検出時にSIGKILLを投げてくる Docker利用時にVSZで制限をかけるスクリプトを書いた golang製のプログラムはlinux-amd64において最低でも101MBのVSZを要求する VSZの制限がそれより小さいと当然起動できない 実際のRSSは3MB程度で起動する Background コンテナ内で動いているプロダクション上のgolang製のプログラムが時々OOMに殺されて
コンテナのイメージ情報を簡単にコマンドで表示してくれるdockertagsが便利すぎる！
コンテナのイメージ情報を簡単にコマンドで表示してくれるdockertagsが便利すぎる！投稿者: adachin 投稿日: 2020/01/112020/01/11 Dockerfileでどのコンテナイメージ使おうかと毎回Docker Hubでググっていましたが、コマンドベース(CLI)で確認できるツール dockertags があまりにも便利すぎるのでご紹介したいと思います。 ■Whats dockertags https://github.com/goodwithtech/dockertags コンテナイメージの情報をシンプルに確認するツール dockertags をリリースしたので、記事を書きました。https://t.co/6qYGRVQau1https://t.co/ent49VbQBw — Tomoya AMACHI (@tomoyamachi) December 26, 20
Dockerコンテナ時代の第二章～Kubernetesの成熟とエコシステム発展の時代
Dockerの登場により急速に普及をはじめたコンテナ型仮想化の技術は現在、DockerコンテナそのものからKubernetesを軸としたオーケストレーションツールへと主役が移ってきています。 その様子は2017年12月に公開した記事「Dockerコンテナ時代の第一章の終わり、そして第二章の展望など」で紹介しました。 この記事の公開から2年が経過し、現在のコンテナ型仮想化技術は、マイクロサービスやクラウドネイティブなどの文脈とともにエンタープライズな分野でも使われるメインストリームな技術へと確実に進み続けています。 本記事では前記事で描いたDockerコンテナ時代の第一章に続く第二章として、コンテナ型仮想化技術のここ2年半ほどの動向をPublickeyなりにまとめてみました。 Docker 1.0の到達とKubernetesの登場 まずはDockerとKubernetesの登場とその後の主要
docker-composeを便利にするツール「dip」を使ってみた｜TechRacho by BPS株式会社
更新履歴 2019/11/27: 初版公開 2020/05/01: サブコマンド実行部分に追記 2021/04/14: dip 7.0に合わせて更新 2021/07/16: docker-composeコマンドをdocker composeに置き換え dipとは dipは、Rails開発会社のEvil Martiansのメンバーが作った、docker-composeでの作業を能率的に行えるツールです。dipはDocker Interaction Processの略だそうです。 dipはRubyで書かれているのでRuby実行環境が必要です。元々Rails向けに作られたツールのようですが、Evil MartiansのReactアプリにもdip.xmlがあることからわかるように、Railsに限らず一般のdocker-composeでも使えます。私の場合はローカル開発環境でのみ使っています。 追記
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Rails on Docker
GitHub - coord-e/magicpak: :hammer: Build minimal docker images without static linking
Docker Buildにおけるリードタイム短縮のための3つの改善ポイント | PLAID engineer blog
Terraform、Docker、Kubernetesなどのテストを自動化する - Yevgeniy Brikman氏のQCon SFでの講演より
