概要 Amazon ECS 上で実行するコンテナをローカルでテストする際ってどうしてます？ すでにご存知の方はバシバシ使われているかもですが、改めて焼き直しということで本ブログを書いていきます。 紹介するツールは、こちらの amazon-ecs-local-container-endpoints と ecs-cli です。 ちなみに ECS ってなにもの？ Amazon ECSとは、AWSのフルマネージドなコンテナオーケストレータサービスです。 また、コンテナが実行される場所(データプレーン)としては、fargate、EC2、Anywhere などがあります。 amazon-ecs-local-container-endpoints まず初めに amazon-ecs-local-container-endpoints についてです。 一言で表すと、ECS 上で実行するコンテナをデプロイする
Docker-in-Docker でお手軽 Amazon ECS Anywhere お試し環境を手に入れる | トリの部屋
『手軽に作って壊してができる ECS Anywhere お試し環境が欲しい』、あるいは『ECS Anywhere で遊んでみたい気持ちはあるけどそれだけのために Raspberry Pi を買う1気にはならない』、という方向けの記事です. TL;DR x86_64 なラップトップが手元にあるなら… VirtualBox で VM を作ればサクッと試せる ただし VM はそこそこ重い M1 Mac なみなさまは… VirtualBox は残念ながら M1 Mac 未サポート というか ARM 未サポート お金を出せば Parallels で ARM な VM を作れる2ので、それも可 💸 VMware Fusion は残念ながら記事執筆時点で ARM 未サポート というわけで、本記事では Docker-in-Docker を利用して (M1 Mac でも) ECS Anywhere する手
概要 下記記事にありますとおり、Docker Compose to ECS pluginを用いることで これまでDocker Composeで起動していたコンテナ群をECSへデプロイすることが可能となります。 Docker Compose と Amazon ECS を利用したソフトウェアデリバリの自動化 サンプルアプリケーション 動作確認をおこなうため公式のサンプルアプリケーションを利用させてもらいます。 サンプルアプリケーション 下準備 Contextの確認 以下コマンドで現在のContextを確認します。 docker context list 表示結果例 $ docker context list NAME TYPE DESCRIPTION DOCKER ENDPOINT KUBERNETES ENDPOINT ORCHESTRATOR default * moby Current
TL; DR 以前、社内向けにDocker/Kubernetes入門の勉強会を開催したのですが、今回はそれに引き続き、AWS Fargateに関する勉強会を開きました。 speakerdeck.com 資料の目的 前回の勉強会の資料についてはこちらをご覧ください。 inductor.hatenablog.com 今回の勉強会については、前回Kubernetesに入門してからそこそこ概要を理解した前提で、AWSのマネージドサービスであるECSやFargateの実態や、その特徴について理解してもらうために開きました。 ECS初心者がつまづきがちな、FargateとECSを比較してしまう問題や、そもそもECSというサービスの立ち位置などについて改めて解説した資料となっています。 インフラ向けではありますが、開発者が見てもわかりやすくなるよういくつか前提知識のスライドも含めていますので、もしよけれ
こんにちは、エムスリーエンジニアの園田です。 この記事は先日のAWS FargateでElixirのコンテンツ配信システムを本番運用してみた - エムスリーテックブログの続きです。 エムスリーでは医療・ヘルスケアサイト向けのコンテンツ配信システムであるChuoiというサービスを運用しています。先日のポストで、ElasticBeanstalkからFargateに運用を切り替えたことについて書きました。 www.m3tech.blog 今回はその実装編で、実際のコードを見ながら説明します。 まずは構成のおさらいです。 Fargate化のためにやったこと AWS Fargateで運用するために実際にやった作業は大まかに以下の通りです。 Elixir/PhoenixアプリのDocker化 Docker化したアプリのFargate動作確認 社内GitlabからのCI/CDパイプライン構築 Terra
このエントリはRails developer meetup 2017で発表した内容をブログとして書き出したものです。 サンプルのスニペットが多いので資料の代わりにエントリとして公開します。 スライド用のmarkdownを元に起こしたものなので、少し読み辛いかもしれませんがご容赦ください。 ECSとは Dockerコンテナを稼動するためのクラスタを管理してくれるサービス 使えるリソースを計測し、自動でコンテナの配置先をコントロールしてくれる kubernetesではない。最近、kubernetesが覇権取った感があって割と辛い 今はEC2が割とバックエンドに透けて見えるのだが、Fargateに超期待 ECS or EKS :tired_face: RailsアプリのDockerize オススメの構成 実際にデプロイするimageは一つにする 例えばstagingやproduction等のデプ
問題 Macのローカルで動作していた HashiCorp Vault のDockerイメージをAmazon ECSに持っていったら、タスクが起動停止を繰り返してしまう症状が発生した。 環境 Docker image / 0.8.3, https://hub.docker.com/_/vault/ ECSインスタンス / amzn-ami-2017.03.g-amazon-ecs-optimized (ami-21815747) 原因と対策 ECSインスタンスにログインして、ログを確認したところ、 $ docker logs <CONTAINER ID> Error initializing core: Failed to lock memory: cannot allocate memory This usually means that the mlock syscall is not
Using Docker and OverlayFS on Amazon ECS
If you’re using the ECS-optimised Amazon Linux AMI for your ECS instance hosts, the Docker engine on these instances will be using the devicemapper storage driver. Though this is a fine default for many use cases, you might want to switch to use the overlay/overlay2 storage driver. When we were setting up our Buildkite agent cluster on ECS, we found that the default devicemapper storage driver pro
以前こんな記事を書きました hatappi.hateblo.jp この記事ではDigdagをDocker上で動かす際にsession情報をDataVolumeにおくことでコンテナを立ち上げ直した時もsession情報を参照できるようにするというものでした これはECS上でも実現することは出来る データボリュームについてかかれたドキュメント 画面上から作成することも可能だが最近Hakoを使っているのでこれを使って実現したい 今回実現したいこと コンテナインスタンスにボリュームを追加してコンテナにてマウントポイントを指定したい Hakoの設定 scheduler: type: ecs region: ap-northeast-1 cluster: test-cluster app: image: digdag-sample memory: 3000 mount_points: - source
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに 現在お手伝いしているアカウンティング・サース・ジャパンにて、ECSを使ったDockerの本番運用を始めたので、その一連の流れについてまとめました。 税理士向け会計システムを扱うアカウンティング・サース・ジャパンでは最近Scalaでの新規プロジェクトが立ち上がってきており、既存のプロジェクトはJavaであったり、Erlangであったりと様々な言語が用いられていますが、インフラ人員が少ないということもあり、なるべくシンプルなインフラ構成を実現する必要がありました。 そういった中、各アプリケーションをDocker化することでインフラ
github.com 最近Hakoを使い始めたのでノウハウをためていく Hakoとは?? Dockerコンテナをデプロイするためのツールです Hakoがうまれた背景はECS を利用したデプロイ環境 by Kohei Suzukiによると ECSを利用しつつ、秘匿値の注入や関連するリソースや設定を操作するデプロイツールが必要 だったからだそうです 今回のHakoの使い方 Dockerコンテナをデプロイする hako deployの他に hako oneshotというECSのRunTaskAPIを呼び出し単発の実行を行うものがあるのですが、今回はこのhako oneshotを使います 今回試すものとしては 実行中のログをCloudWatch Logsになげる 秘匿値の管理方法 の2つを確認していきます なお今回ECSのクラスター名はtest-clusterというものを使用したとします 実行中の
Speee開発基盤部、兼ヌリカエエンジニアの森岡です。 今回は、ECSを使ってPR毎に確認環境を構築する社内ツールであるwebapp-revieee をOSSとして公開しましたので、そのご紹介をさせて頂きます。 作ったもの PRを作ると、そのPRに対応した確認環境がECS上に構築され、PRに構築した確認環境にアクセスするためのURLがコメントされます。 ここで構築された確認環境は、PRがcloseされると一緒に閉じられます。主にデザイナの画面確認や、制作物のPOレビューなどが捗ります。 この社内ツールは一つのプロダクトだけでなく、社内のすべてのプロダクトの確認環境を用意することが可能です。 この社内ツールは、Webapp Revieeeという名前で開発されました。 作った理由 今回このような社内ツールを作った背景として、確認環境の構築に時間的、金銭的コストを掛けたくない。 という理由があり
こんにちは。エンジニアの志村です。 cluex-developers.hateblo.jp の続きとなります。 今回はタイトル通り、デプロイ辺りを執筆していければと思います。 Blue-Green Deployment Blue-Green Deploymentはマーチン・ファウラー氏が提唱したデプロイ方式です。 blue, greenとほぼ同じ本番環境を2系統用意してデプロイを行います。このデプロイ方式ですが、 ダウンタイムの極小化 ロールバックが容易 という大きな2つの利点があります。 Dockerizeへのモチベーションとして前回の記事にも書いたのですが、徐々にドッグフーディング環境・本番環境で差異が出てきました。 そのような状況だと、ドッグフーディングでは正しく動作したのに本番環境では意図した挙動とは違うという場面も出てきます。 上記のようなトラブルがあった際に今までのIn pla
Amazon EC2 Container Service (ECS) と CircleCI を活用した Docker ベースなコーポレートサイト コーポレートサイトを一部リニューアル 今月のはじめに、弊社のコーポレートサイトを一部リニューアルしている。 内容だけではなく、バックエンドのシステム側も AWS OpsWorks を使って構築した環境へデプロイしていたものから、 Amazon EC2 Container Service (ECS) を使った Docker ベースのものへと変更している。 弊社では、これまで開発環境では Docker を使っていたが、本番環境での Docker 運用はしていなかった。 そろそろ本番環境でも Docker を使った環境に移行したいと思い、 ECS 環境への移行を行った。 今回は、その移行の際のポイントをまとめてみたいと思う。 Docker Hub 前述
cloudpack大阪の佐々木です。 ECSでコンテナ用のボリュームを作ったらどこに保存されるか？という話です。 ECSで使うamazon-ecs-optimizedのAMIはデフォルトでは下記のディスク構成になっています。(2015.09.d 以降) /dev/xvda 8G /dev/xvdcz 22G Amazon ECS に最適化された、2015.09.d 以降の AMI を使用している場合、インスタンスには 2 つのボリュームが設定されます。[Root] ボリュームはオペレーティングシステム用で、2 番目の Amazon EBS ボリューム (/dev/xvdcz にアタッチ) は Docker 用です。 永続化データを取り扱う場合、ボリュームを追加すると思います。/dev/xvdcz はDocker用ボリュームってことなので、当然そちらに作られるのかと思ったのですが、違うようで
nazoです。 Graceful RestartによるRailsアプリのデプロイ を行っていたのですが、もっと手軽に環境ごとデプロイをしたいという需要もあって、Dockerを採用したデプロイも行っています。 CircleCI(1.0)では辛うじてDockerのサポートがありますが、いくつか癖があるので、ECSと含めて運用まで踏まえた手順について紹介したいと思います。 目的 AWS EC2 Container Service（以下 ECS ）を使用し、DockerコンテナをEC2にデプロイします。github.comにコードをpushしたら CircleCI 上で自動でビルド・テスト・デプロイが行われるようにします。 ECSを使う理由は、AWSへの依存をぎりぎり少ないところで手軽にDockerコンテナのデプロイを行いたかったというところです。ECSを使用することにより、簡単にDockerコン
戦略 開発環境はDockerComposeでRails + MySQL + Redisな構成 ファイル同期にはDockerSyncを使う 本番環境はECS + RDS + ElastiCache ALBを使って動的ポートマッピング nginxは使わず、pumaでリクエストを受ける assetsはDockerコンテナに含めてビルド CDN（CloudFront）を経由して配布 CircleCIでRailsコンテナをビルド＆デプロイ ECRにイメージをpush db:migrateなどはECS RunTaskAPIを叩く デプロイはecs-deployツールを利用 決めてないこと cronの運用方法 CloudWatch + LambdaでRunTaskAPI叩く kuroko2やsidekiq-cronなどのお手軽ジョブスケジューラを入れる 現時点の感触 DockerComposeな環境で開
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Amazon ECS adoption trends