Linuxで「Git」のような更新管理を実現するにはどうすればよいですか?


14

Linuxシステムの更新を、Gitが行うのと同様の方法で、「リビジョン」内で前後に移動できるようにすることで管理したいと思います。どうすればそれができますか?


Linux / Unixシステムの動作のより深い側面を扱うLinux / Unixシステム管理者として、Gitのようなリビジョンシステムを必要とするためにシステムにどのような変更を加える必要があるか想像できません。これらのシステムで変更される主なものは、ソフトウェアのインストールと設定ファイルです。構成ファイルは、手動で簡単にバックアップおよび追跡できます。そして、それは「それを設定し、それを忘れる」という考え方に陥ります。
-JakeGould

回答:


12

おそらく、Nixパッケージマネージャを使用するNixOSをご覧ください。

NixOSは、システム構成管理の最先端を改善することを目的としたGNU / Linuxディストリビューションです。既存のディストリビューションでは、アップグレードなどのアクションは危険です。パッケージをアップグレードすると他のパッケージが破損する可能性があり、システム全体のアップグレードはゼロから再インストールするよりも信頼性が低く、構成変更の結果を安全にテストできません。システムへの変更を簡単に元に戻すことはできません。


12

おそらく探しているものは、構成管理ツールと呼ばれます。いくつかの選択肢がありますが、どの状況でもどちらが最適かは非常に主観的です。

私は個人的にPuppetを使い始めるのは非常に簡単であると感じましたが、他の一般的な選択肢はSaltAnsibleです。


私はすでに、浮浪者に人形を使用しますが、私は...私は私のOSでやったいくつかの厄介なものを元に戻すことができるという今までに覚えていない
パトリックVillela

4
通常、構成管理ツールは「ロールバック」機能を提供しません。「ロールバック」はシステムを吹き飛ばし、構成管理ツールを使用してシステムを再構成します。たとえば、Razorなどのベアメタルプロビジョニングツールを使用して、OSをフォーマットして再インストールする場合があります。次に、Chefなどのツールに渡して構成を適用します。
ctc

2
魔女は意図されていますか?:)
ルスラン

cfengineは死んでいますか?私がシステム管理者だったときに、小さなクラスターで使用することに満足したものを取り戻そうとしたことを覚えています。しかし、私は結局それを展開することはありませんでした。
ピーターコーデス

これらのツールのいずれかを使用すると、マスター構成ファイルをgitに保持することでバージョン管理を取得できます。それらから得られるものは、システム全体の構成をいくつかのテキストファイルの1つに集中化および削減することです。
ピーターコーデス

10

これはあなたの質問にとってはやり過ぎかもしれませんが、システムレベル/大規模な変更を元に戻すことができる最も簡単な方法はスナップショットです:

https://en.wikipedia.org/wiki/Snapshot_%28computer_storage%29

リグの詳細については言及していませんが、gitに精通しているので、より複雑なファイルシステムの使用に興味があるかもしれないと想像するのはそれほど難しくありません。次世代のファイルシステムを使用する場合(click-bait-yの名前は無視)、ターミナルにパンチするだけのコマンドでシステム全体を完全に「巻き戻す」ことができます。行われたすべての変更は、ごくわずかな遅延/労力で元に戻ります。ZFSが最善の策であり、この素晴らしいArsの記事を参照して、それがあなたにとって価値のあるものであるかどうかを確認することができます(他にも多くの素晴らしい機能がたくさんあります)。

http://arstechnica.com/information-technology/2014/02/ars-walkthrough-using-the-zfs-next-gen-filesystem-on-linux/


2
もう1つのオプションはbtrfsで、BTWはUbuntu、SUSE> = 11、Oracleから公式のエンタープライズサポートを受けています。まだ開発中であり、何とかしています、毎日のデスクトップの使用に信頼性があり、非常にうまく機能します。
イグニス

1
@ignis:最近、RAID 5の下にあるにもかかわらず、一貫性がなく回復不能なBtrfsに遭遇し、さらに2つのインスタンスが稼働していることを聞きました。したがって、本番環境で使用する準備ができていないという警告を軽視しません。私はそれに遭遇する前に自分でそれを信じたくありませんでした。ZFSの人々がECCメモリの使用を強く 推奨する理由の1つは、おそらくRAMの不良が原因である可能性があります。同じことがBtrfsにも当てはまると思います。
MvG

6

「更新」の意味に応じて、etckeeperなどの構成管理ツールに興味があります。これにより、システム構成への変更を自動的に記録し、以前の構成に戻すことができます。

Gitがおなじみのツールであり、「更新」が「システムパッケージの更新」または「サーバーに保存されているすべてのファイルの更新」ではなく「システム構成の更新」を意味する場合、これは見ているものですにとって。

Puppet、Ansible、Etckeeperなどのツールを使用しているかどうかにかかわらず、豚全体(別の回答で述べたスナップショットなど)を使用しない限り、データを失うことなくきれいに「ロールバック」できるとは限りません。適切なアプローチは状況によって異なります(たとえば、ロールバック時に顧客の注文を失う可能性のある運用システムにはスナップショットは適切ではありません)。



1

