A method for separating policy definition and behavior control by an intermediate language to achieve optimal server configuration management according to the situation
ちょっと、簡単に答えられなかったので、休み中にまとめました。 「どこまで勉強すれば良いか？」 という質問には、 自分の立ち位置や、今後の目標など関わるので、 それらを踏まえて考える必要があると思います。 職種によっても違いますが、質問された時の状況は、 Web系エンジニアが新卒の子に聞かれた形なので、 考慮いただきたいです。 また、そもそも、どんな背景をもったやつが書いてるんだ？と思う方も いらっしゃるかと思いましたので、簡単に自己紹介してから書きます。 書いている人の自己紹介 現在33歳で、エンジニアスタートしたのが、 2005年08月だったので、エンジニア歴は11年となります。 ほとんどの現場がデスマーチ状態だったので、2ヶ月くらい前に転職して、 現在はホワイトな会社のリクルート住まいカンパニーで、PHPを書いています。 言語歴としては、最初にJP1スクリプトを１年半くらいやって、次に
みなさんこんにちは。@ryuzeeです。 これから新たにChefを学ぶ人向けに非常に基本的なトレーニングの資料を作ったので公開します。 資料の構成は以下のとおりです。 まずDevOpsの文脈から自動化が必要な背景を説明Infrastructure as Codeについての利点を説明ChefのアーキテクチャChefの用語解説Vagrantで仮想マシンを2台使った一番単純なハンズオン(boxも用意済み)Serverspecを使ったCookbookのテストの書き方(VirtualBoxの仮想マシンの中でDockerを使っています)その他なお、2-3時間でさくっと触りながら全体像を掴むことを目的にしているので、網羅性はありません。 ハンズオン用のVagrantのboxには、あらかじめ、Chef DK(Development Kit)、Dockerなどが含まれており、すぐに触れると思います(ただしb
近年Webアプリが増え、サーバの環境構築を行ったり、アプリのデプロイを行ったりする機会が増えてきました。しかし、いまだにこのようなサーバ作業をマニュアル頼りに手作業で行っていることもあるかと思います。環境構築やデプロイなどを何度も行う場合は自動化したいところです。 サーバ作業を自動化しようと考えたとき、最初に思い浮かぶのはシェルスクリプトを利用することではないでしょうか。シェルスクリプトを使って環境構築やリリースを自動化することは可能ですが、シェルスクリプトだけだと手間が掛かってしまう作業もあります。 例えば、リリースを行う環境が複数ある場合、scpでビルド成果物を送り、sshで接続してリリース用スクリプトを実行する、といった作業が環境ごとに必要になってしまいます。 また、ファイルの追記や修正などを行うシェルスクリプトが途中で失敗してしまった場合、シェルスクリプトを修正した後にそのまま再実
RedHat系におけるRPMパッケージを扱うYUM、Debian系におけるDEBパッケージを扱うAPT、これらはサーバー管理において重要なわけですが、絶妙な度合いで、おざなりに扱ってもわりとなんとか運用出来てしまう感があります。そのため今一度、こんな感じが今風のスタンダードじゃないっすかね（ｷﾘｯ という構成を説明してみます。 ぶっちゃけ、たいしたことないネタの集合体なので、タイトルに下駄を履かせました。 そもそもパッケージは必要なのか 言うまでもなく必須です。理由は、インストール物のファイル管理が容易になるのと、インストール時間を短縮できるからです。既存のパッケージでconfigureオプションが物足りない時や、RPMパッケージが存在しない場合は作成することになります。 最近はプロビジョニング・ツールによって全て自動化できるので、超簡素なコンパイルのものはレシピに落とし込んで終わりにした
この文章は、サーバサイドのウェブアプリケーション開発において、社内実績の少ない新しい言語を採用したときにインフラ面で考慮したことを社内向けにまとめたものです。 はてなでは、長らくPerlでウェブアプリケーション開発を続けてきた一方、ここ数年で社内でScalaまたはGoの採用事例も増えてきました。 今後開発が始まるプロダクトにおいても、Perl、Scala、Goもしくは他の言語を採用するかどうかを開発開始時に選ぶことになるでしょう。 新言語を採用するときに、考慮すべきことの一つとして、「インフラ」への影響があります。 新言語に関する雑談をしていると、ウェブアプリケーションエンジニアに「インフラ」への影響について聞かれます。 もしくは、ウェブオペレーションエンジニアから考慮するポイントを伝えることもあります。 ScalaやGo以外に、Node.jsやサーバサイドSwiftはどうかというのも雑談
dots. Conference Spring 2016 ゲーム開発の裏側 http://eventdots.jp/event/580344
2. ディープラーニング（DL：DeepLearning）とは l 層が深く、幅も広いニューラルネットワークを利利⽤用した 機械学習⼿手法 l 2012年年の⼤大ブレーク以来、研究コミュニティのみならず 産業界に多く使われてきた – 2014〜～2015年年中に出された関連論論⽂文数は1500を超える* l 画像認識識、⾳音声認識識などで劇的な精度度向上を果たし、その 多くが既に実⽤用化されている 2 2014年の一般画像認識コンテストで優勝した 22層からなるNNの例 [Google] *http://memkite.com/deep-‐‑‒learning-‐‑‒bibliography/ 2015年の一般画像認識コンテストで優勝した 152層からなるNNの例 [MSRA] 3. なぜ機械学習が実世界で使えるようになったのか l Internet of Thing
前編（「ビッグデータは“リアルタイム”でこそ価値がある」）では、リアルタイムなビッグデータ解析プロジェクト「CET（Capture EveryThing）」が始まったきっかけから、いまのチームまで組織に焦点を当てました。 後編では、いよいよビッグデータ解析のシステムについて深掘りしていきます。 Amazonのクラウドサービスを活用して作り上げた現状のシステムを捨て、Googleで作る構成に変えようとしているそう。その意図とは。 クラウドサービスのコストパフォーマンスなど、エンジニアやアーキテクトには気になる情報が満載です。 「CET」で基盤構築や分析・集計アプリケーションの開発を行っている、吉田啓二さんに聞きました。 聞き手／構成／編集／写真：小川楓太（NEWPEACE Inc.） AWSで本格的に運用するのは厳しいかなという印象です —— 今回構築された基盤の具体的なシステム構成はどのよ
運用をイージーにする オブザーバビリティ 誰にも馴染む操作性のUIで、監視を育てるプラットフォーム。 未知の問題に立ち向かう力を開発者に。
中〜大規模サービスのインフラの様子を知りたいアプリケーションエンジニア向けに、もともとアプリケーションコードを書いていた視点から、個人的な体験をベースにはてなで大規模サービスのインフラを学んだ過程や学んだ内容の一部を紹介します。 Webアプリケーションのブラックボックス Webアプリケーションフレームワークの向こう側 なぜ複数のサーバが必要なのか 突然のWebサービス3層構成 リバースプロキシ アプリケーション データベース その他のコンポーネント キャッシュは麻薬 飛び道具としてのKVS/NoSQL 非同期処理 バッチ処理 Mackerelの場合 参考 まとめ Webアプリケーションのブラックボックス 今年もはてなインターンの時期が近づいてきた。 毎年ではないけど、はてなインターンでは「インフラ講義」というのをやっている。 今年はインフラ講義の講師としてアサインされたのでちょうど何を話そ
こんにちは、テコラス株式会社技術研究所の伊勢です。この度、テコラス：：データホテルテックブログが開設されたようでして、「最初のエントリは最年長技術者が書くべきじゃねーか？」というデジコアディレクター松本氏からの脅迫に近いお達しにより、一発目のエントリを書くことになりました。とはいえ、最近あまり仕事もしておりませんし、旬な技術や実装ネタも無いため、どーしよーっかなー？と考えていましたら、技術評論社Software Design誌編集長の(心やさしい）池本さんから、過去に寄稿した記事を転載してもイイヨ！というありがたいお言葉を頂きましたので、それを元に書きたいと思います。 本エントリは昨年12月4日に技術評論社から発売されたSoftware Design別冊シリーズ「インフラエンジニア教本」に寄稿させて頂いた「インフラエンジニア鬼十訓」を転載したものです。この鬼十訓は私の経験知見だけではなく、
1. The document discusses knowledge representation and deep learning techniques for knowledge graphs, including embedding models like TransE, TransH, and neural network models. 2. It provides an overview of methods for tasks like link prediction, question answering, and language modeling using recurrent neural networks and memory networks. 3. The document references several papers on knowledge gra
インフラ部の荒井（@ryot_a_rai）です。この記事ではクックパッドで利用しているプロビジョニングツール "Itamae" の紹介と細々した Tips を紹介します。 式年遷宮とプロビジョニングツール 現在、弊社ではインフラの式年遷宮*1を進めています。式年遷宮以前、弊社では Puppet を利用してサーバをセットアップしていましたが、式年遷宮に際して既存のプロビジョニングに関するコードは捨てることになるため、プロビジョニングツールの再検討を行うことになりました。 Puppet, Chef, Ansible, SaltStack を検討した結果、 言語特性の観点では、Ruby DSL な Chef が良い アーキテクチャ・エコシステムの観点では、シンプルな Ansible が良い といった点から、どれも決め手に欠ける状況で、Ruby DSL で記述できるシンプルなプロビジョニングツール
一部のサブシステムの構築で、プロビジョニングツールを捨ててみた。じゃあどうするのかというとシェルスクリプトでやる。今回はこのやりかたが一番楽できるような気がしたので試している。 具体的にはPackerからシェルスクリプトとServerspecを実行してAMIを煮込む。おいしくできあがったらそいつから構築。もしミドルウェアより下の層のコンフィグ類に変更があったらまた煮込む。構築する。新しい方に切り替える。つまり”捨てるインフラ”にする。 プラットフォームはAWS。 (追記)ちなみにchefなどのプロビジョニングツールがめんどくさいからシェルスクリプトにしたというよりは、捨てる前提のサーバだからシェルスクリプトでの構築も選択肢として出てきたということです。ただ自分個人の嗜好としてchefはもう飽きたというのも事実です。なお、オンプレだと同じサーバで継続してプロビジョニングすることになるのでch
雑誌の概要はこちら => WEB+DB PRESS Vol.85｜技術評論社 。 写真はオープンセミナー広島2015での発表から 共著のみなさんも既にブログで紹介されています、各章の対象読者や雑誌のオススメ具合はこちらがとても参考になります。 @sgwr_dts(winebarrel) さんの記事 => AWS as Code!: WEB+DB PRESS Vol.85に記事を書きました - so what @muramasa64 さんの記事 => WEB+DB PRESS vol.85にCloudFormationの記事を書いた - 雑記帳(2015-02-23) @y15i(y13i) さんの記事 => t.y13i.com — WEB+DB PRESS Vol.85にCloudFormationの記事を書きました 特集を簡単に紹介すると、 導入しやすく、まあまあ普及感のあるCloud
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
