RailsのECS移行事例なんて既に山ほどあるので、特に書くつもりは無かったのですが、実際にやってみると 時代が進んで、より便利なものが出てきている デプロイどうするのよ、となったときに各自が最強のECSデプロイツールを作っていて、参考にならない といった体験をしたので、最近やったECS移行の話を書くことにしました。 社内Qiitaに書いたポエムです pic.twitter.com/yDlWGhhkF1— wata (@wata727_) 2017年8月31日 もちろん、この記事も古くなると何の役にも立たないと思うので、古くなったら、みなさん頑張って調べてください。 ECS移行で考えるべきこと まず前提として、移行対象はシンプルなRailsアプリで、WebサーバとWorkerからなります。デプロイはCapistranoなどのいわゆる「Push型」で行っていたものとします。Railsに限定し
普段から docker-compose を利用して開発しているアプリケーションを、Circle CI 2.0 に対応させる作業を行ったので、今回必要になった設定をまとめておきます。 アプリケーションの概要このアプリケーションでは、フロントエンドに Node.js を利用しており、バックエンドに Ruby on Rails を利用しています。それぞれ docker-compose で Node.js と Ruby のサービスを動かしており、Circle CI でも docker-compose を利用してテストすることにしました。 設定内容設定と言っても、以下のようなファイルを用意するだけです。Circle CI では docker-compose を利用できるので、普段から docker-composeを使っているのであれば、ほとんど余分な設定無しにテストを実行できます。 まず Git リ
Building Docker images and configuring your dockerized apps doesn’t have to be a try-fail-repeat Google extravaganza. This article will help you work with Docker ARG, ENV, env_file and .env files with confidence. The only prerequisite: make sure that you’re comfortable with the basics of Docker. Read on and you will understand how to configure your Docker images and dockerized apps with ease - wit
はじめに Dockerfileとは docker imageを作成する際のコマンドをコード化したもの 公式ドキュメント Dockerfileは「コンテナを動かす」ためだけなら簡単に作成することが出来るが、工夫せずに書くと運用上いろいろな問題が発生する。 それらの問題点のほとんどは書き方のテクニックによって回避することが出来るが、それらのテクニックを駆使すると、今度はDockerfileの中が複雑になっていく。 Dockerfileはなぜ複雑にならざるを得ないのか 発生する問題とそれに対するテクニックを例を上げて説明していくことで理解してもらう。 rails5.1 hello world projectを例に説明する。 簡単なDockerfileの例 重要なのはFROMとRUNとCOPYのみ FROM ベースとなるimageの指定 https://docs.docker.com/engine
Introduction Docker Machine is a tool that makes it easy to provision and manage multiple Docker hosts remotely from your personal computer. Such servers are commonly referred to as Dockerized hosts, and as a matter of course, can be used to run Docker containers. While Docker Machine can be installed on a local or a remote system, the most common approach is to install it on your local computer (
はじめに Dockerを開発環境で使うことが多くなってきてますね。 使い捨てできる環境は本当に便利なので、本番環境にも使いたいなーと思って、本番運用で注意すべきセキュリティ周りを調べてみました。 基本的な考え方 基本的な考え方は以下になります。 コンテナ内部に入られるな 権限は最小限にせよ 監視を怠るな DockerといえどVPSやオンプレのセキュリティ設定と考え方は同じですね。 ここではDockerにまつわる話を書いていきます。 コンテナ内部に入られるな 信頼できるイメージを使う 多くの場合、ベースとなるピュアなOSイメージはDockerHub上のイメージを使いますが、元となるイメージがセキュアであるかどうかを確認して使うようにしましょう。 既知の脆弱性を含んでいる場合や、最悪の場合、悪意のあるスクリプトが仕込まれている場合があります。 既知の脆弱性が含まれているかどうかはDocker
関連記事 マイクロサービスを支えるインフラアーキテクチャ (AWS Dev Day 2019登壇資料) ECSデプロイツールを公開しました ECSにおけるログの取り扱いを別ページに移動させました 設計 基本方針 基盤を設計する上で次のキーワードを意識した。 Immutable infrastructure 一度構築したサーバは設定の変更を行わない Infrastructure as Code インフラの構成をコードで管理 (Terraformを採用) Serverless architecture 無駄にサーバを増やさない アプリケーションレイヤに関して言えば、Twelve Factor Appが参考になる。コンテナ技術とも親和性が高い。 ECSとBeanstalk Multi-container Dockerの違い 以前に記事を書いたので、詳しくは下記参照。 Dockerコンテナデプロイ
In this article I will be writing about common issues that I’ve stumble upon using AWS Elastic Beanstalk running Docker environment. I will be updating this article in future each time I stumble upon new issue (…or remember old one) that may happen to you. Pull Requests are welcome to add more know-hows to this article (Github logo at the bottom will redirect you to git source of this Markdown fil
本稿は良いDockerイメージを良い方法でビルドすることを探求した記録である。 Supership株式会社 Advent Calendar 2016の21日目にあたる。 2019年現在は@inductor氏の改訂版を見たほうが良い。 この記事で論じた望ましいコンテナイメージの姿は2019年でも変わらない。ただし、multi-stage buildのような新しい仕組みが普及したりツールの評価が定まってきたりと、実現に用いるツールの状況が2016年からやや変化している。 良いDockerイメージ 良いDockerイメージとは何だろうか。Dockerの利点は次のようなものだから、それを活かすイメージが良いものであるに違いない。 ビルドしたイメージはどこでも動く 適切にインストールされ、設定されたアプリケーションをそのままどこにでも持っていける。 コンテナ同士が干渉し合うことはないので、任意のイメ
We work with Dockerfiles on a daily basis; all the code we run for ourselves and for our customers, we run from a set of Dockerfiles. In this article, we’ll talk about what mistakes people commonly make, and how to write them better. For those of you who are Docker experts, a lot of the tips in this article will probably be pretty obvious and will just provoke a lot of head-nodding. But for beginn
現在、様々な環境で docker が動作します。先日同僚から、「docker はいろんな環境で動作するが、どの環境で動かせばいいの?」と質問を受けました。 今、初めて docker を始める場合、どこで環境を作ればいいのか迷ってしまうほどたくさんの選択肢があります。この問いに自分なりに答えてみたいと思います。 このポストは現在(2016/3/15)のところの私の個人的な意見を書いておきたいと思います。よりよい選択があれば是非コメントいただきたいと思います。 またこの話は、私より1000倍 docker に詳しい方に共有しておいたので、彼がもっといい記事を書いてくれるかもしれません! 1. 開発環境 開発や、docker を試してみたい目的で docker を動かす環境が欲しい場合、現在はほぼ一択で、「Docker Machine」を使うと良い。Docker Machine は、docker
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く