「NoOps」の時代がこない理由
印刷する メールで送る テキスト HTML 電子書籍 PDF ダウンロード テキスト 電子書籍 PDF クリップした記事をMyページから読むことができます こんにちは。真壁徹と申します。とあるイベントでインフラ技術者への愛を語ったことがきっかけで、この連載のお話をいただきました。 インフラ技術者はいま、向かい風を受けています。ハードウェアのコモディティ化が進み、設備投資は縮小傾向です。設備が減れば、担当する組織全体の予算も減りがちです。また、パブリッククラウドの浸透が「NoOps」につながる、と主張する人もいます。下を向いてしまいがちな状況です。 ですが、能力や意欲のあるインフラ技術者にとっては、むしろ活躍の場が広がっていると考えています。それをお伝えしたく、この連載オファーを受けました。 わたしは日系システムインテグレーターでのアプリ開発でキャリアをスタートしました。その後、外資系でイン
オープンソースのデータセンター管理ツール『openDCIM』をインストールしてみた | 俺的備忘録 〜なんかいろいろ〜
仕事でデータセンターのラック構成図とか書くのだが、これがまたExcelなのである… この時代、もうちょっと先進的なものが欲しいなぁ、と思ったりするわけで、色々とアンテナを張って見つけたのが、この『openDCIM』だ。 オープンソースのデータセンター管理ツールだとのこと。まさに先ほど書いていた、Excelで書いているラック構成図を無くすために作られたツールらしい。 こちらにデモがある。ID/パスワードは共に『dcim』となっている。 とりえず、ラック構成図の辺りをいじってみた。 【ラック構成図】 ラック構成図を作成し、そのサーバの前面・背面イメージを貼り付ける事で現地でどのようなサーバが入っているのかが分かりやすくなっている。 サーバ筐体をクリックすると、その筐体の詳細情報が編集出来る。ラックは「Cabinet」になる。 【サーバ筐体の詳細】 それぞれの筐体についての詳細。 NICの接続先
Chef脱落者が、Itamaeで快適インフラ生活する話 - Qiita
こんにちは。株式会社ベーシックのCTOやってる@zaruです。今年はじめてQiitaのアドベントカレンダーに参加しました。25日埋まるようなんとか頑張ります。また、ベーシックのエンジニアについて興味のある人はベーシックエンジニアのQiita記事に目を通してみてください。それなりに面白い記事があると思います。 長い前置き Chef、めっちゃ流行って今や定番ツールになってますね。僕はChefに挑戦したものの脱落したダメエンジニアです。なんで脱落したかというと、セコセコ作ったレシピを保守できなかったんですね。Chefさわれる人が社内に全然いない＆教えようにも自分がよく分かっていないという、ツールに振り回されてダメダメという状況になってしまいました。 そこでもういっそ、VagrantBoxを直接配布したり、AWSならAMI化されたものを使いまわしたりしてたわけです。そこまで大規模なインフラでもない
Serverspec - Resource Types
Resource Types bond | bridge | cgroup | command | cron | default_gateway | docker_container | docker_image | file | group | host | iis_app_pool | iis_website | interface | ip6tables | ipfilter | ipnat | iptables | kernel_module | linux_audit_system | linux_kernel_parameter | lxc | mail_alias | mysql_config | package | php_config | port | ppa | process | routing_table | selinux | selinux_module | s
「Serverspec」を使ってサーバー環境を自動テストしよう | さくらのナレッジ
ChefやPuppet、Vagrantといったサーバーの設定を自動で行うツールが普及しつつあるが、それと同時にサーバーの自動テストについても注目されるようになっている。今回はサーバーの自動テストを実現するツール「Serverspec」をLinux環境で利用する手順を紹介する。 サーバーの自動テストの必要性とテスト駆動開発 最近ではサーバーの設定やソフトウェアのインストールといった作業を自動で行えるツールが注目されている。しかし、設定後のテストについてはあまり注目されておらず、各種設定やソフトウェアのインストールが正しく行われているかどうかは手作業で確認することが一般的だった。しかし、手作業での確認にはミスや抜けが発生する可能性があり、また対象とするサーバーの数が増えるとそれに比例して手間も増えてしまう。そこで活用したいのが、サーバーの自動テストツールだ。 サーバーの自動テストツールは、あら
Saltってどうなんだろうと思って試してみた – OpenGroove
Saltは最近出てきたPythonベースの構成管理ツールで、開発元はSaltStack。日本ではまだ無名だが、一部ではアツい？らしい。Ansibleみたいに簡単に使えるものだったらいいんだけど、どうなんだろうと思って試してみた。 おおまかなポイントは以下。 Ansibleと違ってSSHは使わない。必要なポートは4505, 4506。互いの通信にはsalt-keyを使用する。 管理する方がMasterで、クライアント側はMinionと呼ばれる。それぞれデーモンを起動する必要がある。 （ということはクライアントへのMnionインストールがSaltで操作する以前に必要なわけで、ここの自動化をどうするべきか…） 他、Saltには以下のようないくつかの概念がある。この辺りもちょっと、Ansibleに比べるとプラスα学習時間が必要かもしれない。 State (Salt States) Saltにおける
[実践編] MaaSとJujuによるOSS配備、Ubuntu Serverの運用・管理（前編）
今回お届けするUbuntu Server実践編の第2弾では、前編でスケールアウト基盤にOSを簡単にベアメタル配備するためのMaaSサーバーの構築手順を解説します。後編では、OSSのオーケストレーションを実現するJujuを解説します。 MaaSによるOSの自動インストール Ubuntu Serverでは、OSにMaaS（Metal-as-a-Service）と呼ばれるベアメタル配備の機能があります。MaaSは、Ubuntu Serverを物理サーバー上に配備する役割を担っていますが、後述のJujuと組み合わせることにより、複数のOSSが連携したUbuntu Serverのシステムを構築することが可能となります。 JujuによるOSSのオーケストレーションを物理サーバーベースのクラウド環境を実現するためには、MaaSが必須となります。物理サーバーベースのスケールアウト型のNAS環境やHadoo
![[実践編] MaaSとJujuによるOSS配備、Ubuntu Serverの運用・管理（前編）](https://cdn-ak-scissors.b.st-hatena.com/image/square/7854e51b5f846d773583bce6363e0c00636f5d30/height=288;version=1;width=512/https%3A%2F%2Fthinkit.co.jp%2Fsites%2Fdefault%2Ffiles%2Fmain_images%2F4697_main_5_8.png)
今年流行りそうな「インフラエンジニア」向けトレンドのまとめ その1 (Blue-Green DeploymentとImmutable Infrastructure編)
あけましておめでとうございます。バズワード評論家 横田でございます。(恐らく)皆様1月6日から出社ですね。お仕事がんばりましょう。 というわけで今年のインフラ業界のバズワードトレンドをまとめてみました。年始の仕事前にどうぞ 《Blue-Green DeploymentとImmutable Infrastructure》今年のインフラ業界の一番のトレンドは「Blue-Green Deployment」と「Immutable Infrastructure」となる気がしています。今までは、サーバの設定を変更する時は、運用中のサーバを変更していましたが、「Blue-Green Deployment」と「Immutable Infrastructure」の考え方は、運用中のサーバの変更するのではなく、新しくサーバ群を用意し、本番環境をそちらに切り替えるという手法を取っております。 手法自体は「Blu
いかにしてベンチャーの社内ネットワークを構築するか - UNIX的なアレ
情シス担当者なんていない 現在、nanapiは社員数30名弱くらいの会社規模です。アルバイトさんを含めると70名くらいになりますが、そのうちエンジニアは私を含めて8名。このくらいの会社の規模だと、まだ情シス的な仕事を専門的にやるような人はいません。 当然、ネットワークの専門家もまだ弊社にはいないので必然的にエンジニアの誰かがこのあたりを担当することになります。ベンチャーにおいてだいたいの場合、こういった技術的な行き場の分からない仕事ってのはCTOがやるもんです。 しかし、情シス的な仕事って本当に難儀な仕事。動いてて当たり前、高速で当たり前、ちょっとでもネットワークが遅くなるものならその時点ですでに障害です。 外注するという選択肢もありますが、何かしら社内でネットワークのトラブルがあれば少なくともその瞬間はたぶん僕が対応するなり調査するなりすることになります。どうせそうなるのであれば、自分で
さらば自社サーバールーム！pixiv、白河データセンターに移る (1/2)
900万を超えるユーザー数を抱え、日本を代表するイラスト投稿SNSに育った「pixiv（ピクシブ）」。長らくサービスを社屋の自作サーバーとIDCフロンティアの新宿データセンターで運用していたpixivのインフラを、新たに白河データセンターにまで拡げた背景をピクシブの方々に聞いた。 開始1週間後にサーバーを落とす イラスト投稿に特化したユニークなSNSであるpixivは、イラスト好きなプログラマーである上谷隆宏氏の思いから生まれた。ピクシブ 代表取締役社長の片桐孝憲氏は、「上谷が、イラストを描いている人同士が気軽に交流できるSNSとギャラリーを混ぜたようなサービスを作りたいと話していた。正直、特定のユーザーに特化したSNSでうまくいっている事例を知らなかったので、特定の分野に限定したものはあまり受けないと思っていたが、pixivという名前はカッコイイと思った（笑）」と振り返る。 こうして生ま
仮想化前提のシステムで失敗するインフラ作りの問題点
仮想化前提のシステムで失敗するインフラ作りの問題点：クラウドファースト時代の運用ベストプラクティス（1/2 ページ） 仮想化を前提にしたシステムの構築や運用が広がりつつあるが、インフラ全体の視点ではどのような点に注意すべきだろうか。前回に引き続き、日本仮想化技術の宮原徹氏に話を聞いた。 前回は仮想化環境を中心に運用面で考慮すべきポイントを、日本仮想化技術の宮原徹代表取締役社長兼CEOに聞いた。今回はインフラ全体の視点から現状の課題と解決へのアプローチについて、引き続き宮原氏に聞く。 クラウドへの過剰な期待と積み残し 仮想化と並んでITインフラでの導入・利用が広がるパブリッククラウドも、仮想化と同様に事前の期待と現実とのギャップからさまざまな課題が表面化している。例えば、外部のクラウドを利用すれば自社資産を抱える必要がなくなり、大幅なコスト削減を実現できるという期待があった。実際にコスト削減
インフラストラクチャ自動化フレームワーク「Chef」の基本
DevOpsというキーワードに関連して、「Chef」というツールの名前を聞いたことのある人も多いのではないでしょうか。この記事では、インフラにおける構成管理、展開作業を自動化するChefの構造および基本的な使い方について解説します。 インフラストラクチャ自動化フレームワーク「Chef」 Chefは、物理、仮想、クラウドといったさまざまな大きさのインフラに対して、サーバやアプリケーションの展開を容易にするための自動化フレームワークです。 Chefの重要な要素の1つに「Infrastructure as Code」という概念があります。インフラをどのように構築し、維持するべきかという定義はRubyの文法で記述され、ソースコードのように扱うことができます。つまり、あたかもRubyでプログラミングをするように、インフラの構成管理をコードによって行えることがChefの利点の1つです。 自然言語による
インフラ系技術の流れ - Gosuke Miyashita
ここ最近のインフラ系技術の流れがおもしろいなー、と思ったので、Puppet が出た辺りぐらいから、振り返って整理してみる。殴り書きなので、後から修正したり書き加えたりするかも。特に後半の方は、あまり考えが整理できてない。 最近のウェブ界隈での「インフラ」という用語の使われ方には、色々異論もあるようだけど、ここではごく最近使われるようになってきた、OS からミドルウェアといったソフトウェアレイヤーを指す言葉としてのインフラについて触れる。（英語圏でも同様の意味で使われているようなので、ある程度市民権を得たと言っても良さそうだし。） プロビジョニングレイヤー まず、前提知識としてプロビジョニングレイヤーと自分が勝手に呼んでるものについて整理。 Chef や Puppet は「プロビジョニングフレームワーク」とも呼ばれているが、以下の議論をより厳密にするために、Lee Thompson 氏による
ITインフラで起きる「もしも」のための12個のコマンド
こんにちは。斎藤です。 ITインフラの障害は、多くの場合「予期せぬ」タイミングで発生します。特に、CPUリソースを多量に消費したり、Disk I/Oが輻輳している場合、その切り分けは困難な状況に陥りやすいものです。 そこで、本日はITインフラ、特にOS・ミドルウェアを支えるにあたって、問題解決を助けてくれるであろう12個のコマンドを取り上げてみます。「必ず押さえておきたい」5つのものと「更に覚えると便利なコマンド」7つの2節に分けてお話しします。 ※CentOS 6.4 (64bit)を前提に取り上げます 必ず押さえておきたいコマンド もしITインフラ管理者になりたてな方はぜひ サーバサイドのプログラマをやっていたのだけれど、ある日突然「君、サーバ管理担当ね！」と、バトンを渡される方っていらっしゃると思います。私も以前はそのクチでした...。そうなってしまったとき、まずは覚えておきたい5つ
DMM inside
日本アニメ初の快挙！海外アニメ賞を受賞した『スキップとローファー』海外ライセンス部長&プロデューサーが語る、奮闘の舞台裏
サーバ用途でコンシューマ SSD へ調子に乗って書き込みすぎると壊れるという話 - mura日記 (halfrack)
Crucial M500 の write endurance が 75TB しか無いというのが話題になっていて、同じく 75TB である m4 をわざと虐待していたホストはどうなったのか気になって調べて見たところ、面白い結果が観測されたという話。 石橋を叩いて壊し障害時の挙動を見るべく「自社全サービスのアクセスログを受け止める syslog サーバ」という、どう見ても書き込み中心で SSD にやさしくないホストをあえて動かしていた。具体的には下記のようなノリのホストである。 iostat の一行目なので uptime 数百日における平均値であることに注意。 [root@touge ~]# iostat -k -x -d sda | sed -n '3,4p' Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await
mixiのサーバOS移行のお話 - mixi Engineers' Blog
はじめまして、運用部アプリ運用グループの清水 勲です。 2011年8月に入社して以来、はじめてエンジニアブログを書きます。 運用部では、日々、mixiを支えるサーバやネットワークを管理、運用しています。 今回は、サーバで使用しているOSの移行について、何回かにわたって紹介したいと思います。 はじめに 突然ですが、mixiで採用しているサーバのOSはなにかご存知でしょうか？ 過去のブログ記事でもあまり紹介していなかったと思います。 はるか前のことなので詳しくは知りませんが、2006年の社外イベントで、弊社からの発表者と質問者との間で、以下のようなやりとりがあったようです。 参加者からの質問 Fedoraを利用している理由は？ 弊社発表者Bさんの回答 他のOSだとNICを認識してくれなかった。Fedoraなら一発でいけたから。 ということで、mixiでは何年も前からFedoraを採用してき
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Itamae - Infra as Code 現状確認会
「クラウド本気で始めました」なSIerのChef活用と実践～Chefアンチパターンとの戦い～
NameBright - Domain Expired