ステータス:非推奨

この記事では、サポートされなくなったバージョンのUbuntuについて説明します。 現在Ubuntu12.04を実行しているサーバーを運用している場合は、サポートされているバージョンのUbuntuにアップグレードまたは移行することを強くお勧めします。

理由:
Ubuntu 12.04は2017年4月28日に保守終了(EOL)に達しました and no longer receives security patches or updates. This guide is no longer maintained.

代わりに参照してください:このガイドは参照として役立つ場合がありますが、他のUbuntuリリースでは機能しない場合があります。 可能な場合は、使用しているUbuntuのバージョン用に作成されたガイドを使用することを強くお勧めします。 ページ上部の検索機能を使用して、より新しいバージョンを見つけることができます。

序章


Linuxマシンで作業するとき、環境をかなり大幅にカスタマイズし始める可能性があります。 テキストエディタのようないくつかの一般的に使用されるアプリケーションは非常に構成可能であるため、変更されていないバージョンは完全に異なるプログラムのように見える可能性があります。

構成を微調整するにはかなりの作業が必要になる可能性があり、使用法が時間の経過とともに変化するにつれて、多くの場合、小さな編集を行うことになります。 これは、1台のコンピューターで処理するのは大変ですが、複数のマシン間で設定を同期したい場合、物事はすぐに複雑で扱いにくくなる可能性があります。

この記事では、マシン間で共有したい複雑な構成ファイルを処理するための1つのアプローチについて説明します。 重要なファイルを管理するためにgitバージョン管理を使用します。 次に、これらをリモートリポジトリにアップロードしてから、それらのファイルを他のコンピューターにプルダウンします。

これらのアイデアをUbuntu12.04マシンでデモンストレーションしますが、gitの性質と使用する構成ファイルにより、適度に最新のLinuxディストリビューションも同様に機能するはずです。

基本的な考え方


このアイデアを実装する実際の手順に進む前に、実際に設定する内容について説明しましょう。

いくつかの重い構成がすでに進行中の1台のコンピューターがあると想定します。 これは、gitリポジトリを構築するために使用するシステムです。 適切なファイルをリポジトリに追加してから、リモートのgitリポジトリにプッシュします。

リモートgitリポジトリは、構成データを保存できる場所になります。 構成ファイルを配置する可能性のある他のすべてのマシンからアクセスできる必要があります。 GitHubのようなパブリックスペースを使用してファイルをホストすることに抵抗がない人もいますが、これには、機密データを誤って世界中の読み取り可能な場所にプッシュするリスクが伴います。

このガイドでは、代わりに、自分のマシンにインストールして使用できるセルフホスティングのgitリポジトリソリューションであるGitLabを使用します。 DigitalOceanは、事前構成されたGitLabVPSを作成するためのワンクリックGitLabインストールイメージを提供します。 また、GitLabを自分でインストールする方法についても説明します。

構成ファイルがリモートのgitリポジトリに配置されたら、ファイルを新しいシステムにプルして設定を実装できます。

どのタイプのファイルをコミットする必要がありますか?


新しいシステムで行うカスタマイズにはさまざまなレベルがありますが、このタイプのソリューションには、他のタイプよりもいくつかのタイプのファイルとカスタマイズが適しています。

システムに大きく依存する値を持つファイルは、手動で処理するか、Chef、Puppet、Ansibleなどの構成管理システムなどの他の方法を使用して処理する必要があります。

行っているカスタマイズがユーザー設定が少なく、システム操作の詳細に近い場合は、gitを使用してもあまり役に立ちません。 とにかくクライアントシステムに一致するようにほとんどの値を変更する必要があります。

ツールとユーザー環境ファイルの構成は、このタイプのソリューションに最適です。 vim、emacs、screen、tmux、bashなどのカスタマイズなど。 このタイプの構成の優れた候補です。

一般に、経験則として、機密性の高い、またはマシンに大きく依存する設定を含まない「ドットファイル」(ホームディレクトリ内にある非表示の構成ファイル)を使用できます。 GitLabのようにGitHubの代わりに自己ホスト型のファイルを使用している場合は、自己責任で機密情報を含むファイルを含めることができます。

シードマシンのセットアップ


「シード」マシンとして使用する構成ファイルが既に変更されているコンピューターを参照します。 これは、構成ファイルが作成される場所になります。

