Discover amazing ML apps made by the community

RailsのECS移行事例なんて既に山ほどあるので、特に書くつもりは無かったのですが、実際にやってみると 時代が進んで、より便利なものが出てきている デプロイどうするのよ、となったときに各自が最強のECSデプロイツールを作っていて、参考にならない といった体験をしたので、最近やったECS移行の話を書くことにしました。 社内Qiitaに書いたポエムです pic.twitter.com/yDlWGhhkF1— wata (@wata727_) 2017年8月31日 もちろん、この記事も古くなると何の役にも立たないと思うので、古くなったら、みなさん頑張って調べてください。 ECS移行で考えるべきこと まず前提として、移行対象はシンプルなRailsアプリで、WebサーバとWorkerからなります。デプロイはCapistranoなどのいわゆる「Push型」で行っていたものとします。Railsに限定し

Railsにおけるログの出力方法について理解が浅く、勘違いをしていた。 自分と同じような人が１０人くらいはそうなので、基礎知識から簡単な表示方法をまとめる。 環境 Ruby 2.6.3 Rails 5.2.3 目次 ログと標準出力 Railsにおけるログの取り扱い ログへの書き込み ログへの書き込み ログと標準出力 今回大きな間違えをしていたのが、ログと標準出力を混同してしまっていたこと。 pなどで変数情報を表示する際に、pumaの出力(以下のようなrails sを立ち上げた際の画面)に表示されるものは、ログファイルに保存されるものと同じだと勘違いしていた。 Processing by SamplesController#index as HTML "-----デバッグ情報------" Rendering samples/index.html.erb within layouts/app

Amazon ECS のデプロイツール、ecspresso の v1.5.0 をリリースしたのでお知らせです。 github.com 今回は Amazon ECS Exec という新機能対応が目玉です。ほかにもお送りいただいたPRを取りこんだ各種修正が入ったリリースになります。どうぞご利用ください。 PRをお送りいただいた皆様、ありがとうございました！ 新機能 ECS Exec への対応を追加しました ホストから docker exec するように、Fargate に対しても起動しているコンテナに入ってコマンドを実行できる ECS Exec 機能がリリースされています。 aws.amazon.com ecspresso v1.5 では exec コマンドを追加して、AWS CLI なしで exec できるようにしました。session-manager-plugin は必要です。 exec

普段からECSを使っている方なら知っていると思いますが、2021/03/16(JST)にECSの管理下にあるコンテナに入ることができるようになりました 特にFargateでは、以前はなかなか回りくどい方法をとらないといけなかったのが、公式に機能が提供されたインパクトが大きく、界隈が盛り上がっていたように思います。 コンテナに入るコマンド aws ecs execute-command ... を使えるようにする方法は、公式ドキュメント他多くの情報があります。 ところで、私は普段ECSでデプロイを行う際に ecspresso を使っています。 ecspressoの導入や使い方についてはREADMEに詳しく書いてあるので省略しますが、execute-commandを使えるようにするのに少し躓いたので、有効化する方法を紹介します。 なお、以下は2021/04/09現在の最新版である v1.4.0

モチベーション 僕は自宅のサーバでいくつかの自宅用サービスを動かしています。全てのサービスはコンテナ化してあり、ホストマシン自体にはdockerとgitといくつかのツールぐらいしか追加していません。そんなサーバを前提にした話です。 前々から自宅サーバで動かしているサービスの継続的デリバリー( 以下CD )をしたいと思っていましたが、最初に思いついた幾つかの方法はどれも「これだ！」って感じがしませんでした。以下、思いついた方法です。 CircleCIにSSH鍵を登録してCircleCIから自宅サーバにSSHしてデプロイコマンドを叩く 外部に自宅サーバのSSH鍵を渡すのは怖い SSHのポート開くのもちょっと怖い githubからのwebhookを受け取ってデプロイコマンドを叩く webhookを受け取ってデプロイコマンドを叩くプログラム作らないといけない？ CDのログどうやって見る？ 自宅サー

Actionsの利用可能時間を気にせずに使えるセルフホスト設定をEC2で実際に試してみました。利用費的にも事前に超過することが判っている場合にはおすすめです、 はじめに GitHub ActionsのWorkflow利用可能時間枠は比較的多めだと思われますが、複数人で使う場合にはやはり上限が気になってきます。 利用枠を上限まで使い切ると動作が止まり、追加時間を購入することで再度動作可能となります。ただ、Workflow毎の実行ベース等読みにくい事も多々あり、足すべき枠の計算は困難だと思います。 Actionsはセルフホストの場合に利用可能時間枠の制限がありません。セルフホスト環境はクラウド環境でも可能です。利用時間が共有されないことと、使いすぎた分はAWS利用費で個々に跳ね返ってくるため分かりやすいこともあり、EC2でのセルフホスト設定を手順作成含めて試してみることにしました。 自分のラン

