株式会社サイバーエージェント AI事業本部 2024年度エンジニア新卒研修 オブザーバビリティ研修実践編(一部社内向けの内容)
株式会社サイバーエージェント AI事業本部 2024年度エンジニア新卒研修 オブザーバビリティ研修実践編(一部社内向けの内容)
システム運用アンチパターン ―エンジニアがDevOpsで解決する組織・自動化・コミュニケーション | Jeffery D. Smith, 田中 裕一 |本 | 通販 | Amazon エンジニアがDevOpsで解決する組織・自動化・コミュニケーション。早速お薦めしたく書いています。読書感想文です。 感想5点 良いぞ。周りに薦めたい 百聞一見。目次だけでも: https://www.oreilly.co.jp/books/9784873119847/#toc 特に自分にとって良かったのは以下 9章 せっかくのインシデントを無駄にする 10章 情報のため込み:ブレントだけが知っている だが、一番スゴイのは11章かもしれない 「文化を変えようと思うのであれば、文化がどのように共有されているかを理解すること」 コロナ以前は 議事録 会議 机横での雑談 飲み会 タバコなどなどあったが コロナ以降、リ
まえがき IT業界で10年弱努めて見て、現在は教育部門にいることもあり”新人教育に向いている教材は有りませんか?”という質問を頂くことがあります。 昨今ITに関する様々な知識は情報が溢れていて、少し検索エンジンで調べれば大量のリソースにすぐアクセスができます。 一方で、本当に価値があるものも大量の情報の中に埋もれてしまいがちです。 本記事が目指すポイントとしては、”これからIT業界でインフラエンジニアとして頑張るぞ”という方向けが、短時間で良質なリソースにアクセス出来るようにすることです。(私自身のおすすめ色が強いです) なお、ここで想定する”インフラ”というのは次の要素を想定しています。 サーバ オペレーティング システム ストレージ ネットワーク 仮想化 パブリッククラウド ですから、次のようなカテゴリについては全く触れていない、あるいは触れていてもかなり部分的だと言う点をご理解下さい
2021/03/16 インフラエンジニア Books #7の資料です。 https://infra-eng-books.connpass.com/event/201291/
こんにちは。 ご機嫌いかがでしょうか。 "No human labor is no human error" が大好きなネクストモード株式会社の吉井 亮です。 日本国内においても多くのシステムがクラウド上で稼働していることと思います。 俊敏性、拡張性、従量課金、IaS、セキュリティなどクラウドのメリットを享受しやすい所謂 SoE で多くの実績があるように感じます。 ここ1~2年は、社内基幹システム・情報システム、SoR 系のシステムのクラウド移行が本格化してきたというのが肌感覚であります。 クラウドでのシステムインフラ構築は従来のようにゼロから非機能要件定義を行っていくものではなく、ベストプラクティスをまず実装して少しずつ微調整を行っていくものと考えています。とはいえ、システムごとの要件は予め明らかにしておくことがインフラ構築においても重要になります。 クラウド上では出来ること出来ないこと
最近GCPから登場したKubernetes YAMLのPackage managerであるKptは「Infrastructure as Data(Configuration as Data)」という考えかたを基礎としてそれを推し進めようとしている.それ以外にもKubernetesのEcosystemには(明示はされていなくても)この考え方が中心にある.Infrastructure as Codeとは何が違うのかなど歴史を振り返りつつまとめてみる. (指針はBorg, Omega, and Kubernetesという論文にあるが「Infrastrcuture as Data(Configuration as Data)」という言葉を明確に定義した文章はない.この記事はReferencesに挙げるいくつかのPodcastにおける@kelseyhightowerの発言や,それに反応する@bgra
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog サイトオペレーション本部の渡邉です。 サイトオペレーション本部はデータセンタ・ネットワーク・サーバー・OS・ストレージといった全社的なインフラの管理運用や調査検証などを担当しています。 今回は、2013年に全社のプライベートクラウドとして導入した OpenStack の監視基盤として、OSS の Sensu と Graphite を採用した事例についてご紹介したいと思います。 採用に至るまで サイトオペレーション本部では、もともと 2011 年から内製のプライベートクラウドを開発運用していました。 プライベートクラウドでは VM のホストとなるハイパーバイザを大量に運用する必要がありますが、その監視基盤として社内で一般的に利用され
フロントエンジニアに知ってもらいたいリバースプロキシの重要性 | RickyNews この記事が目に入って読んでみた。なるほど、昨今は Reverse Proxy は便利な L7 ルーター的なものとして認識されているのだな、と思った。URL の Rewrite や、VirtualHost 云々。確かに Reverse Proxy の便利な側面ではある一方、それらは Nginx などの Reverse Proxy でなければ実装が不可能かと言えばそんなことはないものでもある。 自分は Reverse Proxy はもうすこしサーバー/インフラ的な側面でその役割を捉えている。今更何をというものでもあるが、昼休みがてら時間があるので簡単に書いてみよう。 Reverse Proxy はWebシステム全体のリソース最適化のためのパーツ Reverse Proxy のインフラ的な視点での役割は「Web
Dockerが使えるようになったため、Jenkinsにより仮想サーバの起動から、サーバ構築、テスト、仮想サーバの廃棄までを自動化してみました。 やりたいこと 以下のように、Chefのリポジトリの更新をトリガーに、仮想サーバの起動から、サーバ構築、テスト、仮想サーバの廃棄までをJenkinsにて自動化します。 Chefのレシピをリモートリポジトリへgit pushすると、Jenkinsが通知を検知 JenkinsからDockerの仮想サーバ(コンテナ)を起動 起動が成功すれば、Chefを実行し、サーバを構築 サーバ構築が成功すれば、serverspecを実行し、サーバの状態をテスト テストが成功すれば、Dockerの仮想サーバ(コンテナ)を廃棄 また、Dockerの起動停止、サーバ構築、テストは全てSSH接続により行います。 構成 CentOS 6.5 : Chef、serverspec、J
事前に断っておくがここでいう「インフラ」はレイヤ的には OS より上の話。 少し前に GitHub 時代のデプロイ戦略 - naoyaのはてなダイアリー で、GitHub を介したデプロイを実践しているということを紹介した。普段の開発を Pull Request ベースでやっているので、デプロイもまた Pull Request を契機に実行させると色々捗る、という話。 このプラクティスの対象領域をインフラにまで拡大してみました、というのが今回の話。 DNS レコードを Pull Request を merge した契機に自動で更新 AWS を利用している場合、ドメインの管理も Amazon Route 53 を使うといろいろと都合がいい。 Route 53 での DNS レコードの更新はこれまでブラウザから操作していた。これだと誰がいつ作業したかわからないし履歴もトラックしづらい。また変更
CyberZ 公式エンジニアブログ アドテクや最新のテクノロジーについて情報発信していきます ブログトップ 記事一覧 画像一覧 jsとcssで等身・・・ » 怠惰のすゝめ。Dockerで環境構築・テスト・デプロイを完全自動化 2014-06-02 11:04:38NEW ! テーマ:ブログ こんにちは、2014年新卒エンジニアの進藤です。 CyberZに配属されて1ヶ月経ちましたが、優秀な先輩エンジニアに囲まれ、刺激的な毎日を過ごしています。 さっそくですが、いま僕が進めているプロジェクトについてを説明します。 開発中のプロジェクトに対して、環境構築・テスト・デプロイの自動化を進め、開発のサイクルを早める仕組み・体制を整えています。 さらには運用中のプロジェクトに対して「Immutable Infrastructure」の概念を取り入れ、安全な運用体制についても調査しています。 まだ検証の
Immutable Infrastructureはアプリケーションのアーキテクチャを変えていく、伊藤直也氏(前編) 仮想化やクラウドを基盤とした新しいインフラの考え方である「Immutable Infrastructure」が注目されています。3月25日、このImmutable Infrastructureをテーマに渋谷のDeNAオフィス大会議室で開催された勉強会「Immutable Infrastructure Conference #1」は、150人の定員に400人以上が申し込む人気ぶりでした。 これまでのImmutable Infrastructureに関する議論はおもにデプロイなど運用とインフラ周りの話題が中心でしたが、最初のセッションで登壇した伊藤直也氏は、Immutable Infrastructureが結果的にアプリケーションアーキテクチャにも大きな影響を与えるため、アプリケ
今年の3月に 入門Chef Solo - Infrastructure as Code という本を書いた。 その名の通り Chef の入門書なのだけど、このサブタイトルは "Configuration Management Tool (構成管理ツール)" でもなく "Provisioning Framework (プロビジョニングフレームワーク)" でもなく、はたまた "Automated Infrastructure (自動化されたインフラ)" でもなく、"Infrastructure as Code" にした。 この一年で Chef や Puppet にはずいぶんと注目が集まった。おそらく、AWS をはじめとするクラウドサービスがより広いユーザーに浸透したことで仮想化環境が前提になって、以前よりも頻繁にサーバーを構築し直したりする機会が増えたとかその辺がひとつ理由として挙げられると思う
140文字で書ききれなかったのでブログに殴り書き。 Heroku のアプリケーションを人に渡す 昨日、「naoyaさんが作ってるiOSアプリのバックエンドサーバーに相乗りさせてもらえないか」という話をいただいた。自分でも同じようなAndroidアプリを作っているけど、サーバーサイドは作ってないからということらしい。 対して「githubにコードあるからgit cloneしてheroku pushすれば動くし、自分で heroku にデプロイしてよ」と応えた。相乗りしてもらってもよかったのだけど、こちらでコードを書き換えたりメンテしたときに先方のアプリが停止することを考えると同じコードベースでサーバーは自分で立ててもらう方が何かと良い。 対象になったソフトウェアは Heroku で動かしていたので、Heroku Ready な形、つまり、必要な外部パッケージの一覧やサーバーの起動手順なんかは
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く