GitHub Project機能が強化されたのでZenHubから移行することを検討してみた | feedforce Engineers' blog
こんにちは!新卒エンジニアのtsubです! 本日Appleから新型のMacbook Proが発表されたということで早速ポチりました。Touch barのハックにワクワクしております。 そして同じく本日GitHubでProject機能が強化されました。 Introducing Projects for Organizations 私が所属しているチームではZenHubを利用しています。GitHubのProjectはZenHubのBoardに近い機能です。 できることなら余計な拡張など入れずにGitHubを純正で使いたいため、今回も移行を検討してみました。 前回の移行検討のおさらい 知っての通り、GitHubのProject機能は以前からリリースされています。 リリース当時にも移行を検討しましたが、その時は見送りという形になりました。 弊社エンジニアの @yukiyan が検討してくれた記事は
mhaとconsulでDBサーバーの冗長化をしています | feedforce Engineers' blog
こんにちは。Lorentzcaです。3月ですがまだまだ寒いのでなかなか釣りに行けずテンションさげぽよです！ ↑↑ この度DBサーバー(物理マシン、MySQL)の引っ越しを行いました。 そのついでに、冗長化の仕組みをmhaとconsulを使った方法に変えたので紹介します。 はじめに まずは簡単に引っ越し前と引っ越し後の構成を比べてみます。 引っ越し前は以下の様な構成でした。 サーバー台数: 2台 MySQLフェイルオーバーの仕組み: 自作シェルスクリプト アプリの参照先を切り替える仕組み: keepalivedでvipを張り替えることで実現 引っ越し後は以下の様な構成になりました。 サーバー台数: 3台 MySQLフェイルオーバーの仕組み: mha アプリの参照先を切り替える仕組み: consulのdns機能を使って実現 なぜこのような構成にしたのか、話していきます。 引っ越し前に持っていた
terraformを使ってAWS環境を構築する | feedforce Engineers' blog
お久しぶりです。tjinjinです(╹◡╹) 最近じめじめしていますね。梅雨あけると夏ですよ！！夏アニメが始まりますよ！！ ということで、PV見た感じの私のおすすめは六花の勇者です！”りっか”ではなく”ろっか”です！ AWS環境のコード化 弊社ではAWS環境の構築を管理コンソールでの温かみのある作業やRakeTaskで行ってきましたが、サービスを新規で立てるのに時間がかかるという課題があり、AWS環境もコード化したいという思いがありました。インフラチーム内で検討した結果、 名前がかっこいい コードが読みやすいということで一部サービスでterraformを採用し始めています。 terraformを使って行く中で、何点か壁にぶち当たったので情報共有できればと思います。 terraformとは？ 一言で表すとインフラ構成をコード化することのできるツールというところでしょうか。みんな大好きHash
Vagrantで簡単に作れる！！RubyやKyotoTycoonのrpmたち | feedforce Engineers' blog
皆さんお元気ですか。 Debian GNU/Linux好きだけど、最近rpmの作り方を習得した増田です。 昔話 初めてRedHat Linuxに触れたのは7.1の頃(2002年？)。あの頃は配布されているrpmが少なく、make installに逃げていました。 そんな中出会ったDebian GNU/Linux。配布パッケージが膨大で、手動ビルドの手間から逃れることが出来ました。Emacsとか興味あるアプリはビルドしてましたが。 サーバのCIとrpm作成 時は流れ2014年。先日こんな記事を公開しました。 JenkinsでサーバのCIを始めました | feedforce Engineers' blog 実はこの時は、CookのたびにRubyやKyotoTycoonをビルドしていたため、CIに30分くらいかかっていました。CIに使うEC2インスタンスはt1.microでしたし。。 これでは使
個人で使ってみた Docker とCoreOSとか | feedforce Engineers' blog
こんにちは。 技術チームの星野と申します。 社内勉強会で、Dockerfileの作り方とか、CoreOSでのDockerでのデプロイ方法の一例を紹介しました。 ↑はその際のスライドです。前半のポエムっぽい序章は、適当に読み飛ばしていただければと思います。 個人としてDockerを試している理由は、構成管理をDockerfileというシンプルな形式で記述しようとしているところが魅力的だったからです。 「CoreOSの発表」と言いつつ、デモでは「CentOS7」も使ったりしました(CentOS7がリリース直後だったから!!)。 CentOS7ではsystemdがデフォルトで動いており、弊社ではCentOSを採用しているサービスも多いため、ここぞとばかりに試させていただきました。 補足 あと、スライドの補足として、今回デモで動かしたCoreOSの起動〜Jenkinsコンテナ起動までのスクリプトの
「今日から始める Go言語 と appengine」というテーマで社内勉強会をしました | feedforce Engineers' blog
はじめまして！DF Plus開発チーム エンジニアの いのうえ と申します。 少し前にはなるのですが、表題のテーマで社内勉強会にて発表をしたので、その資料をこちらでも公開したいと思います。 弊社での主な開発言語はRubyで、またプラットフォームも CentOS の専用サーバだったり、AWS EC2だったり、なのですが、私が前職で Google App Engine（以下 appengine）メインの仕事をしていたことと、その appengine で使える言語であり、最近異様な盛り上がりを見せてきている言語である、ということで、 『Go言語』 と 『appengine』 のふたつをいっきに、私の勉強会のテーマとして取り上げさせて頂きました。（弊社では採用技術ではないものを社内勉強会のテーマとして取り上げたりすることもよくあります^^） と、いう理由は言わば建前で...。 好きなんです！僕は！
Mercurial はじめの一歩 | feedforce Engineers' blog
弊社ではソースコードの管理に Subversionを使用していますが、個人的に興味があるので、分散バージョン管理システムの一つである Mercurialを触ってみました。 Mercurialとは mercurial [マ キュ リアル] 機敏な、快活な、水銀(mercury/記号Hg)の→コマンド名 hg 分散バージョン管理システムのひとつ ほぼ Pythonで実装(diffのみC) バージョン1.0(2008/3/24) バージョン1.0.1(2008/05/22) フロントエンド TortoiseHg(Windows) / mercurial.el(Emacs) / Mercurial bundle( TextMate)など 分散バージョン管理システムとは バージョン管理システムのうち、中央リポジトリを持たない (特定のリポジトリをそう看倣すのはOK)もの リポジトリを複製する。 複製
駆け足でTrac | feedforce Engineers' blog
Tracとはなんぞや プロジェクト管理ツール。 Wiki + Subversion連携 + チケットシステム（BTS + 進捗管理） なにがうれしいの ブラウザ上でオールインワンのプロジェクト管理。 Wikiでドキュメント管理 Subversionリポジトリのブラウズができてチェンジセットが見やすくてソースも見られる。 バグやタスクをチケットとして発行して管理。BTSとして使える。フィールドカスタマイズも自由。 マイルストーンごとにチケットを登録しておくと進捗見える化 RSSやメールでチケットの更新をお知らせ さらにプラグイン機構で機能追加可能 うれしい。 なにがめんどくさいの Tracの暗黒面。 導入が面倒。RH7.3とか古いディストリに入れようとすると泥沼。最近のディストリなら比較的楽。 多機能ゆえの業。導入した直後に何していいのかわからん。 あー、また別のWiki記法覚えないといかん
負荷分散講習会 Apache編 | feedforce Engineers' blog
ゴール 負荷分散のいくつかの方法に関して理解する mod_proxy_balancerによる負荷分散クラスタが構築できる 基礎知識編 基本的な資料 主にクラスタによる負荷分散の資料。 - Apache モジュール mod_proxy_balancer - mod_proxy_balancerで中?大規模サーバー運用するときの勘所 - cyano あと社外秘資料。 負荷分散？ 複数台のサーバにアクセスを分散して、個々のサーバにかかる負荷を減らし、全体的に処理できるアクセスを増やすこと。 以下のようなアプローチがある。 DNSラウンドロビン DNSでひとつのホスト名に複数のIPアドレスを割り当てる方法 シンプル しかしダウンしているホストにもアクセスが振り分けされてしまう 冗長化と併用でなんとかなるかな？ 機能ごとにホストを分割 ウェブサーバとDBサーバの分割（基本過ぎるが一応これも負荷分散）
FFTT : Capistrano
※ この資料について 2006年4月の勉強会資料をCapistranoのバージョンアップ（現時点では1.3.1になってました）による仕様変更などに合わせてちょっと修正したものです。 質疑応答の部分は当時のままなので最初の質問が初々しいです。 Capistranoって何なのさ デプロイツール デプロイ=配備 参考 : Capistrano: Automating Application Deployment 一言で言うと複数のサーバ上で同時に並行してコマンドを実行できるツール。 複数のサーバで動いているサービスのデプロイを楽に行うことができる。 Rails起源なのでRailsに特化した部分もあるが、ほかのアプリケーションでも使える。 昔はSwitchTowerと呼ばれていた。はてなでも使われてる。 何がいいのか 複数サーバへの作業が効率化、自動化できる 定義済みの標準タスクに沿った運用をする
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
