ITILに関する前回のエントリーでは、サービス運用や管理の事例集としての概要に触れました。今回は、ITILの中でも中心的なプロセスである「構成管理（サービス資産管理）」を見てみましょう。構成管理を導入することで、ITサービスを効果的・安定的に提供するのに必要なさまざまなリソースを、最新の状態に保つことができます。それが、結果としてシステム運用を楽にしてくれます。 サービス運用や管理の事例集 ITILについて知ろう：ITILの基本（1） https://un4navi.com/management/19007/ 各ITリソースは、構成アイテム（CI）として管理 構成管理の対象となるリソースの例は、以下の通りです。これらは「構成アイテム（CI : Configuration Item）」と呼ばれます。ハードウェアやネットワーク、PCなどの物理資産と、ソフトウェアや接続構成などの論理資産がありま
This is a quick set of guidelines for making the best use of Subversion in your day-to-day software development work. Use a sane repository layout There are many ways to lay out your repository. Because branches and tags are ordinary directories, you'll need to account for them in your repository structure. The Subversion project officially recommends the idea of a "project root", which represents
近年、ChefやPuppetなどの構成管理ツールが人気だが、新たに注目されつつある構成管理ツールとして「Ansible」がある。Ansibleは設定ファイルがシンプルで、管理対象サーバーに特別なソフトウェアをインストールすることなく利用できるなど、最小限の手間で各種設定を自動化できるのが特徴だ。今回はこのAnsibleについてその基本的な使い方を紹介する。 小規模な環境でも手軽に使えるAnsible あらかじめ用意しておいた設定ファイルに従って、ソフトウェアのインストールや設定ファイルの修正、サービスの起動/停止、ネットワーク設定といったサーバーの各種設定を自動的に実行するソフトウェアを構成管理ツールと呼ぶ。代表的なものとしては、さくらのナレッジでも過去に取り上げているChefやPuppetがある。 関連記事： サーバー設定ツール「Chef」応用編：knife-soloとData Bagを
みなさん、Git使ってますか？僕はまだメインのVCSがSubversionなのもあって、なかなか慣れません。せっかくGitを使っているのに、ちょっと不便なSubversionくらいの位置づけです。でも、同じような理解度の人って多いんじゃないでしょうか。 一方で、最近はGitHub管理のオープンソースプロジェクトが増えてきました。バグレポートを送るにしてもpull request*1が前提のような空気があり、Git初心者には少し敷居が高い印象があります。 そんな僕も先日初pull requestをしてみたんですが、色々な失敗の積み重ねで残念なpull requestになってしまいました。その反省を元に、本稿ではpull requestする際のベストプラクティスを紹介します。これは「Git Workflow」をベースにコマンド例などを加筆したものです。 概要 pull requestする際は、
目次 はじめに Git を使ったことがない方へ 生のデータが見たい方へ Git の全体像 .git の中身 Git オブジェクトデータベース 4種類のオブジェクト リファレンス リファレンスのリファレンス 大きなツリー Git オブジェクトの ID と 中身 ハッシュ関数 SHA1 の簡単な説明 tree と blob オブジェクト tree と blob の参照関係 ルートツリーの ID でツリー全体を識別する commit オブジェクト リファレンスとブランチ ブランチ ブランチ先頭を指すリファレンス HEAD リファレンス detached HEAD 2種類のタグ 一時待避 (stash) インデックス キャッシュとしての役割 マージ Fast-Forward マージ non Fast-Forward マージ rebase reset 2種類のブランチ 各リポジトリが自分のブランチを
「絶えまない変化に対応していくためにこそ、Puppetのようなフレームワークが必要とされるのです。」サーバ構成管理自動化ツールPuppetについてその基本から複数台マシンの管理まで紹介する、手を動かしながら学べる実践的入門書 内容紹介クラウドが一般的になってきた昨今、サーバ構成管理の自動化は、もはやそれなしでは考えられないほど当たり前のものになっています。Puppetは、そのためのフレームワークのひとつです。 Puppetは2005年のリリース以来、後発のChefとともに、サーバ構成管理の自動化に欠かせないフレームワークとして広く利用されてきました。とはいえ、ドキュメントが非常に充実してはいるもののその機能は膨大で、初心者にとって決してとっつきやすいものでないことは確かでしょう。現に、筆者の周りでも「Puppetを学習してみたいけど、どこから手をつけたらいいのか……」という声をよくききます
KoshiNukeはGitを企業内で用いる際に使えるアプリケーションライフサイクルマネジメントシステムのモックアップです。 Gitが徐々に企業でも利用されるようになっている中、Gitをベースにしたアプリケーションライフサイクルマネジメントが求められるようになっています。そこでモックアップとして紹介したいのがKoshiNukeです。 コードをダウンロードした場合の表示です。 デモ阪の画面です。格好いいです。 リポジトリの履歴です。 コードツリーも表示できます。 コミットログです。個々のコミットログ詳細は見られませんでした。 ブランチグラフです。GitHubと違って縦に進んでいきます。 Wikiは編集機能が備わっています。 Wikiの編集履歴です。 KoshiNukeはあくまでもモックアップなのでビューのみですが、それでも十分に便利そうな機能がそろっているのが分かります。後はバックエンドをRE
Rational ClearCase は、ソースコードなどのソフトウェア開発資産のためのバージョン管理システム（構成管理、SCMも含む）である。IBM のラショナル部門が開発している。ClearCase は中規模以上の大きな商用ソフトウェアプロジェクトでよく使われ、数百人から数千人の開発者を管理できる。 ClearCase 本体にも SCM 機能があるが、それとは別に UCM という SCM 機能もある。Linux、Solaris、Windowsといった様々なプラットフォーム上で動作する。巨大なバイナリファイルや多数のファイル、巨大なリポジトリを扱える。分岐、ラベル付け、ディレクトリのバージョン付けなどが可能。 ClearCase は1992年、Atria Software が UNIX 向けに開発し、後に Windows 版もリリースされた。Atria の開発者の一部はそれ以前にアポロコ
「Hudson」改め「Jenkins」で始めるCI（継続的インテグレーション）入門：ユカイ、ツーカイ、カイハツ環境！（21）（1/4 ページ） CIツール「Hudson」改め「Jenkins」とは 「Jenkins」とは、CI（継続的インテグレーション）ツールとして有名な「Hudson」の開発者たちにより開発されているCIツールです。Hudsonは商標上などの問題によりJenkinsと名前を変えて継続することが発表されたので、記憶に残っている方も多いと思います。現在では落ち着いて開発されているようです。 本稿では、今話題のJenkinsの使い方を紹介します。本記事の想定読者は、Java開発を行っている方で、「今までCIを導入していなかったけどこれから導入しよう」「Jenkins（Hudson）は使えそうだけど、難しそうだなぁ」と思っている方を対象としています。本稿を読めば、10分程度でJe
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
