https://rubygems.org/gems/capistrano-pending/versions/0.2.0 Capistranoのプラグイン方式がv3.7から大きく変わって:scm変数が非推奨になり、さらにv4.0からは消されるらしく、その対応のため。といってもいただいたPRの挙動を確認しただけだけど。 github.com 仕組みが変わるのはメンテする側からすると厄介だけど、見た感じフックする方法やデフォルト値の設定のタイミングなどが整備されるみたいなので良さげな感じ。あと:scmが消えるというのも、Capistrano本体はリモート実行のフレームワークという側面が強くなって正統進化してるように見受けられる。 しかし今回の対応では英語でやりとりされてるニュアンスや、Capistrano自体の挙動やらがなかなか理解できなくて戸惑うことが多かった。
背景 アカツキではRailsでゲームサーバを開発しています。インフラはAWSにあり、CloudFormation, Chef, Capistrano を用いて、Infrastructure as Code を実現しています。 エンジニアは普段ローカルマシンで開発していますが、ディレクター、レベルデザイナーなどは定義ファイルを変えた後、それを反映して動作を確認するための検証サーバ(以下、検証環境)を使っています。 検証環境へのデプロイも Capistrano で自動化しており、最初は問題が無かったのですが、ゲーム上のデータが増えることによって、一度のデプロイで10分程度かかるようになっていました。 以下、Capistrano ver.2系の話にはなりますが、検証環境のデプロイを高速化したので、その内容を紹介したいと思います。 現状分析 rsync について、capistrano_rsync_
先週、とうとう Mackerel にグラフアノテーション機能がリリースされました。 mackerel.io この機能を使えば、「デプロイ実施」とか「ミドルウェアの設定を変更」などといったオペレーションの実施の記録に加えて、「経験値2倍キャンペーン開始」「CM放映スタート」といったビジネス施策としてのイベントの投稿もできるようになります。これらのイベントの以前・以後、といったグラフの見方がしやすくなるので、これは便利!! "Mackerel オタク" を自称している身(参考)としてはスルーできないワクワク機能!ということで、早速自分のアプリケーションにも組み込んでみることにしました。 capistrano のデプロイタスクにグラフアノテーションの POST を組み込む 今回はとりあえずのお試しということで、capistrano のデプロイタスクのうち deploy:starting でデプロ
今年、稼働中のサービスであるはてなブログのデプロイ方法を新しい方式へ無事故で移行し、従来と比べて約6倍速くデプロイできるようになりました。 この記事では、安全にデプロイ方式を変えたプロセスを順を追って紹介します。 はてなブログと継続的デリバリー デプロイが遅い 複雑なデプロイ設定 デプロイのテストを書く ボトルネックの発見、そして pull 型から push 型のデプロイへ 新デプロイへの移行 結果 まとめ はてなブログと継続的デリバリー はてなブログは1日あたり平均して1.02回デプロイを行っています。これは土日を除いた週5日の営業日に対する平均です。ざっくりとした算出で、祝日は考慮していません。5月と9月の祝日を含めるともう少し多くなるかもしれません。 また、原則として休日の前日にはデプロイしないことになっています。もしもデプロイした変更にバグがあった場合、休日が明けてから対応するか、
amakanをUnicornからPumaに移行した - ✘╹◡╹✘ に引き続き、小さい改善を加えた。 変更の概要 https://amakan.net/ への今後の変更に備えて、テストやデプロイに掛かる時間を短くする恩恵が良いだろうと思い、node_modulesの管理に使うツールとしてyarnを使うことにした。結果的に、テスト用ビルドの所要時間が130秒から70秒に、デプロイ用ビルドの所要時間が300秒から200秒になった。 CircleCIの設定変更 継続的なテストとデプロイ作業の実行のために、amakanではCircle CIを利用している。Circle CIを使っている理由は、仕事でも使っている上にPrivateでも無料だから。 yarnを利用するためにCircle CIに追加する必要があった設定は、以下の通り。 指定したバージョンのyarnが入っていない場合はインストールする グ
Capistrano3.5.0以降ではデフォルトでログがターミナルの横幅いっぱいまでしか表示されない 新しいrailsアプリケーションを作成していつも通りCapistranoさんをインストール。バージョンは3.5.0になったみたいです。 そしてもろもろ設定していつも通りbundle exec cap staging deploy! そしてしばらく様子を見ているとなんとなくログがオシャレになった気が。そしてbundler:installタスクに入ったその時! ・・・ 00:12 bundler:install 01 RBENV_ROOT=/usr/local/rbenv RBENV_VERSION=2.3.0 /usr/local/rbenv/bin/rbenv exec bundle insta… ✔ 01 hoge@123.123.123.123 0.986s ・・・ 実行コマンドが途中
もっとシンプルにできるやり方があれば教えてくださいませ! chefを動かしているCapistranoのログをよしなにする必要があり 標準出力とファイル出力の両方に出力することはできないかなと悪戦苦闘した記録になります。 - 参考 capturing output to log file require 'capistrano' require 'capistrano/logger' output = '/var/log/capistrano.log' custom_logger = Capistrano::Logger.new(:output => output) custom_logger.level = Capistrano::Logger::TRACE self.logger = custom_logger まず、こちらの設定で標準出力は行わず、ファイル出力されることを確認。 では合
こんにちは! ヌリカエ / 開発基盤エンジニアの @selmertsx です。 chatopsを導入しているチームで、chatops使える人と見れるだけの人を分けたいってことありますよね。 今回はそのための機能をご用意しました。 その機能を SpeeeKaigiで話したところ、ぎりぎり3位入賞をもらえましたので、 今回はそのお話をしたいと思います。 SpeeeKaigi自体については、こちらを御覧ください。 tech.speee.jp トークテーマ Rubotyで認可認証 & Deploy機能を作った話 キーワード chatops ruboty 認可認証 deploy 発表スライド 作成した gemはこちら。 https://github.com/selmertsx/ruboty-capistrano https://github.com/selmertsx/ruboty-authoriz
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? Joumae(錠前)というサーバレスの分散ロックサービスをOSSとして公開したので、ご紹介させていただきます AWS LambdaとAPI Gateway、DynamoDB、JAWSフレームワークなどを利用していて、小規模な社内利用であれば月々数十円で運用できます。 Webアプリ(joumae-users、joumae-resources) クライアント(joumae-ruby) Joumaeとは Joumaeはサーバレスの分散ロックサービス(Distributed Locking Service, Distributed Lock M
2. self.introduce => { name: “SHIBATA Hiroshi”, nickname: “hsbt”, title: “Chief engineer at GMO Pepabo, Inc.”, commit_bits: [“ruby”, “rake”, “rubygems”, “rdoc”, “tdiary”, “hiki”, “railsgirls”, “railsgirls-jp”, …], sites: [“hsbt.org”, ruby-lang.org”, “rubyci.com”, “railsgirls.com”, “railsgirls.jp”], } 5. 2014/11 の minne の状況 • IaaS の上で動くシンプルな Rails アプリケーション • Rails が動いているサーバーは 6 台 • デプロイは capistrano
machine: timezone: Asia/Tokyo ruby: version: 2.1.3 dependencies: pre: - sudo pip install awscli deployment: staging: branch: deploy-staging commands: - sh script/deploy-staging.sh: timeout: 1500 production: branch: deploy-production commands: - sh script/deploy-production.sh: timeout: 1500 CircleCIでのビルドは以下の6つののフェーズに分かれており、それを上記の設定ファイルに書いていくようだ。 machine checkout dependencies database test deploymen
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く