AWS Solutions Architect ブログ
はじめに ソリューションアーキテクトの安川 (@thekentiest)です。AWS ElasticBeanstalkがDockerに対応したという発表がされて以来、実際に利用してくれるお客様や、ブログを書いてくれる方がたくさんいて、嬉しい限りです。 最近ではローンチ当初に比べてDeployの仕組みも改善され、Deploy時にはStagingコンテナが立ち上がり、その立ち上げが完了した後に旧コンテナとの切り替えが行われるようになり、よりダウンタイムが短くなったので、使い勝手も良くなってきたかと思っています。 ところで皆さん、Dockerを使ったDevOpsを行う際、コンテナイメージを置くレポジトリはどうされていますでしょうか？ベースイメージだけを公開レポジトリ等から取得して、毎回コンテナをBuildする場合にはそれほど悩まないかもしれませんが、構築済みのコンテナイメージをPullしてDep
デプロイ作業の属人化を徹底的に排除したい話 - @kyanny's blog
ここ数カ月、デプロイとリリースについて、同僚や友人と議論したり雑談したりする機会が数多くあった。そんな折に、友人から Facebook のリリースエンジニアリングチームについて教えてもらった。曰く、 Facebook ではリリース作業を専門とするチームがあり、そこのメンバーは開発ブランチのコミットとそれに付随する ITS の議論を精査した上でリリースに値する変更をリリースブランチへ cherry-pick するのだそうだ。 2012/07/25 追記 Facebook のリリースエンジニアリングについては Facebook のリリースと文化 - Kato Kazuyoshi を参照のこと cherry-pick は無いわー、というのは置いておくとしても、リリースという極めて重要な作業が特定の人たちに委ねられている点に恐ろしさを感じた。嫌だと思うのはなぜなのかしばらく考えて、デプロイ作業の属
安全なリリースのために心がけていること - クックパッド開発者ブログ
こんにちは。会員事業部の高田です。今回は安全にリリースをするために、アプリケーションエンジニアとして心がけていることについて書きます。 クックパッドではなるべく早くユーザーに価値を届けることを大切にしているため、1 日に何度も安全にリリースできるしくみや、リリース後に発生したエラーにすぐに気付けるしくみがあります。しかし、アプリケーションレイヤーの問題はアプリケーションエンジニアが気をつけなければいけません。私個人としては、少し気をつければ防げた問題を起こしてユーザーや会社に迷惑をかけてしまった経験があるため、注意深くなっています。 プロジェクトの大きさや目的はさまざまあり、早くリリースして検証したい施策などもあると思います。今回は慎重にリリースしたいプロジェクトの例として、有料会員の解約の前に特定のユーザーにのみクーポンを配布するという架空のプロジェクトを元にお話します。 1. 準備 リ
謎のトラブルでcapstrano3移行に失敗した話 - くりにっき
表参道.rb #4 で発表しようと思って資料を作ったものの参加できなくなったので資料だけ上げておきます。 スライド版 sue445.github.io スライドのソースコード https://github.com/sue445/omotesandorb-04 以下はスライド本文です。スライドをmarkdownで書いているとブログにもそのまま貼り付けられて便利 謎のトラブルでcapstrano3移行に失敗した話 #omotesandorb sue445 2015/09/03 表参道.rb #4 自己紹介 sue445 株式会社ドリコム 所属 サーバサイド全般の雑用 インフラ、アプリ、ライブラリ、社内ツールetc 鉄砲玉なのでこの会社で一番最初にcap3の人柱になった（2013年末くらい？） TDDおじさん プリキュアおじさん 【今期の嫁】キュアトゥインクル 【本妻】キュアピース Agenda
Server::Starterから学ぶhot deployの仕組み - $shibayu36->blog;
以前http://tech.naver.jp/blog/?p=1369の記事を読んだのだけれど、それまでにprocessの知識が無かったりして、まったく理解できませんでした。そこでWorking with UNIX ProcessesやServer::Starterの中身を呼んでようやくhot deployの仕組みを理解できた(気になっている)ので、Server::Starterの実装を追いながら、それをまとめてみます。 hot deployとは hot deployとは「再起動の時にリクエストの処理を続けながら、変更の内容を反映するための手段」です。 通常serverをrestartさせるときは、stop -> startの流れになると思いますが、この場合stopしてから、start出来るまでの期間にリクエストを処理できない期間が発生します。その期間なしにdeployする仕組みがhot
事前にprecompileしたassetsをS3に配置してdeployを高速化する方法 - HK's Weblog
Railsで作られているサービスとおもわれるbasecampやgithubはassetsファイルをアプリケーションサーバとは別のCDN(akamaiやCloudFront)サービスから配信している。 CDNに配置する事のメリットとして世界中のEdgeサーバからassetsを配信できるのでどこからアクセスしてもページロードが速い事が一番大きいが、 副次的な効果として事前にassets:precompileすることが可能なためcapistranoでのdeploy時にprecompileしない戦略を取ることによって大幅にdeploy時間を短縮できるメリットがある。 (assetsをgit等ににコミットしてしまってprecompileせずにdeployする戦略もあるがコミットログが汚くなるため避けたい) 今回はasset_syncというgemを使ってS3にassetsを配置しつつcapistran
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Scalable Deployments - How we deploy Rails app to 150+ hosts in a minute
GitHub - mislav/git-deploy: git deployment made easy
Webアプリのデプロイ今昔物語