月 5.5ドルで使える Vultr で nginx-proxy を構築して frourio を Docker で動かす！
はじめに この記事は、いままで Docker を開発環境としてお気持ちで使っていた初心者が書いています。 玄人の方々におかれましては、暖かい目で見守って頂けますと幸いです。 （誤っている情報などありましたらディスカッションにてお願いします…！） 最初は下の記事で紹介されている Vercel + Heroku での運用を考えていたのですが、Free Dyno があまりよくなかったので（スリープしたり、時間枠の概念だったり）悩んでいました。 👇 Vercel + Heroku 構成の紹介 そこで知人が Docker ベースでの VPS 運用を勧めてくれて、その知人の手厚いサポートの末になんとか構築できました。本当にありがとうございます！ (単純比較できるものではないですが、Heroku Hobby は $7/月、Vultr は $5.5/月 なので自分で運用したほうが安い！) 完成図 Git
Laravel+Nuxt.jsでDocker開発環境構築からHerokuデプロイまで - Qiita
はじめに 本記事では「フレームワークをインストールして、それをインターネットに公開する」という0から1までのフェーズについて、Laravel+Nuxt.jsによって「蔵書管理」システムを構築して解説したいと思います。 また、実際に構築したシステムは下記になります。 - Heroku: https://frozen-castle-47874.herokuapp.com/ - Github: https://github.com/kon-shou/bcm-qiita-example 目次 システムアーキテクチャ Laravel/Nuxt.jsインストール Docker環境構築 Nginx設定 Typescript対応 サーバーでのモデル/ビジネスロジック実装 フロントでのモデル/ビジネスロジック実装 Heroku設定 システムアーキテクチャ 下記の技術スタックを用います。 サーバーサイド: L
Docker を用いてソフトウェアをデプロイするとソフトウェアの品質が上がる - Diary
Docker を用いてソフトウェアをデプロイするとソフトウェアの品質が上がる http://b.hatena.ne.jp/entry/bonotake.hatenablog.com/entry/2018/09/06/072800 ここをながめていて思ったことなんですが。 Docker はデプロイにのみ関連するツールであって、ソフトウェア開発の本質には一切関係ないものだ、という考えの人をたまに、いや、よく見る。これは全く間違っていて、 Docker を用いて継続的にソフトウェアをデプロイしているだけでソフトウェアの品質は上がります。ソフトウェアの品質のような問題について考えている人は Docker とそのメンタルモデルに興味をもつべきです。 本来こうした問題について僕がなにかを言う必要はなくて The Twelve-Factor App という文章を読めば十分です。あるいは 大切なことはだい
社内開発で使ってるSinatra + Datamapper + Heroku + Dockerの簡易テンプレート for Mac - Qiita
社内開発で使ってるSinatra + Datamapper + Heroku + Dockerの簡易テンプレート for MacRubySinatraHerokuDockerDataMapper なぜ？ 社内システムは、なるべくクラウドの既製品を使うという方針でIT部を運営していますが、ちょっとしたバッチ処理、自動監視、データ転送・変換処理なんかは自分で開発したほうが早かったりします。 そういった処理を実現するために、社内サーバを用意するのは面倒なので、Herokuを使ってサクっと作ってしまおうということを繰り返してきた結果、なんとなくテンプレートのようなものができたので、ここに公開しておきます。 なんでDockerを使うの？ 自分のMacの環境をできるだけ汚さないようにするためです。特にMacの場合はRubyの環境がmacOSのバージョンアップの度に大きく変わって、つらい思いをしたのでD
Go Web ApplicationをHerokuにデプロイ #herokujp
http://herokujp.doorkeeper.jp/events/10902
12 Factor App - モダンなサービス運営に必要な12のインフラ的要素 - Qiita
皆さんは、The Tweleve-Factor Appをご存知だろうか？ これはHerokuの中の人が書いた、Webアプリケーションを使いやすい形でスケーラブルにするための方法論である。簡単にいえばコンテナで動かしたいアプリケーションが守っておくとよいレシピ集であると言える。 http://12factor.net/ (日本語訳) 今回これを取り上げた背景としては、実はDockerコンテナをメインにした本番でのインフラ運用を考えた時に、アプリケーションがこの12の要素を満たしていることが重要だと最近ひしひし感じているから。 実際、自分が働いているところが運営しているサービス Wantedlyは、もともとずっとHerokuで運営していて、最近AWSに移行し、現在Dockerコンテナの上で動いている。この移行を約1ヶ月半で実現できた大きな要因として、Herokuの上に乗っていたことで知らず知ら
DockerによるマルチホストのPaaS flynnの概要とそのアーキテクチャー
“flynnの時代” “Docker meetup tokyo #3”で発表してきた．内容は，Dockerの応用の１つであるOSSでPaaSをつくるflynnというプロジェクトの概要とそのアーキテクチャーの紹介．このflynnというプロジェクトの中には，Dockerの面白い使い方がたくさん詰まってるため，今後Dockerを使う人が，その応用の際の参考になればという思いで紹介させてもらった． 今回の発表のために資料を集めまくり，理解できない部分は出来る限りコードも読んだ．発表スライドの補完にもなると思うので，そのメモ書き（一応体裁は整えた）を公開しておく． デモ 以下は，簡単なデモ． やっていることは以下． nodeのアプリケーションをデプロイ ルーティングの追加 スケール コマンドを含めた詳しい解説は以下で解説する． 前提知識 (Herokuの動作) まず，前提知識としてPaaS (ここで
ポータブルなwebアプリケーションとそのインフラの未来の一考
naoya さんのポータブルな Web アプリケーションを受けて最近思ってることをば。140 文字で時々書いてるんだけど、まとまりがないので一回まとめておきます。 12-factor app ステートフルなアプリケーションについては、Heroku の人が提唱してる 12-factor app というのが現在の状況をよく表してます。 The Twelve-Factor App The Twelve-Factor App（日本語訳） Heroku や他の PaaS によってもたらされたこうした一種の”制約”によって、アプリケーションの新しいカタチが生まれてきています。引き算によって新しい価値が生まれてきているわけですね。 とはいえ、PaaS は PaaS でそれぞれに独自の仕様を持っているわけですが、Heroku の buildpack という仕組みを使って、Heroku とインタフェース仕様
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
DockerベースのHerokuライクなオープンソースのミニPaaS・「Dokku」