みなさんさようなら,最近デプロイが趣味の@h3_potetoです. この記事は,僕が趣味で改善していたCrowdWorksのデプロイ周りの大改造の歴史を振り返ります.基本的には,デプロイが趣味の方向けの記事です.とても長いです. 手動構築の時代 その昔,CrowdWorksのサーバは手動で構築されていました. 手動でRuby等の設定をいれたサーバを複数台用意し,そこにcapistranoデプロイをしていました. インフラは手動構築だった割に,なぜかBlue/Greenデプロイを実現していました.Blue/Greenの実現方法 まずはじめに,Blueが稼働系Greenが待機系 です.Blue/Greenデプロイをする際には,Green系にデプロイをして,Blue系と挿げ替え,旧Blue系をそのまま廃棄します. この動作をどこで実現しているかというと,なんとCrowdWorksのアプリ

クラウドワークスの缶コーヒーエンジニアの森田(@minamijoyo)です。 だいたい毎日缶コーヒーを飲みながら主にインフラ周りの仕事をしてるので、クラウドワークスのインフラの一部は缶コーヒーでできていると言っても過言ではないんじゃなかろうかと思う今日この頃。ちなみに最近のマイブームはFIREのハワイアン微糖です。 これまでのあらすじ クラウドワークスではAWS(Amazon Web Services)でサーバを運用しており、AWSでのIAM(Identity and Access Management)ユーザのグループポリシーの管理について、以前こんな記事を書きました。TerraformでAWSのIAMユーザのグループポリシーを管理する - QiitaTerraform+Atlas+GitHubでAWSのIAMユーザのグループポリシーをいいかんじに管理する - クラウドワークス エン
Scala大好きインフラエンジニアの九岡(@mumoshu)です。マイブームはConcourse CIですが、今日はマイクロサービスの話をさせていただきます。 TL;DR; 「サービスの負荷上がってきたし、マイクロサービス化しよう。マイクロサービス化って、Railsアプリ分割して、それぞれCapistranoでデプロイしておけばいいんでしょ?」*1 マイクロサービス化をするためには、アプリケーションだけでなくインフラや運用のことも考える必要があります。 この記事では、クラウドソーシングのクラウドワークスが来るマイクロサービス化に向けて認識しているデプロイメント上の問題とその対策を紹介します*2。 テストからデプロイまでがめんどくさいよ問題 →Dev/Prod Parity、Infrastructure as Code、CI、ビルドパイプライン リリースに1時間かかるよ問題 →ビルドキャッシ
1リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く