構成の同期を実際に実装できるように、gitがインストールされていることを確認する必要があります。 ディストリビューションが提供するリポジトリからgitをインストールします。 Ubuntuの場合、次のコマンドが機能するはずです。

sudo apt-get update
sudo apt-get install git

gitをインストールしたら、コミットメッセージをクリーンに保つための構成の詳細を設定する必要があります。 次のコマンドで自分の名前とメールアドレスに置き換えます。

 git config --global  user.nameあなたの名前」gitconfig--globaluser.email「 email  @ドメイン .com

この時点で、私たちがとることができるいくつかの異なるアプローチがあります。 この選択は後の進め方に影響するので、それぞれを順番に説明しましょう。

ホームディレクトリ全体をGitリポジトリとして使用する


おそらく、私たちが持っている最も簡単なアプローチは、ホームディレクトリ内のgitリポジトリを単純に初期化することです。 このアプローチには、非常に単純でわかりやすいという利点がありますが、状況が進むにつれて混乱する可能性があります。

このメソッドは、次のように入力することで開始できます。

cd ~
git init

gitリポジトリがホームディレクトリ内に作成されます。 ファイルの状態を見ると、「追跡されていない」とマークされたファイルがたくさんあることがわかります。

git status

# On branch master
#
# Initial commit
#
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#	.bash_history
#	.bash_logout
#	.bashrc
#	.gitconfig
#	.profile
#	.screenrc
#	.ssh/
#	.viminfo
#	.vimrc
nothing added to commit but untracked files present (use "git add" to track)

gitがすべてのファイルを見るのは良いことですが、ファイルの大部分が「追跡されていない」と見なされ、これを見るたびにこのような長いリストを作成すると、このコンピューターをより多く使用するため、かなり苦痛になります。

それでも気にならない場合は、次のように、必要なファイルをgitリポジトリに追加するだけです。

git add .bashrc
git add .vimrc
. . .

gitステータスをクリーンに保ち、有用と思われる情報のみを提供する場合は、代わりにgitにデフォルトで all ファイルを無視するように指示できます。特に、ファイルの例外を作成できます。バージョン管理にチェックインしたいと思います。

これを行うには、ディレクトリに.gitignoreファイルを作成します。このファイルには、すべてに一致するワイルドカードが含まれています。

echo "*" > .gitignore

これを実行してリポジトリのステータスを確認すると、追跡するものが何もないことがわかります。

git status

# On branch master
#
# Initial commit
#
nothing to commit (create/copy files and use "git add" to track)

このシナリオでは、-fフラグを使用して、追加するファイルを強制的に追加する必要があります。

git add -f .bashrc
git add -f .vimrc
. . .

いずれにせよ、終了したら変更をコミットする必要があります。

git commit -m "Initial configuration commit"

ファイルを保存するための構成ディレクトリの作成


ホームディレクトリ全体を含むgitリポジトリを作成する別の方法は、これらのファイルを追跡するために特別に別のディレクトリを作成することです。

このチュートリアルでは、このディレクトリをconfigsと呼びます。

cd ~
mkdir configs

このディレクトリに入り、ホームディレクトリの代わりにここでgitリポジトリを初期化できます。

cd configs
git init

これでgitリポジトリができましたが、中にファイルはありません。 ファイルをこのディレクトリに配置して、バージョン管理システムでコミットできるようにしますが、プログラムがファイルを正しく検出できるように、ファイルをホームディレクトリで使用できるようにします。

これらの目的の両方を達成する解決策は、ファイルをこのディレクトリにコピーしてから、システムリンクを作成してメインディレクトリに戻すことです。

各ファイルについて、これは次のようになります。

mv ~/.vimrc .
ln -s .vimrc ~/
mv ~/.bashrc .
ls -s .vimrc ~/
. . .

これで、すべての実際の構成ファイルが~/configsディレクトリにあり、これらのファイルへのシンボリックリンクがホームディレクトリにあります。

これはもっと複雑に聞こえるかもしれませんが、それは物事のgit側をかなり単純化します。 すべてのファイルを追加するには、次のように入力します。

git add .

そして、次のようにコミットできます。

git commit -m "Initial configuration commit"

このアプローチはgit側を単純化しますが、ファイルの実際の管理を少し複雑にする可能性があります。