Amazon ECS でのコンテナデプロイの高速化 この記事は同僚の Nathan Peck (@nathanpeck)が書いた記事 “Speeding up Amazon ECS container deployments” を翻訳し、加筆・修正したものです. 元記事を ECS ユーザに紹介する機会が何回かあったので、せっかくなので翻訳することにしました. コンテナのオーケストレーションは非常に複雑な問題の一つです. アプリケーションコンテナのデプロイのために、相互にやり取りを行う複数の異なるコンポーネントが存在します. あなたのアプリケーションを実行したオーケストレータは、その実行されたアプリケーションが Web トラフィックを受け取る用意ができているかどうかについて判断する必要があります. その後そのアプリケーションはスケールダウンされたり、あるいは新しいバージョンのアプリケーション

BuildKit is a toolkit for converting source code to build artifacts in an efficient, expressive and repeatable manner. Key features: Automatic garbage collection Extendable frontend formats Concurrent dependency resolution Efficient instruction caching Build cache import/export Nested build job invocations Distributable workers Multiple output formats Pluggable architecture Execution without root

本記事の趣旨 令和時代のRails運用 こちらのスライドに掲載されている以下のDockerfileが、キャッシュやマルチステージビルドを利用したベストプラクティスとして参考になりました。 # syntax = docker/dockerfile:experimental # Node.jsダウンロード用ビルドステージ FROM ruby:2.6.5 AS nodejs WORKDIR /tmp # Node.jsのダウンロード RUN curl -LO https://nodejs.org/dist/v12.18.0/node-v12.18.0-linux-x64.tar.xz RUN tar xvf node-v12.18.0-linux-x64.tar.xz RUN mv node-v12.18.0-linux-x64 node FROM ruby:2.6.5 # nodejsをインス

概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: Build images on GitHub Actions with Docker layer caching — Martian Chronicles, Evil Martians’ team blog 原文公開日: 2021-03-11 著者: progapandist (And[re]y Bar[a]nov)、dragonsmith (Kirill Kuznetsov) サイト: Martian Chronicles, Evil Martians’ team blog -- ニューヨークやロシアを中心に拠点を構えるRuby on Rails開発会社です。良質のブログ記事を多数公開し、多くのgemのスポンサーでもあります。 はじめに: 適切なDockerレイヤキャッシングでGitHub Actionsでイメージを構築する方法

はじめに Docker イメージをビルドしていく上で、イメージサイズ軽量化や並列実行はどこの環境でビルドするか気にしないで行うことができました。 しかし、キャッシュの仕組みは環境によっても異なるなど複雑です。 本記事では、キャッシュの種類について紹介します。 レイヤーキャッシュ Docker イメージは層が重なることによってできています。 RUN hogeの層の上にCOPY fugaの層があり、その上にENTRYPOINT piyoの層があるという風になっています。 イメージのレイヤー構造はdocker history で確認できます。 例えば、マルチステージビルドでビルドしたadachikun/qiitatohatenaは以下のようになります。 さまざまなレイヤーが重なってイメージが構成されていることが分かります。 $ docker history 4a57f4eb178a IMAGE

Circle CI でも travis-ci でもなんでもいいんですが、とにかくデプロイ用に用意する assets:precompile を早くしたいというあなたむけの記事です。 bin/rake assets:precompile は public/assets 以下に配信用の assets を吐き出し、 manifest.json なども配置されますが、この public/assets ディレクトリをキャッシュするだけでは、次回の bin/rake assets:precompile は早くなりません。 継続的な bin/rake assets:precompile の実行を高速化するには public/assets だけでなく、 tmp/cache/assets も保存しておき、 assets:precompile 実行前に再配置しておく必要があります。 これにドはまりすると『CI

GitHub Actions のワークフローから別のワークフローを再利用する機能が昨年11月にリリースされました。この機能がなくて不便に感じていた人も多いのではないでしょうか。 GitHub Actions: Reusable workflows are generally available | GitHub Changelog Reusing workflows - GitHub Docs シンプルなワークフローを作って試してみました。 呼び出し側のワークフロー。同一リポジトリのワークフローを呼び出すには、uses キーワードを使ってプロジェクトルートからの相対パスで .github/workflow 配下のワークフローファイルを指定します。通常のジョブと違って runs-on などは指定しません。 name: Caller Job on: workflow_dispatch: job