gitのようなシステム全体(カーネルバージョンを含む)を本当に管理したい場合は、NixOSを探しています

あまり関係のないバージョンの場合、ほとんどすべてのUNIXからNixOSのパッケージマネージャーであるnixを使用できます。Nixは単純なユーザーとしてインストールできますが、rootとしてインストールする方が簡単です。nixがインストールされると、それを使用して非特権ユーザーとしてパッケージをインストールでき、競合なしで既存のパッケージマネージャーと一緒に正常に実行されます。システムからnixを完全に削除することも非常に簡単なので、実際にそれを試してはいけない言い訳はありません。;-)

質問に直接対処するために、Nixはインストールされたシステム全体を環境として定義します。これは、gitコミットのように、インストールされたすべてのパッケージの非常に特定のバージョンへのポインターセットへのポインターです。

Nixはパッケージをアップグレードすると、新しい環境を作成します。これは、パッケージへの新しいポインターセットを指します(更新されていないパッケージのほとんどは既存のものを指します。これも、ほとんどが新しいgitコミットと非常に似ています)以前の変更されていないファイルと変更されたファイルのいくつかの新しいバージョンを指します)。

もちろん、以前のバージョンの環境に切り替えることは簡単で、フォーク(つまり、最後より古い環境に基づいて新しい環境を作成する)を信じています。環境は特定のシェル(実際、シェルで使用可能な環境変数のセット、つまり名前です)に対してロードできるため、同じマシン上の異なるプロジェクトに対して異なる環境を簡単に作成することもできます。関連のないプロジェクトには別のバージョンのライブラリが必要なので、依存関係の問題はもうありません!

NixOSはそれを次のレベルに引き上げ、同様の方法でカーネルを含むコンピューター全体を管理し、マシン全体の非常に低いリスクのアップグレードを可能にします。

私はそれらのすべてを読み終えていませんが、Nixの紹介として致死薬のNix錠剤をお勧めします。


0

あなたが実験的なタイプの場合、ファイルシステム全体をローカルgitリポジトリにチェックインしてみてください。これは...面白いと思います。

  1. git init ルートディレクトリ内 /
  2. 内容が頻繁に変更される、またはチェックインされるべきではないディレクトリを無視するルートの.gitignoreを作成します。
    • / dev
    • /実行
    • / tmp
    • / proc
    • / lost + found
    • ...
  3. 除外したい特定のファイルタイプを.gitignoreに追加します。
    • * .tmp
    • *。ログ
    • ...
  4. で初期コンテンツを追加 git add -A .
  5. スナップショットをコミットします git commit -m "Initial Snapshot"
  6. コンピューターを使用する
  7. スナップショットgit commit -Am "Snapshot X"などを定期的に追加します

いくつかの利点があります:

  • のようなgitk、改訂履歴用の使い慣れたツールgit diff
  • Livecdまたはgitを搭載した他のオペレーティングシステムは、バックアップを復元できます。
  • システム全体をgithubにプッシュして他のマシンに復元したり、他のユーザーと共有したりできますか?
  • 分岐は高速で直感的です
  • ルートの/、gitディレクトリは、ソースコードと同様に、システムを悪用し、より冒険的になる自信を与えます
  • 後続の各スナップショットは、他のバックアップソリューションと比較して比較的小さくなります。
  • / etcで設定の変更を確認および追跡するには素晴らしい
  • これを先駆けて、gitでlinit-linuxと呼ぶことができます。
  • 汚名

奇妙なものには次のものがあります。

  • 大幅な変更、またはシステムの実行中に使用されているファイルへの変更を伴うブランチまたはリビジョンを復元/チェックアウトできる可能性はありません。
  • かなり大きな初期コミット
  • 後続の.gitディレクトリでチェック--
  • gitルートgitコンテナにネストされたソースコードディレクトリにいるときに期待どおりに動作することを期待します。
  • / etc / passwdと/ etc / shadowは、ユーザーを維持および追跡し、他のマシンに復元するためにリポジトリに含める必要がありますが、ビューアクセス(おそらくgithub上の)を持つ誰でもコンテンツ、権限、ユーザーのパスワードハッシュ。

3
gitはパーミッションを適切に処理しないため、このアプローチは恐ろしく失敗する可能性が高いです。すべてをルートとして行うと仮定すると、基本的にファイルシステム全体をルートにチャネリングし、その結果、書き込み操作が中断されます。たとえば、スナップショットを作成して復元し、Apacheログディレクトリの所有者が(httpではなく)ルートになり、Apacheがディレクトリに書き込めないため、起動に失敗します。似たようなことを試みたが、はるかに小規模で、その上でさえ問題があったので、私はそれを知っています。
トゥンジャイGöncüoğlu

別の回答で示唆されているように、Nixを見てください;)
マイケルパンコフ

知っておきたい!私のスクリプトはクローンでxフラグを保持しているため、少なくともオクテットの許可を処理すると思いましたが、ファイルとグループの所有権については考えていませんでした
-Ehryk

必要に応じて、完全な許可と所有権を保持する追加のツールがあるように見えます。そのようなツールがあるのgit -キャッシュ-メタ、およびここではリストです
Ehryk
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.