Books For Site Reliability Engineering
By: Heather Adkins, Betsy Beyer, Paul Blankinship, Ana Oprea, Piotr Lewandowski, Adam Stubblefield Can a system be considered truly reliable if it isn't fundamentally secure? Or can it be considered secure if it's unreliable? Security is crucial to the design and operation of scalable systems in production, as it plays an important part in product quality, performance, and availability. In this bo
PHPにおけるシンボリックリンクを使ったデプロイの危険性について（「realpath_cache」和訳）
2016/10/31 PHPにおけるシンボリックリンクを使ったデプロイの危険性について（「realpath_cache」和訳） PHP サーバーサイド この文書は@julienPauliさんによる記事「realpath_cache」の日本語翻訳です。元々は@gilbiteさんがKLab社内向けに翻訳したものでしたが、日本語では見たことがない指摘を含んでおり今でも有用だと考えたため、@julienPauliさんの了解を取った上で@hnwが修正・追記して公開するものです。 はじめに PHP に realpath_cache_get(), realpath_cache_size() という関数があることをご存じでしょうか？ また、php.ini に realpath_cache から始まる設定項目があることは？ realpath cache は知っておきたい極めて重要な概念です。 特に、コードの
コードの可読性、ハッカビリティ、抽象化 | POSTD
def deploy(ip): copy('code/', ip + ':~/code', recursive=True) write_template('conf/config.py', ip + ':~/config.py') write_template('conf/crontab', ip + ':~/.crontab') write_template('conf/crontab', ip + ':/etc/apache2/httpd.conf') run_as_root('service cron restart') run_as_root('service apache restart') post('https://pingdom.com/api/2.0/checks', { 'name':ip, 'host':ip, 'type':'ping' }) タスクを実行するものと
Herokuとwerckerによる継続的インテグレーション・自動デプロイでperlのwebアプリケーションを開発する - 平常運転
この記事ははてなエンジニアアドベントカレンダー2014の17日目です。昨日は id:cockscomb による Swiftでenumとジェネリクスを活用したかっこいいAPIクライアントを書く でした。 このエントリでは、CIツールのwerckerとアプリケーションプラットフォームのherokuを組み合わせることでperlのwebアプリケーションのCIを行い、自動デプロイする環境を実現する方法について述べます。 動機 今回のエントリで述べる自動デプロイの流れについては、はてなで11月に行った開発合宿のために筆者、および筆者の開発チームで必要になったために構築されました。 id:onishi によるサービス開発合宿のエントリにもあったように、今回の合宿では合宿先から社内へのVPNが整備されていないことなどから、社内の開発用サーバに依存しないしない各種PaaSを用いた環境を構築することになりまし
Herokuのメリット、デメリット - Qiita
メンテナンスコストがほぼゼロ ほぼ何もしなくても勝手に動いてくれます。 個人的な体感値だとAWSでEC2やロードバランサで環境を組んだ場合と比べると1:100ぐらいの手間無し感です。 デプロイがコマンド一発 デプロイは基本的にgit push heroku masterでHerokuにpushするだけです。(Railsのマイグレーションを行う場合はheroku run rake db:migrateも必要) 自分でデプロイスクリプトを頑張って書かなくてもいいので楽です。 スケールアウトがコマンド一発、もしくはGUIで非エンジニアでも操作可能 Herokuはdynoという独自のWebサーバプロセスの単位で操作するのですが、heroku ps:scale web=3でプロセス数を変更出来ます。 Herokuサイト上のダッシュボードからバーをスライドさせる事によって1〜100までdyno数を変更
Meteorがバージョン1.0に到達
オープンソースとして開発されているWebアプリケーションのフレームワーク「Meteor」がバージョン1.0に到達したと発表されました。 Meteorの最大の特徴は「Live updates」と呼ばれる、アプリケーション内の変数の内容がサーバと全てのクライアントでつねに同期している点です。ブラウザなどから入力や変更された変数の値は、自動的にサーバ内のデータベースに反映され、同時にほかのブラウザ上で実行中の同じアプリケーション内の変数の値にも反映されます。変数の内容を動的に画面に反映するテンプレートエンジンの機能も備えています。 つまりデータベースの項目をアップデートしたり、データの変更をチェックするために定期的にブラウザからサーバへポーリングするといったコードは一切不要で、例えばチャットのような、利用者全員がリアルタイムに情報を共有できるアプリケーションの開発が劇的に容易にできるようになりま
GitLab flowから学ぶワークフローの実践 | POSTD
Gitによるバージョン管理では、従来のSVNなどよりずっと簡単にブランチングやマージができます。さまざまなブランチ戦略やワークフローが可能であり、以前のシステムに比べるとほとんど全てが改善されたと言えるでしょう。しかしGitを利用する多くの組織はワークフローの問題に直面します。明確な定義がなく複雑で、Issue Tracking Systemと統合されていないからです。そこで、明確に定義された最良の実践的方法としてのGitLab flowを提案したいと思います。issue trackingには feature driven development と feature branches を組み合わせます。 他のバージョン管理システムからGitに移行する際によく耳にすることは、効果的なワークフローの開発が難しいということです。この記事ではGitワークフローとIssue Tracking Sys
Google Compute Engine、ワンクリックでRuby on Rails環境をデプロイする機能を追加
Google Compute Engineは、いわゆるIaaS型のクラウドサービスを提供するサービス。利用者は自分でOSやデータベース、言語の実行系などをインストールする必要があります。 しかし今回追加されたワンクリックデプロイ機能では、管理画面からボタンを押すと自動的に以下のソフトウェアのデプロイが行われるため、手軽に開発環境を用意できます。 Apache Webサーバ Apache上でRoRアプリを動かすPassenger Ruby on Railsフレームワーク MySQL Googleは先月、ワンクリックでMongoDBや、Node.js、AngularJSといった「MEANスタック」をデプロイする機能を発表したばかりでした。一連の機能追加は開発者に向けてGoogle Compute Engineを簡単に使える開発環境としてアピールするものだといえるでしょう。
Google Compute Engine、サーバサイドからクライアントまでJavaScriptで開発できる「MEANスタック」のワンクリックデプロイ機能をサポート
Google Compute Engine、サーバサイドからクライアントまでJavaScriptで開発できる「MEANスタック」のワンクリックデプロイ機能をサポート WebアプリケーションのサーバサイドからクライアントまでJavaScriptで開発できる「MEANスタック」が海外では少しずつ話題になってきています。MEANスタックとは、次のソフトウェアの頭文字をとったものです。 MongoDB：NoSQLデータベース Express：Node.js対応のフレームワーク AngularJS：Webアプリケーションのクライアント用JavaScriptフレームワーク Node.js：サーバサイドJavaScriptエンジン オープンソースであるLinux、MySQL、Apache、PHP/Perlの組み合わせが「LAMPスタック」と一般に呼ばれるように、JavaScriptを軸にした上記の4つの
PHP 製デプロイツール「Rocketeer」を使ってみた | 株式会社メイプルシステムズ
こんにちは。西山です。 毎日続く炎天と夕方に来襲する豪雨で夏らしさが一気に全開になりましたね。 今回はデプロイツール「Rocketeer」についてご紹介したいと思います。 これは GitHub上で公開されているオープンソースソフトウェア (OSS) です。リポジトリは https://github.com/Anahkiasen/rocketeer にあります。ライセンスは MIT です。 デプロイツールというと、以前の現場で Capistrano を使っていたのですが、これは Ruby 製ですね。 Rocketeer は Capistrano に似た構成を持つ PHP 製のソフトウェアです。普段、PHP の案件に関わることが多いのですが、デプロイツールも同じ PHP で書かれていたほうが安心感（？）がありますよね。 また、Composer や PHPUnit の実行にもデフォルトで対応
Facebookの継続的デプロイメント - ワザノバ | wazanova
https://www.facebook.com/publications/514128035341603/ 1日500件、3,000ファイルに及ぶ本番アップ フロントエンドのコードは1050万行、内850万行がPHP 開発エンジニア1,000名とリリースエンジニア3名 QAやテスターは存在しない 自分でプロジェクトを選ぶ & 自己責任のカルチャーが強い。 1/3のファイルが一人のエンジニア、1/4が二人のエンジニアでメンテされている。 フロントエンドの本番コードベースは一つのものを共有 日常業務ではローカルのgitを利用。本番アップ可能になれば、中央のレポジトリにマージして、それからSubversion（過去の経緯で使っている。）にコミットする 同じエンジニアがコードをコミットする間隔は中央値で10時間 本番にプッシュする前に、担当エンジニア自身でのユニットテストを終え、同僚によるコード
Amazonは1時間に最大1000回もデプロイする。クラウドネイティブなデプロイとはどういうものか？ AWS re:Invent基調講演（Day2 AM）
Amazonは1時間に最大1000回もデプロイする。クラウドネイティブなデプロイとはどういうものか？ AWS re:Invent基調講演（Day2 AM） クラウドによってリソースの制約から解放され、サーバやネットワークを含む冗長性までプログラミング可能になった新しい世界では、どのような考えによってソフトウェアを構築すべきなのか。 Amazon.com CTOのWerner Vogels氏は、Amazon Web Servicesが先週ラスベガスで開催したイベント「AWS re:Invent」2日目午前中の基調講演で、新しい時代のアーキテクチャとはどういうものなのか、聴衆に向けてたっぷりと解説しました。 （本記事は「AmazonクラウドのCTO「クラウドネイティブなアーキテクチャには4つの戒律がある」。AWS re:Invent基調講演（Day2 AM）」の続きです。 戒律その2「リジリエ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Osquery
DeployStudio / Home