作業ツリーからGitディレクトリを分離する


3番目のアプローチは、ホームディレクトリ自体をバージョン管理しようとすることに固有の問題のいくつかに対処しようとします。 実際のgitリポジトリをファイルをプルする場所から分離します。

これは、ホームディレクトリを直接バージョン管理するというアイデアが好きな場合に役立ちますが、他のgitリポジトリを使用すると事態が複雑になることがわかります。

基本的に、gitリポジトリを初期化すると、デフォルトでは、現在のディレクトリが、チェックアウトによってファイルが配置および変更される作業ディレクトリと見なされます。 .gitというgitリポジトリがこのディレクトリに作成されます。

ただし、gitに別の作業ディレクトリを使用させることはできます。

構成用に別のディレクトリを作成することで、最後の方法で行ったのとほぼ同じように開始できます。

cd ~
mkdir configs

ここでも、ディレクトリ内に移動して、gitリポジトリを初期化します。

cd configs
git init

物事がどのように変化するかを示すために、gitstatusが今何を言っているか見てみましょう:

git status

# On branch master
#
# Initial commit
#
nothing to commit (create/copy files and use "git add" to track)

現在、作業ディレクトリは、リポジトリが配置されている~/configsディレクトリです。 ここにはファイルがないため、コミットするものがなく、空として表示されます。

今、私たちは少し違ったやり方をしています。 core.worktree git構成オプションを使用して、別の作業ディレクトリを指定することから始めます。

git config core.worktree "../../"

これは、.gitディレクトリのパスを基準にして作業ディレクトリを確立することです。 最初の../~/configsディレクトリを指し、2番目のディレクトリはそれを一歩超えてホームディレクトリを指します。

基本的に、gitに「リポジトリをここに保持しますが、管理しているファイルはリポジトリの2レベル上にあります」と伝えました。

何が変更されたかを確認するために、ステータスを再度確認できます。

git status

# On branch master
#
# Initial commit
#
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#       ../.bash_history
#       ../.bash_logout
#       ../.bashrc
#       ../.gitconfig
#       ../.lesshst
#       ../.profile
#       ../.screenrc
#       ../.ssh/
#       ../.viminfo
#       ../.vimrc
nothing added to commit but untracked files present (use "git add" to track)

gitがホームディレクトリ内のファイルを参照していることがわかります。

これで、ホームディレクトリとの関係でファイルを参照してファイルを追加できます。

git add ~/.vimrc
git add ~/.screenrc
git add ~/.bashrc
. . .

次に、次のようにコミットできます。

git commit -m "Initial configuration commit"

ディレクトリに、後で情報を取得する必要がある場合にgitがすべての部分を元に戻すには、/.gitファイルを配置する必要があります。

cd ~
nano .git

内部に必要なのは、gitをリポジトリファイルに転送する行だけです。

gitdir:/ home / your_user /configs/.git

これにより、すべてがスムーズに機能します。

リモートGitサーバーのセットアップ


ニーズに応じて、ファイルを格納するためのリモートリポジトリを設定するためのさまざまなオプションがあります。

明らかな選択は、構成リポジトリをGitHubにプッシュすることです。 これは一部の人にとっては素晴らしいアプローチかもしれませんが、機密データを誤って公開する可能性があることに注意してください。

独自のプライベートgitリポジトリにプッシュしてこれを回避したい場合は、GitLabが最適です。

DigitalOceanでは、ワンクリックGitLabイメージを使用して、地面にぶつかることができます。

もう1つのオプションは、GitLabを自分でインストールすることです。 このガイドでは、自分のサーバーにGitLabをインストールして構成する方法について説明します。

設定方法に関係なく、リモートターゲットとして機能する新しい空のリポジトリを作成する必要があります。

空のリポジトリを作成すると、GitHubまたはGitLabにより、構成ファイルをリポジトリに取り込む方法に関するコマンドが記載されたページが表示されます。 SSHキーをすでに追加していない限り、ボタンをクリックしてSSHではなくHTTPコマンドに切り替えることをお勧めします。

次のようになります。

GitLab existing repo

コマンドの提案を使用して、構成をリモートリポジトリに取り込みます。 ほとんどの場合、次のようなものになります。

