【資料公開】Chef ベーシックトレーニング
みなさんこんにちは。@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
ウェブアプリケーション開発に新言語を採用したときにインフラで考えたこと - ゆううきブログ
この文章は、サーバサイドのウェブアプリケーション開発において、社内実績の少ない新しい言語を採用したときにインフラ面で考慮したことを社内向けにまとめたものです。 はてなでは、長らくPerlでウェブアプリケーション開発を続けてきた一方、ここ数年で社内でScalaまたはGoの採用事例も増えてきました。 今後開発が始まるプロダクトにおいても、Perl、Scala、Goもしくは他の言語を採用するかどうかを開発開始時に選ぶことになるでしょう。 新言語を採用するときに、考慮すべきことの一つとして、「インフラ」への影響があります。 新言語に関する雑談をしていると、ウェブアプリケーションエンジニアに「インフラ」への影響について聞かれます。 もしくは、ウェブオペレーションエンジニアから考慮するポイントを伝えることもあります。 ScalaやGo以外に、Node.jsやサーバサイドSwiftはどうかというのも雑談
ビッグデータツールチェインのセキュリティはビッグリスク、あるいは、誰もHadoopをスクラッチからビルドする方法を知らない件について
ビッグデータツールチェインのセキュリティはビッグリスク、あるいは、誰もHadoopをスクラッチからビルドする方法を知らない件について The sad state of sysadmin in the age of containers コンテナー時代のシステム管理者の惨状 システム管理は惨劇に見舞われている。現状は悲惨だ。 筆者は昔気質のシステム管理者に不満はない。システムの稼働を維持し、アップデートし、アップグレードする方法を知っている者達だ。 この憤りは、コンテナーと構築済みVMと、それらがもたらす、「信頼」や「アップグレード」の欠如による悲惨な惨劇に対するものだ。 例えば、Hadoopを見てみろ。誰もHadoopをスクラッチからビルドする方法を知っているようには見えないぞ。依存性とバージョンとビルドツールが悲惨なほどに絡まりあっている。 この手のイケてるツールの中で、古典的なmake
Consul は 全自動オーケストレーションの 夢を見るか?
＠ペパボテックカンファレンス http://pepabo.connpass.com/event/13208/Read less
コードによるインフラ構成管理はなぜ必要？ 今さら聞けない「Infrastructure as Code」
はじめに 本連載では、インフラの構成をコードで管理するための便利なツールを使って、インフラを構築するための手順をご紹介します。今回は、Vagrantというツールを使って、ローカルマシンに仮想環境でWebアプリケーションの開発環境を作って、開発チーム内で統一した開発環境を構築する方法について説明します。 対象読者 本記事は、次の方を対象にしています。 コードを使ってインフラの構成管理をしたい人 ネットワークやLinuxの基礎知識がある人 Webシステムの開発環境を構築したことがある人 なぜ、コードでインフラの構成管理をするの？ 業務アプリケーション開発者のみなさんは、前任者が作った既存システムにバグがあり、それを修正することき、「設計書の内容と、ソースコードの中身が違う！？！」というシーンに出くわすことはありませんか？ Excelの設計書とソースコードを交互ににらめっこしながら、関係者に仕様
スタートアップ企業向けインフラ運用入門（2）：ログ・メトリクスの収集
システム・サービスに関するログ・各種情報を取得する事により、トラブルシューティング、パフォーマンスチューニングのみならず、ビジネス上の成果の確認、UIの改善等にも役立ちます。ただ、闇雲に情報を取得しても、効果は上がらず労力ばかりがかかってしまいます。本記事ではログ・メトリクスの収集の目的を明らかにし、その為に必要な点を実例を挙げながら説明していきます。 「ログ」取得の目的 Retty開発担当の鹿島です。Webサービスに限らず、ITのシステムを運用していれば、何らかの形で「ログ」の取得・保存をしている事かと思います。そもそも、それらは何のために保存されているのでしょうか。まずは、「ログ」を保存する目的を明らかにし、その観点から各種の「ログ」について見ていきたいと思います。 開発や運用経験のある方であれば、 「ログにxxxに関する情報が出ていれば、障害解決がスムーズなのに......」 とか、
新しいクラウドパフォーマンス管理サービス Mackerel 正式リリースのお知らせ - Mackerel お知らせ #mackerelio
本日、Mackerelを正式リリースしました。 Mackerelは、Immutable Infrastructureを取り入れたアーキテクチャや、ChatOpsといった運用スタイルに最適化した、新しいクラウドパフォーマンス管理サービスです。 Mackerelは2014年5月8日にベータ公開し、それから4ヶ月間、機能追加と安定化を目指してきました。今後も引き続き、クラウド上のサーバとそれらによって構築されるWebサービスを管理するための、より使いやすく、より便利なサービスとして開発運用を加速させていきます。並行して国際化対応し、グローバルへの展開も積極的に行います。 本日より、フル機能をご利用いただける「Standardプラン30日間無料！」キャンペーンを実施しております。ぜひお試しください。 ご意見ご要望などがありましたら、お気軽にサポートまでお知らせください。 Mackerelの特徴 M
Terraform by HashiCorp
Deliver infrastructure as codeTerraform codifies cloud APIs into declarative configuration files. AdoptCompose infrastructure as code in a Terraform file using HCL to provision resources from any infrastructure provider. BuildInfrastructure automation workflows to compose, collaborate, reuse, and provision infrastructure as code across IT operations and teams of developers. StandardizeEstablish gu
HashiCorp Blog: Terraform
Sign up for freeGet started in minutes with our cloud products TerraformInfrastructure as code provisioning
大規模にchefを使い倒すためのcookbook pattern - Qiita
概要 チームや組織、プロダクトをまたいでcookbookを使っていく場合に使えるcookbookの書き分け方を紹介します。 要はプロダクト毎にサーバに対する要求は変わりうるのでサービス毎にcookbookを分けるんだけど、会社全体として組織プロダクトをまたいで共通化しておきたい部分は共通のcookbookを使いましょうという話です。 こういう分け方をしたらよい、という話もします。 組織やプロダクトの成長とcookbook 小さな組織やチーム内でchefを導入した場合、cookbookを書くのは大抵の場合一人だと思います。 扱うサーバの種類もそんなに多くないので、apacheのインストールやphpの設定を一つのrecipeにベタ書きしても人間が管理できるボリュームに収まると思います。 というか、変に分割するよりもベタ書きのほうがrecipeの見通しがいいと思います。 ところが、組織が大きくな
Enterprise Container Platform | Docker
Products Docker DesktopContainerize your applicationsDocker HubDiscover and share container imagesDocker ScoutSimplify the software supply chainDocker Build CloudSpeed up your image buildsTestcontainers Desktop Local testing with real dependenciesTestcontainers Cloud Test without limits in the cloud See our product roadmapMORE resources for developers
Mackerelをベータ公開しました - Mackerel お知らせ #mackerelio
本日、Mackerelをベータ公開しました。 Mackerelは、ウェブアプリケーションのパフォーマンスとインフラを管理するための新しいサービスです。 Mackerelとは Mackerelは、次のような問題を解決することを目指しています。 複数のサーバのリソース状況を効率的に可視化 各種ツールと連携することでサーバ情報の多重管理を解消 複数のクラウド環境を一元管理 リソース消費状況を可視化するだけではなく、APIによる各種ツールとの連携で、開発と運用の自動化をより促進させていきます。 詳細は、下記のリンクからどうぞ。 利用開始 https://mackerel.io/ja/ ヘルプページ https://mackerel.io/ja/docs/ 正式化に向けて ベータ期間中は、すべての機能を無料でご利用いただけます。正式版では無料でご利用いただける範囲に制限がつきます（料金などの詳細は正
Dockerとは何か？どこで使うべきか？
この記事はDockerに関する実験的な記事や，Buildpackを使ってHeroku AppをDocker Containerとして使えるようにする“building”の開発などで知られるCenturyLink Labsの “What is Docker and When To Use It”の翻訳です． Dockerとは何か？Dockerをどこで使うべきか？についてよく見かける記事とは違った視点から説明されています． 翻訳は許可をとった上で行っています． Dockerとは何でないか Dockerとは何かを説明する前に，Dockerは何でないかについて述べる．Dockerの否定形は何か？Dockerの制限は何か？Dockerが得意でないことは何か？ DockerはLXCのようなLinux Containerではない DockerはLXCだけのラッパーではない（理論的には仮想マシンも管理でき
Dockerのネットワーク管理とnetnsの関係 - めもめも
RHEL7RC+EPEL版Dockerの前提で解説します。RHEL7RCを最小構成で入れて、次の手順でDockerを導入します。 # yum -y install bridge-utils net-tools # yum -y install http://download.fedoraproject.org/pub/epel/beta/7/x86_64/epel-release-7-0.1.noarch.rpm # yum -y install docker-io # systemctl enable docker.serviceDockerが設定するiptablesの内容を見るために（見やすくするために）、firewalldを停止した上でdockerサービスを起動します。 # systemctl stop firewalld.service # systemctl mask firew
Dockerコンテナ管理ツールGearDを試してみた | DevelopersIO
ども、大瀧です。 Dockerコンテナをデプロイするツールが欲しいという理由でAWS OpsWorksとの組み合わせを以前のエントリーで紹介しましたが、今回は別のアプローチでデプロイを行うGearDを試してみました。 GearDとは GearDは、Red Hat社が開発するDockerコンテナを管理するCLIツール兼エージェントです。 最近、ITニュースサイトのPublickeyで紹介された、Project Atomicのコンポーネントの1つです。Project Atomic自体はRHELベースの軽量Linuxディストリビューション(Atomic Host)を前提とするものですが、GearDは独立した造りになっており、Fedora 20およびRHEL 7-Beta(EPEL経由なのでサポートなし)で動作します。 ブログ記事 : GearD: The Intersection of PaaS
ヌーラボのインフラ運用最前線 〜イミュータブルを目指して〜 (前編) | 株式会社ヌーラボ(Nulab inc.)
このエントリは前後編に分かれています。前編は主に運用フローやそこでの工夫点、後編は実際の運用から得た知見や今後の課題といった内容です。 ヌーラボのインフラ運用最前線 〜イミュータブルを目指して〜 (前編) ヌーラボのインフラ運用最前線 〜イミュータブルを目指して〜 (後編) 最近はインフラ運用・DevOPS関連のトピックとして目にしないことはないくらい、「イミュータブルインフラストラクチャー」について様々な議論がなされています。私たちも昨年、継続的デリバリという文脈で、@IT の連載にてその基本的な考え方について紹介させていただきました。 さて、今年の二月にローンチをしたばかりのヌーラボのシングルサインオンサービス「ヌーラボアカウント」では、イミュータブルインフラストラクチャの一歩手前として、特定の変更を加える場合のみ、ごっそり環境ごと入れ替えるというやり方にてその運用をスタートしました。
Docker 使ってたらサーバがゴミ捨て場みたいになってた話 #immutableinfra - ゆううきブログ
Immutable Infrastructure Conference #1 : ATND でLTしてきた。 内容はきれいにゴミを捨てましょうという話以上のものは特にない。 背景の説明が少し雑だったので補足すると、Jenkins のジョブスクリプトで、git push する度に docker run していたら ゴミがどんどんたまっていったという感じ。 1 push あたり、アプリコンテナ、DBコンテナとか合わせて3コンテナぐらい起動してるから開発が活発だと、どんどんゴミがたまる。 さらに補足すると、Device mapper がらみのゴミは、aufs 使うとかなり解決できそうな感じはしてる。 (Device mapper だとブロックデバイスレベルでイメージ差分を表現するので、デバイス毎(差分)毎に mount が走るみたいな実装になってるけど、aufs だとファイルシステム単位で複数の
Immutable Infrastructureが開発プロセスに与える影響(仮) #immutableinfra
フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ある若手インフラエンジニアの現状確認 #wakateinfra
Serf という Orchestration ツール #immutableinfra
