AWS Startup Meetup #13 LT 登壇資料です。 Infrastructure as Code(IaC)を導入したものの、IaC化した恩恵が思っていたより少なく、IaCで基盤を統一していく方針を転換していった話をご紹介します。
AWS Startup Meetup #13 LT 登壇資料です。 Infrastructure as Code(IaC)を導入したものの、IaC化した恩恵が思っていたより少なく、IaCで基盤を統一していく方針を転換していった話をご紹介します。
木曜日に Codenize Meetup に参加してきた.Codenize.tools には様々なツールがあって,有名なものだと Roadworker(Route 53 の設定をコード化) / Piculet(セキュリティグループの設定をコード化) / Miam(IAM の設定をコード化)など.タイミング良く Roadworker と Piculet を検証していたので, 実際に運用で Codenize.tools を活用している現場の話を聞いてみたく,抽選も当たって参加できて良かった. codenize.connpass.com cloudinfra-audio に Codenize.tools 開発者の @sgwr_dts さんが出てて,Roadworker を作ることになった背景とか,裏話っぽいことが聞けるので良い!オススメ! cloudinfra.audio Infrastruct
2. 吉羽龍太郎 / Ryuzee.com ✤ アジャイル開発/DevOps/クラウドに関する従量課 金型コンサルティングサービスを提供 ✤ http://www.ryuzee.com @ryuzee 3. コンテキスト設定 複雑な領域 探索 理解 反応 カオスな領域 行動 理解 反応 込み入った領域 無秩序 な領域 理解 分析 反応 明白な領域 理解 分類 反応 ✤ 1チーム〜数10チームくらいの規模を想定 ✤ とてもお硬い領域というよりは変化の大き い領域の話 4. Infrastructure as Code (1) ✤ なんらかのアプリケーションを動かすためのインフラをコードで記述すること ✤ コードで書くことで再現性を高められる (はず) ✤ コードで書くことによって、ソフトウェア開発のプラクティスがインフラにも適用可能 になる
「リクルートテクノロジーズ オープンラボ」はリクルートグループのサービス開発やインフラの運用を手がけるリクルートテクノロジーズが主催する技術勉強会です。毎回テーマを設け、社内外から講師を招いて開催していく予定です。 第3回となる今回のテーマは Infrastructure as Code です。 Infrastructure as Code を大局的な視点から語る、という内容がメインで、実践的な内容は少なめです。Infrastructure as Code の過去と現在から、未来がどのようになっていくのかを考える、そういった場としたいと考えています。 18:30 - 開場 19:00 - 19:05 はじめの挨拶 伊豆原 大也 (Recruit Technologies ATL) 19:05 - 19:30 "Infrastructure as Code" から数年、結果どうなったか
どうも、セクションナイン の 吉田真吾(@yoshidashingo)です。 週末にKINGSGLAIVE FINAL FANTASY XVを観てきました。FFXVメディアミックスのいちコンテンツではありますが、FFをプレイしない人でも十分に楽しめる「ストーリー」「映像クオリティ」でした。9/30が楽しみです。 ということでさっそく行ってみましょう。 AWS公式 1. AWS Black Belt Online Seminar「Parse.comからAWSへのモバイルアプリの移行」の資料公開 2. [OpsJAWS: やってみようシリーズ] Sumologicの検索(CloudTrailのログ解析) AWS関連 Recruit Technologies Open Lab #03 テーマ:Infrastructure as Code 3. Infrastructure as Code のこれ
Kief Morris's book is the core text for more depth on how to use infrastructure-as-code to take advantage of the shift from iron age to cloud age. Infrastructure as code is the approach to defining computing and network infrastructure through source code that can then be treated just like any software system. Such code can be kept in source control to allow auditability and ReproducibleBuilds, sub
In my previous article on the server lifecycle I mentioned ConfigurationDrift. Configuration Drift is the phenomenon where servers in an infrastructure become more and more different from one another as time goes on, due to manual ad-hoc changes and updates, and general entropy. A nice automated server provisioning process as I’ve advocated helps ensure machines are consistent when they are create
私はここ1週間ほど、同僚の David の一言で Infrastructure as Code について頭が大混乱状態でした。 それは次の一言です。 Chef や Puppet は大体の部分は Infrastructure as Code じゃないよね。ARM (Azure Resource Manager) はそうだけど。 ただ、Chef-Provisioning は Infrastructure as Code だよね。 もう頭が大混乱です。なんとなく言わんとしていることはわかりますが、私は今まで Chef とか、Puppet とか、Ansible とかで やっているようなことが、Infrastructure as Code と思い込んでいましたが、何か間違っていたのでしょうか?そういえば、 Chef はConfiguration Management Toolと紹介されていたなとか頭
So you receive this unpleasant notification that a server is unreachable. You follow your usual quick fix routines (for example: flip through the logs to see what has happened), only to find out that the server has actually crashed. You freeze! Immediately, you get flashbacks of the hustle that you had to go through while trying to configure that server. You try to recall every component you had i
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く