ver1.0 Gartner ITインフラストラクチャ & データセンター サミット 2017 にて発表 ver1.2 OpenStack Days Tokyo 2017 にて発表Read less
ver1.0 Gartner ITインフラストラクチャ & データセンター サミット 2017 にて発表 ver1.2 OpenStack Days Tokyo 2017 にて発表Read less
サーバ/インフラエンジニア養成読本 DevOps編 [Infrastructure as Code を実践するノウハウが満載! ] (Software Design plus) 2016/02/26 に出版される「サーバ/インフラエンジニア養成読本 DevOps編」というムック本にて、特集「CircleCIによる継続的インテグレーション入門」を執筆しました。 CircleCIによる継続的インテグレーション入門 私が現在所属するKaizen Platform, Inc.でもCircleCIをヘビーユーズしており、サーバ/インフラ部分においても、 インフラCI 稼働中サーバへのプロビジョニング DNSレコードの管理 Terraformを用いたAWSリソースの管理 Packerを用いたAMI作成 稼働中サーバのセキュリティアップデート メトリクスグラフの取得&slackへの投稿 などにCircl
Hashicorpから2015年秋の新作が2つ登場した. Otto - HashiCorp Nomad - HashiCorp Ottoがなかなか面白そうなのでコードを追いつつ,Ottoとは何か? なぜ必要になったのか? どのように動作するのか? を簡単にまとめてみる. バージョンは 0.1.0 を対象にしている(イニシャルインプレッションである) Ottoとは何か? 公式はVagrantの後継と表現されている.が,それはローカル開発環境の構築も担っているという意味で後継であり,自分なりの言葉で表現してみると「OttoはHashicorpの各ツールを抽象化し開発環境の構築からインフラの整備,デプロイまでを一手に担うツール」である.ちなみにOttoという名前の由来はAutomationと語感が似ているからかつ元々そういう名前のbotがいたからとのこと. なぜOttoか? なぜVagrantで
O'REILLY Velocity 2015 Santa Claraが2015年5月27日から29日まで開催しています。ハートビーツからも松鵜と滝澤の二人が参加しています。 5月27日にチュートリアルに参加してきたのでその一部を紹介します。 後編も公開しました。(6月4日追記) なお、内容については紹介している資料を確認してください。聞き間違えたり、認識が違っているかもしれないためです。 ※写真は初日のチュートリアル終了後のパーティー会場に使われたLevi's Stadiumです。 Best practices for MySQL High Availability このチュートリアルではMariaDB FoundationのColin Charles氏がMySQLおよびその派生の高可用性(High Availability)についてベストプラクティスを紹介してくれました。 高可用性を実現
クックパッドのデプロイとオートスケール、1日10回デプロイする大規模サイトの裏側(後編)。JAWS DAYS 2014 大規模なオンラインサービスを支えるためのオートスケールと、サービスをすばやく進化させていくための迅速なデプロイ。クックパッドはこの2つをクラウド技術の組み合わせによって両立させています。 同社のインフラ責任者である成田氏がその仕組みやルールを、Amazonクラウドのユーザーコミュニティ主催のイベントJAWS DAY 2014で解説しました。 (本記事は「クックパッドのデプロイとオートスケール(前編)。JAWS DAYS 2014」の続きです) オートスケールはAmazon Auto Scalingを使わないと判断 今日の本題であるオートスケールの話をしたいと思います。 オートスケールとは一般に、トラフィックが増えたらサーバを増やしましょうね、という作業を自動化するものです
踊るホスティティングサービス 変化を強いられる時代 壁を越え、進む あの日僕が BASIC に挫折した事を忘れない オープンソースを積極活用、そして一次対応へ 閾値主義からの脱却 一次対応の闇 一度は仕事を辞める覚悟をした 正直、もう人間が運用や監視対応するのは限界かもしれない Serf the Librator ――運用対応自動化が、進化への鍵か 今日よりも鮮やかに 概要と書きたかったこと 師走です。年の瀬ですね。寒くなりましたね。コタツが恋しいです。ミカンおいしいです(^q^) そんな季節柄、ふと、自分の仕事を振り返りたくなりました。 僕はこれまで、ホスティングサービスの中の人として歩んできました。自分が何を考え、どのように行動を起こしてきたか。その経緯は、今の自分しか書けない気がして。色々なスライドや twitter では伝えきれなかった事を、一度まとめたいなぁと。なので、こうやって
ユーザー企業の情報システム部門で今、運用担当者の人数が大きく減り始めていることをご存じだろうか。 運用業務には、「アプリケーション保守」や「OS/ミドルウエア運用」、「ITインフラ運用」などがあるが、あらゆる業務に関わる運用担当者が減少しているのだ。まずは4社の事例を紹介しよう。 サイバーエージェント 運用担当者の人数 20人→0人(予定) サイバーエージェントで消費者向けWebサービスを手がけるアメーバ事業本部では、現時点で20人いるOS/ミドルウエアの運用担当者を、2年後の2015年までにゼロにする計画だ。 彼らは現在、OS/ミドルウエアをサーバーにインストールしたり、パッチを適用したり、アプリケーションの負荷に応じてサーバー台数を増減したりする業務を行っている。これらの業務を、オープンソースソフトウエアの運用管理ツール「Chef」を導入することで、自動化する計画だ(図1)。
フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発
まとめてたくさん処理したい! を解決する「Capistrano」:特集 DevOps時代の必須知識 インフラ運用の自動化を実現し、DevOpsを支援するツールはいくつかあります。ここではその中から「Capistrano」というツールについて、サンプルを用意しつつ紹介します。 はじめに インフラ運用の自動化を実現するツールには「Chef」や「Puppet」などいろいろあります。今回の記事ではそういったツールのうち、Capistranoというツールを簡単なサンプルを用意しつつ紹介します。 Capistranoとは Capistranoとは簡単にいうと、オープンソースで提供されている、複数のサーバ上で同時にスクリプトを実行するためのソフトウェアツールです。主に、同じ役割のサーバが複数台存在するような環境での自動化であったり、アプリケーションのデプロイ自動化に利用されています。 特にRuby On
DevOpsというキーワードに関連して、「Chef」というツールの名前を聞いたことのある人も多いのではないでしょうか。この記事では、インフラにおける構成管理、展開作業を自動化するChefの構造および基本的な使い方について解説します。 インフラストラクチャ自動化フレームワーク「Chef」 Chefは、物理、仮想、クラウドといったさまざまな大きさのインフラに対して、サーバやアプリケーションの展開を容易にするための自動化フレームワークです。 Chefの重要な要素の1つに「Infrastructure as Code」という概念があります。インフラをどのように構築し、維持するべきかという定義はRubyの文法で記述され、ソースコードのように扱うことができます。つまり、あたかもRubyでプログラミングをするように、インフラの構成管理をコードによって行えることがChefの利点の1つです。 自然言語による
2024年4月1日より、Supership株式会社は親会社であるSupershipホールディングス株式会社に吸収合併されました。 合併に伴い、存続会社であるSupershipホールディングスは社名をSupershipに変更し、新たな経営体制を発足しました。本件に関する詳細は、プレスリリースをご確認ください。 2024年4月1日より、Supership株式会社は親会社であるSupershipホールディングス株式会社に吸収合併されました。 合併に伴い、存続会社であるSupershipホールディングスは社名をSupershipに変更し、新たな経営体制を発足しました。 本件に関する詳細は、プレスリリースをご確認ください。
2. 自己紹介 安達 輝雄 ( id:interu ) ブログ: http://interu.hatenablog.com アプリ開発からインフラ構築運用まで手がけている 自称ハイブリットエンジニア チーフプログラマ http://www.skipaas.jp http://messageleaf.jp 3. SonicGardenが手がけるサービス一覧 自社サービス パートナーシップモデル ・データ販売サイト ・植物栽培キッド販売サイト ・ドキュメント配信 ・SEO関連サービス ・Flash動画生成サービス ・・・etc たった7名のメンバーでやってました。 2月から新メンバー2人追加決定!
やっと、”qpstudy 2013.01” の内容がまとまりましたので、この場をかりてご報告します。なお、今回の内容は、qpstudy内での情報だけを元にまとめたものであって、課題の調査に、他のソースは使っていません。 これを元に次のフェーズに入るとした場合、調査も含めて言及するつもりです。 めずらしく、いきなり本題に入ります。 今回の”qpstudy 2013.01“で解決したかった課題は です。Dev と Ops とで異なる企業が案件を受託した場合、そこでは同一企業内の部門同士のバトルとは比較にならないほどの、バトルが繰り広げられています。「お客様に価値を届ける」「お客様至上主義」「お客様を一番に」たくさんのスローガンをもって、企業はお客様にサービスを届けていますが、DevOpsをうまく取り入れて実践されている SIerと言うものはあるでしょうか? あったとしてもごく少数であったり、真
あれは昨日のことでした。 qpstudy 「DevOpsをぶち壊せ(仮) ~DevOps言うな(仮)~」 に参加してきました。 devops関連のパネルディスカッションということでしたが登壇者が豪華。 パネル自体もあれだけど、登壇者の方と懇親会で話したくて参加してきました。 ただの参加者なのでとても気楽。ビールもたくさん飲みました。 devopsと直接関係はないけどtwitterや懇親会や二次会で大盛り上がりしたのが教育について。 ある一定ライン以上の自動化とかしようとすると数学(確率統計とか待ち行列理論とか)と計算機科学は本当に本当に大事なのでちゃんと修めておけばよかった。 単位はとったけど忘れてる。あのときに知識が残っていたらこんなに伸び悩まないのにな…(泣 懇親会ではmizzyさんkenjiskywalkerさんysaotomeさんはじめいろいろとたくさん話せて満足。 懇親会でも少し
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く