タグ

herokuに関するmanabouのブックマーク (51)

  • Hubot を Heroku で動かして Slack から話す - Qiita

    これは Hubot Advent Calendar 2014 の 3 日目の記事です。 また @bouzuya の Hubot 連載の第 3 回です。目次は、第 1 回の記事にあるので、そちらをどうぞ。 前回は Hubot のインストール について紹介しました。Hubot をインストールし、shell アダプターで動かして簡単な動作確認をしました。今回は Hubot を Heroku で動かし、さらに Slack から話してみましょう。 ちなみに、前回の環境の続きとして扱っているので、環境の差異があればそちらを確認してください。簡単にまとめるとこんな状態です。 BOT 名 : uran アダプター : hubot-slack 変更 : なし。generator-hubot で生成したまま。 今回の目標 今回の目標は上記のとおり、Hubot を Heroku で動かして Slack 経由で話

    Hubot を Heroku で動かして Slack から話す - Qiita
  • GitLab+DroneでHerokuにCIする、という最高の環境を10分で作る - アルパカDiary Pro

    ※2015/4/17 GitLab7.9 / Drone0.3 版に記事をアップデートしました。 Drone0.3で大きく変更されたため、手順もだいぶ変わっています。 今回の手順で主な変更点としては以下の様なものがあります。 GitLabでDroneアプリケーションを登録する必要がある Drone側でリポジトリをsyncする機能が追加され、その中から選択する方式になっている Herokuへのdeployについて、0.3からsshキーではなくAPIキー(token)を用いる方法に変更されている GitLab+OSS版DroneをEC2に0から構築し、herokuにCIする という環境を10分くらいで作ってみます*1 また、すこしだけDroneについての説明もメモ程度ですが書き記しておきます。 GitLabとは/Droneとは GitLabGitHubクローンのOSSです。 DroneはTr

    GitLab+DroneでHerokuにCIする、という最高の環境を10分で作る - アルパカDiary Pro
  • DockerでミニHeroku!「Dokku」をさくらのクラウドで試す | さくらのナレッジ

    シンプルなPaaSで知られるHerokuは使っていますか?ちょっとしたWebアプリを作って試すには便利ですが、もっとマシンパワーが必要になったり、もっと自由に使ってみたいと思うこともあるでしょう。 そんな要望を叶えるためのソフトウェアがDokkuです。DockerをベースにしたHerokuクローンになります。Dockerなので任意のクラウド、VPSサーバ上に立てることができます。今回はさくらのクラウドを使ってDokkuを実行する手順を紹介します。 さくらのクラウドでUbuntuサーバを立てる 追加をクリックします DokkuはUbuntu 12.04 x64または14.04 x64をサポートしています。LTSとは言え、ここは14.04を選択することとします。アーカイブにUbuntu Server 14.04 LTS 64bit(基セット)が登録されていますので、ここから選ぶだけでOKです

    DockerでミニHeroku!「Dokku」をさくらのクラウドで試す | さくらのナレッジ
  • チャット経由でデプロイする - Qiita

    最近開発で利用している、デプロイをチャット経由で行うフローについて説明します。 要点 開発者はmasterブランチで開発する 開発者はデプロイしたいときにBotにお願いする Botはmasterブランチからproductionブランチに対してPull Requestをつくる 開発者はPull Requestを確認してmergeする CIはproductionブランチが変更されるとサーバにデプロイする ChatOps masterブランチからproductionブランチにPull Requestを出す作業は面倒なので、チャット経由で行っています。Heroku上で動かしたRubotyにruboty-githubとruboty-aliasというプラグインを入れて、「デプロイしたい」と発言するとPull Requestを作成するように設定しています。チャット経由で物事を行うようにすると、周知や教育

    チャット経由でデプロイする - Qiita
  • 無料で作るWebサービス Herokuを使ってWebサービスを作ってみた(前編) - 今日学んだこと

    休日。何かしなければという焦りがあるんだけど、何をしようか思いつかない。 現在の飯のタネである(僕はいわゆるSIer)システム系の勉強を、最近してないことに気づいてはいるんだけど、インフラの構築に気が行ってしまって、なかなかスタートを切れない(どうせなら借りているVPSに対して色々と自動化して・・・と)。 そこでインフラの部分に気を取られることは無いHerokuを使って、何か作ってみることにした。 >> できあがったもの >> http://studysuggest.herokuapp.com ※後ろの方にも書いてますが、綺麗に何かを作るより、まず動くものを作って公開するというのを主題にしてます。 Herokuとは ざっくりとまとめると 高負荷でなければ無料で利用できる 定期的にバックグラウンドで◯◯動かす みたいな事やると、無料枠超える可能性出てくるので注意 gitにソースを上げて、流し

    無料で作るWebサービス Herokuを使ってWebサービスを作ってみた(前編) - 今日学んだこと
  • Hubot と Jenkins をつかって heroku への Deploy 環境を用意した - Qiita

    はじめに 過去に Hubot と CircleCI をつかって Heroku への Deploy 環境を用意したネタを投稿したことはありましたが、体験期間を過ぎてしまったので Jenkins server を用意して CI 環境を用意しました 前提な話 これをやるために必要な環境とかその辺の話 Jenkins server (VPS) ローカルとかでもいいけど hubot でみんなが使えるようにしたかったので vps にしました 構築系の話は他にわかりやすい資料がたくさんあったので今回は割愛します GitHub ぎっはぶぎっはぶ Hubot 動作環境 (Heroku) hubot を vps におけばいいじゃないかってなりそうだけど個人的なサービスを Heroku で公開していくことを想定して Deploy 環境を VPS にしてそこから Heroku へ Deploy できるようにしたい

    Hubot と Jenkins をつかって heroku への Deploy 環境を用意した - Qiita
  • Deploy to Heroku / Webアプリケーションのポータビリティ再び - naoyaのはてなダイアリー

    Heroku の新機能で Heroku Button が出た。 見るよりも、触る方が早い。以下のボタンを押すと md2inao をあなたの Heroku アカウントにデプロイして、動かすことができる。 ボタンを押すと以下のような画面が出て、Deploy to Free を押すと直ちにデプロイが始まる。 GitHub からソースコードが Heroku にデプロイされて、Web アプリケーションが動く。 ご満悦。 このボタンを README.md に置いておけば、Webアプリケーションを自分で動かしたいなと思ったユーザーが、自分自身の環境で好きな時にそれをデプロイして使うことができる。 すなわち、Heroku Button で、URI を介した Web アプリケーションの交換が可能になった。 Heroku Button Heroku Button を有効にするための前提は割とシンプルで Git

  • Deis: DockerベースのHeroku的PaaS - ワザノバ | wazanova

    Deisは、Heroku的なワークフローを実現する Docker/CoreOSベースのPaaSです。オープンソースのプロジェクトですが、既にOpDemandが運営会社になっており、同社はこれまでに約2.5億円の資金調達も完了してます。フルタイムでオープンソース開発を担当する正社員の募集も始まって、最新バージョンは0.9.1という段階のようですので、これから格的に立ち上がっていくのでしょうか。 Deisのクリエーターであり、OpDemandのFounderでもあるGabriel Monroyのが、dockdercon 2014でDeisのこれまでの進捗を紹介しています。 Deisは最初のマルチホストDocker PaaS。最初はPythonで書いていたが、最近はGoが中心。 フルタイム5名 + ~40名のコントリビューター すぐにプロトタイプをだしてコミュニティからのフィードバックをもらお

  • HerokuのAPIデザイン

    Herokuが自ら実践しているAPIデザインガイドをGithubに公開した. “HTTP API Design Guide” このガイドは些細なデザイン上の議論を避けて,ビジネスロジックに集中すること目的としている.Heroku特有なものではなく,一般にも十分適用できる知見となっている. 最近は,モバイル向けにAPIをつくることも多いため,勉強もかねて抄訳した.なお内容は,HTTP+JSONのAPIについて基的な知識があることが前提となっている. 適切なステータスコードを返す それぞれのレスポンスは適切なHTTPステータスコード返すこと.例えば,“成功"を示すステータスコードは以下に従う. 200: GETやDELETE,PATCHリクエストが成功し,同時に処理が完了した場合 201: POSTリクエストが成功し,同時に処理が完了した場合 202: POSTやDELETE,PATCHリク

  • GitHub - interagent/http-api-design: HTTP API design guide extracted from work on the Heroku Platform API

    You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

    GitHub - interagent/http-api-design: HTTP API design guide extracted from work on the Heroku Platform API
  • API設計のポイント - ワザノバ | wazanova

    Living Socialが7回に渡りSOA (Service-oriented architecture) についてのブログを書いてますが、今回はAPI設計についてのエントリーです。 「APIはRESTful」と言うだけでなく、社内でガイドラインがオーソライズされるように調整すること。設計にあたっての選択肢及び自由度をしっかり考慮すること。そして一番大事なのは、決めた原則とおりにブレなくインプリすること。 どのHTTPステータス(success/error)をどのシチュエーションで採用するか。 204もしくは200をPOSTで使うか?PUTで使うか? 4xx番台のコードの一貫性。 bodyにエラーメッセージを追加するのか。 認証はどこで? ヘッダー?もしくはURLパラメータ? リソースの階層はどうするか。 忠実にRESTfulとするのか、RPCのようなエンドポイント(/inventory

  • 「実践DevOps! SonicGarden流Herokuガチ運用術!」というテーマでCIO安達とHerokuでの運用について話しました | mah365

    運用=監視ではない。現状把握(監視)+リスク低減(リカバリ)=運用である。 今「データ保全に細心の注意をはらっている」と言いましたが、単純に「バックアップが行われているか?」「コピーしたDBダンプが保存されているか?」をチェックするだけでは運用とは言えません。運用=監視ではないんですね。 監視観点を網羅することでしっかりと現状把握をするのと同時に、いざ問題が起こったときに速やかにリカバリできる必要があります。 SonicGardenでは主に以下のリスクを念頭に置き、問題が起こったときに速やかにリカバリできるようにしています。 アプリケーションデータの一部が破損するリスク ログファイルを一定期間保存(デフォルト3年分)し、ログからのリカバリを行えるようにする。 データベース内のデータの一部が消滅するリスク リージョンをまたいだ冗長化バックアップを行い、もしもの場合には別リージョンを利用したサ

    「実践DevOps! SonicGarden流Herokuガチ運用術!」というテーマでCIO安達とHerokuでの運用について話しました | mah365
  • ScaleOut | Supership

    2024年4月1日より、Supership株式会社は親会社であるSupershipホールディングス株式会社に吸収合併されました。 合併に伴い、存続会社であるSupershipホールディングスは社名をSupershipに変更し、新たな経営体制を発足しました。件に関する詳細は、プレスリリースをご確認ください。 2024年4月1日より、Supership株式会社は親会社であるSupershipホールディングス株式会社に吸収合併されました。 合併に伴い、存続会社であるSupershipホールディングスは社名をSupershipに変更し、新たな経営体制を発足しました。 件に関する詳細は、プレスリリースをご確認ください。

    ScaleOut | Supership
  • ポータブルなwebアプリケーションとそのインフラの未来の一考

    naoya さんのポータブルな Web アプリケーションを受けて最近思ってることをば。140 文字で時々書いてるんだけど、まとまりがないので一回まとめておきます。 12-factor app ステートフルなアプリケーションについては、Heroku の人が提唱してる 12-factor app というのが現在の状況をよく表してます。 The Twelve-Factor App The Twelve-Factor App(日語訳) Heroku や他の PaaS によってもたらされたこうした一種の”制約”によって、アプリケーションの新しいカタチが生まれてきています。引き算によって新しい価値が生まれてきているわけですね。 とはいえ、PaaS は PaaS でそれぞれに独自の仕様を持っているわけですが、Herokubuildpack という仕組みを使って、Heroku とインタフェース仕様

    ポータブルなwebアプリケーションとそのインフラの未来の一考
  • The Twelve-Factor App (日本語訳)

    はじめに 現代では、ソフトウェアは一般にサービスとして提供され、Webアプリケーション や Software as a Service と呼ばれる。Twelve-Factor Appは、次のようなSoftware as a Serviceを作り上げるための方法論である。 セットアップ自動化のために 宣言的な フォーマットを使い、プロジェクトに新しく加わった開発者が要する時間とコストを最小化する。 下層のOSへの 依存関係を明確化 し、実行環境間での 移植性を最大化 する。 モダンな クラウドプラットフォーム 上への デプロイ に適しており、サーバー管理やシステム管理を不要なものにする。 開発環境と番環境の 差異を最小限 にし、アジリティを最大化する 継続的デプロイ を可能にする。 ツール、アーキテクチャ、開発プラクティスを大幅に変更することなく スケールアップ できる。 Twelve-F

  • ポータブルなWebアプリケーション - naoyaのはてなダイアリー

    140文字で書ききれなかったのでブログに殴り書き。 Heroku のアプリケーションを人に渡す 昨日、「naoyaさんが作ってるiOSアプリのバックエンドサーバーに相乗りさせてもらえないか」という話をいただいた。自分でも同じようなAndroidアプリを作っているけど、サーバーサイドは作ってないからということらしい。 対して「githubにコードあるからgit cloneしてheroku pushすれば動くし、自分で heroku にデプロイしてよ」と応えた。相乗りしてもらってもよかったのだけど、こちらでコードを書き換えたりメンテしたときに先方のアプリが停止することを考えると同じコードベースでサーバーは自分で立ててもらう方が何かと良い。 対象になったソフトウェアは Heroku で動かしていたので、Heroku Ready な形、つまり、必要な外部パッケージの一覧やサーバーの起動手順なんかは

    ポータブルなWebアプリケーション - naoyaのはてなダイアリー
  • GitHub - dokku/dokku: A docker-powered PaaS that helps you build and manage the lifecycle of applications

    You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

    GitHub - dokku/dokku: A docker-powered PaaS that helps you build and manage the lifecycle of applications
  • Deploying Python and Django Apps on Heroku | Heroku Dev Center

    Expected files for Python Heroku automatically identifies your app as a Python app if any of the following files are present in its root directory: requirements.txt setup.py Pipfile If none of these files is present in your app’s root directory, the Python buildpack will fail to identify your application correctly. Python deployment flow When you deploy to Heroku, the dependencies you specify in y

    Deploying Python and Django Apps on Heroku | Heroku Dev Center
  • Node.js + Express を Heroku で動かすまでの手順まとめ - tacamy--blog

    普通の JavaScript も jQuery もまともに書けないけど、はじめての Web アプリを Node.js でつくってみるという奮闘記。 環境つくるだけなのに何も分からなすぎてハマりすぎて、この一連の流れだけで丸 2 日潰れるという大惨事だったので、ちゃんとブログに残しておく。 Node.js のインストール Node.js の INSTALL ボタンから、インストーラを使って入れることもできるけど、Node.js のバージョンを切り替えて使える方が便利だと思うので、前回のエントリを参考に nodebrew を使ってインストールするのがオススメ。 node.js 入れるなら nodebrew が超簡単 - tacamy memo インストールが正しくできているか確認のため、Node.js のバージョンを表示。 $ node -v npm のインストール Node.js にはたくさ

    Node.js + Express を Heroku で動かすまでの手順まとめ - tacamy--blog
  • GitHub時代の開発委託とは? デブサミでQA@ITの事例の話をします - QA@IT公式ブログ

    2013年2月14日と15日の2日間にわたって東京・目黒で開催されるDevelopers Summit 2013(デブサミ2013)の1セッションで、QA@ITの委託開発の話をさせて頂くことになりました。 ソーシャルコーディング革命後の開発委託の世界〜QA@ITの事例(仮) 私はこれまでいつも、デブサミは取材記者という立場で見て来ました。記者として取材して、例えば以下の様な記事を書いて来ました。聴衆に混じって講演を聞く側だった私が、まさか話す側に回ることになるとはと、今からドキドキしています。 デベロッパーズ・サミット2008:すばらしいソフトを作るには、カリスマが講演 未来の言語は「APL」? Rubyのまつもと氏が講演 IIJRuby対応PaaS「MOGOK」は、どんなサービスか? さて、デブサミは開発者のイベントですが、私は委託側、つまり受託開発における「お客の声」ということでお話