cd configs#または「cd〜」(ホームディレクトリを使用している場合) git remote add origin http:// git_lab_ip / your_gitlab_user / repo_name .git git push -u origin master

これにより、構成がGitLabリポジトリにプッシュされます。

リモートリポジトリから構成をプルする


リモートリポジトリに構成ファイルがあるので、他のマシンからそれらをプルダウンできます。 構成ファイルを追加するサーバーを「ターゲット」マシンと呼びます。

ターゲットマシンに、gitがインストールされていることを確認してください。 Ubuntuでは、これも次のように実行されます。

sudo apt-get update
sudo apt-get install git

これをインストールしたら、基本的な構成変数を再度設定する必要があります。

 git config --global  user.nameあなたの名前」gitconfig--globaluser.email「 email  @ドメイン .com

次のステップは、このマシンがgitリポジトリファイルとどのように相互作用するかによっても異なります。

ホームディレクトリをバージョン管理下に置く


ホームディレクトリ全体をgitバージョン管理下に置きたい場合は、そこで空のgitリポジトリを開始する必要があります。

cd ~
git init

ここから、このリポジトリの起点としてGitHubまたはGitLabリポジトリを追加できます。

git remote add origin http:// git_lab_ip / your_gitlab_user / repo_name .git

この時点以降、リポジトリにあるものと競合する可能性のあるファイルがこのマシンにすでにある場合は、少し異なることを行う必要があります。 たとえば、~/.bashrcファイルは通常、各ユーザーのデフォルトで含まれています。

1つのオプションは、リポジトリファイルと競合する各ファイルを削除または移動することです。 ただし、競合するすべてのファイルをリモートバージョンで上書きするようにgitに指示することもできます。

これを行うには、最初にリモートファイルをフェッチしてから、gitに最新のコミットにリセットするように指示します。これはリモートバージョンである必要があります。

git fetch --all
git reset --hard origin/master

これにより、すべてのリモートファイルが新しいマシンに取り込まれるはずです。

このマシン上のファイルを簡単に変更して、リモートリポジトリにプッシュバックすることもできます。

echo "# a comment" >> .bashrc
git add .bashrc
git commit -m "test"
git push origin master

別の構成ディレクトリを使用する


別のディレクトリを使用して実際の構成ファイルを保持する場合で、それらのファイルをホームディレクトリにリンクするだけの場合は、代わりにリポジトリのクローンを作成できます。

リモートリポジトリを再度参照するURLが必要です。 今回は、新しいgitリポジトリを初期化する代わりにcloneを使用します。

git clone http:// git_lab_ip / your_gitlab_user / configs .git

これで、新しく複製されたディレクトリに移動できます。

cd configs

これには、すべての構成ファイルが含まれます。 次に、それらを個別にホームディレクトリにリンクできます。

ln -s .vimrc ~/
ln -s .screenrc ~/

繰り返しますが、新しいファイルと競合するファイルを移動または削除する必要がある場合があります。

rm ~/.bashrc
ln -s .bashrc ~/

これはより手動のプロセスですが、このコンピューターでアクティブにするファイルをよりきめ細かく制御できます。

個別のGitリポジトリとディレクトリを実装する


シードマシンについて説明した、分離された作業ディレクトリとリポジトリのセットアップを実装するために、リポジトリのクローンを再度作成できます。

この方法との違いは、リポジトリがファイルをホームディレクトリに直接アンロードするため、クローン作成時にファイルをチェックアウトしないことです。

git clone --no-checkout http:// git_lab_ip / your_gitlab_user / configs .git

次に、~/configs/.gitディレクトリ(ホームディレクトリ)の2層上のディレクトリにファイルを解凍することをgitに通知する必要があります。

cd configs
git config core.worktree "../../"

これで、ファイルを明示的にチェックアウトできます。 繰り返しますが、gitに現在のファイルを上書きさせる必要があります。 これを行うには、リモートリポジトリからファイルがあった状態に「リセット」します。

git reset --hard origin/master

これで、構成ファイルが新しいコンピューターで使用できるようになります。

結論


これで、個人用構成ファイルをバージョン管理に保持する方法についていくつかのオプションがあります。 構成ファイルへの変更をリモートリポジトリに継続的にコミットすることにより、リモートマシン上で環境の最も重要な部分をすばやく簡単に再作成できるはずです。

ジャスティン・エリングウッド