Git을 사용하여 Linux VPS에서 사용자 구성 파일을 관리하는 방법
상태: 더 이상 사용되지 않음
이 문서에서는 더 이상 지원되지 않는 Ubuntu 버전에 대해 설명합니다. 현재 Ubuntu 12.04를 실행하는 서버를 운영 중인 경우 지원되는 Ubuntu 버전으로 업그레이드하거나 마이그레이션하는 것이 좋습니다.
- Ubuntu 14.04로 업그레이드합니다.
- Ubuntu 14.04에서 Ubuntu 16.04로 업그레이드
- 서버 데이터를 지원되는 버전으로 마이그레이션
이유:
대신 참조:
소개
Linux 시스템으로 작업할 때 환경을 상당히 많이 사용자 지정하기 시작할 수 있습니다. 텍스트 편집기와 같이 일반적으로 사용되는 일부 응용 프로그램은 구성이 가능하여 수정되지 않은 버전이 완전히 다른 프로그램처럼 보일 수 있습니다.
구성을 조정하는 데 상당한 작업이 필요할 수 있으며 시간이 지남에 따라 사용량이 변경됨에 따라 사소한 편집을 수행하는 경우가 많습니다. 단일 컴퓨터에서 처리하기에는 많은 일이 될 수 있지만 여러 컴퓨터에서 설정을 동기화하려는 경우 작업이 빠르게 복잡하고 다루기 어려워질 수 있습니다.
이 기사에서는 시스템 간에 공유하려는 복잡한 구성 파일을 처리하는 한 가지 접근 방식에 대해 설명합니다. 중요한 파일을 관리하기 위해 git 버전 제어를 사용할 것입니다. 그런 다음 이러한 파일을 원격 저장소에 업로드한 다음 해당 파일을 다른 컴퓨터로 가져올 수 있습니다.
우리는 Ubuntu 12.04 시스템에서 이러한 아이디어를 시연할 것이지만 git의 특성과 우리가 사용할 구성 파일로 인해 합리적으로 최신 Linux 배포판은 비슷한 방식으로 작동해야 합니다.
기본 아이디어
이 아이디어를 구현할 실제 단계로 이동하기 전에 실제로 설정할 항목에 대해 이야기해 보겠습니다.
무거운 구성이 이미 진행 중인 한 대의 컴퓨터가 있다고 가정합니다. 이것은 우리가 git 저장소를 구축하는 데 사용할 시스템입니다. 저장소에 적절한 파일을 추가한 다음 원격 git 저장소로 푸시합니다.
원격 git 저장소는 구성 데이터를 저장할 수 있는 장소입니다. 구성 파일을 배치하려는 다른 모든 시스템에서 액세스할 수 있어야 합니다. 일부 사람들은 GitHub와 같은 공용 공간을 사용하여 파일을 호스팅하는 것이 편하다고 느끼지만 이렇게 하면 실수로 민감한 데이터를 누구나 읽을 수 있는 위치로 푸시할 위험이 있습니다.
이 가이드에서는 대신 자신의 컴퓨터에 설치하고 사용할 수 있는 자체 호스팅 git 리포지토리 솔루션인 GitLab을 사용합니다. DigitalOcean은 미리 구성된 GitLab VPS를 생성할 수 있는 원클릭 GitLab 설치 이미지를 제공합니다. 또한 해당 경로로 이동하려는 경우 GitLab을 직접 설치하는 방법도 다룰 것입니다.
구성 파일이 원격 git 저장소에 있으면 파일을 새 시스템으로 가져와서 설정을 구현할 수 있습니다.
어떤 유형의 파일을 커밋해야 합니까?
새 시스템으로 수행하는 다양한 수준의 사용자 지정이 있지만 일부 유형의 파일 및 사용자 지정은 다른 솔루션보다 이 유형의 솔루션에 더 적합합니다.
시스템에 크게 의존하는 값이 있는 파일은 수동으로 처리하거나 Chef, Puppet 또는 Ansible과 같은 구성 관리 시스템과 같은 다른 방법을 사용하여 처리해야 합니다.
수행 중인 사용자 정의가 사용자 선호도가 적고 시스템 운영 세부 사항에 더 가깝다면 git을 사용하는 것이 별 도움이 되지 않을 것입니다. 어쨌든 클라이언트 시스템과 일치하도록 대부분의 값을 변경해야 합니다.
도구 및 사용자 환경 파일에 대한 구성은 이러한 유형의 솔루션에 가장 적합합니다. vim, emacs, screen, tmux, bash 등에 대한 사용자 정의와 같은 것들이 이러한 유형의 구성에 적합한 후보입니다.
일반적으로 좋은 경험 법칙은 민감하거나 컴퓨터에 크게 의존하지 않는 설정을 포함하지 않는 모든 "dotfile\(홈 디렉터리에 있는 숨겨진 구성 파일)을 사용할 수 있다는 것입니다. GitHub 대신 자체 호스팅 대안을 사용하는 경우 , GitLab과 마찬가지로 민감한 정보가 포함된 파일을 포함할 수 있습니다.
종자 기계 설정
"시드\ 머신으로 사용하려는 구성 파일을 이미 수정한 컴퓨터를 참조할 것입니다. 여기가 구성 파일이 시작되는 위치가 될 것입니다.
구성 동기화를 실제로 구현할 수 있도록 git이 설치되어 있는지 확인해야 합니다. 배포판에서 제공하는 리포지토리에서 git을 설치합니다. Ubuntu의 경우 다음 명령이 작동합니다.
sudo apt-get update
sudo apt-get install git
git을 설치한 후 커밋 메시지를 깨끗하게 유지하기 위해 몇 가지 구성 세부 정보를 설정해야 합니다. 다음 명령에서 자신의 이름과 이메일 주소를 대체하십시오.
<예비>
이 시점에서 우리는 다양한 접근 방식을 취할 수 있습니다. 이 선택이 나중에 진행하는 방식에 영향을 미치므로 각각을 차례로 설명하겠습니다.
전체 홈 디렉토리를 Git 저장소로 사용
아마도 우리가 가진 가장 간단한 접근 방식은 단순히 홈 디렉토리 내에서 git 저장소를 초기화하는 것일 것입니다. 이 접근 방식은 매우 간단하고 직선적이라는 장점이 있지만 작업이 진행됨에 따라 지저분해질 수 있습니다.
다음을 입력하여 이 방법을 시작할 수 있습니다.
cd ~
git init
홈 디렉토리 내에 git 저장소가 생성됩니다. 파일 상태를 보면 "untracked\로 표시된 파일이 많이 있음을 알 수 있습니다.
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 repo에 추가할 수 있습니다.
git add .bashrc
git add .vimrc
. . .
git 상태를 깨끗하게 유지하여 유용하다고 생각할 수 있는 정보만 제공하려면 기본적으로 모든 파일을 무시하도록 git에 지시할 수 있습니다. 버전 제어를 확인하려는 파일.
모든 항목과 일치하는 와일드카드가 있는 .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 디렉토리 분리
세 번째 접근 방식은 홈 디렉토리 자체를 버전화하려고 할 때 내재된 일부 문제를 해결하려고 시도합니다. 파일을 가져오는 위치에서 실제 git 저장소를 분리합니다.
이것은 홈 디렉토리를 직접 버전 관리하는 아이디어가 마음에 들지만 다른 git 리포지토리를 갖는 것이 복잡하다는 것을 알게 된 경우에 유용할 수 있습니다.
기본적으로 git repo를 초기화할 때 기본적으로 현재 디렉터리는 체크아웃이 파일을 배치하고 수정하는 작업 디렉터리로 간주됩니다. .git
라는 git 저장소가 이 디렉토리에 생성됩니다.
그러나 git이 별도의 작업 디렉토리를 사용하도록 강제할 수 있습니다.
구성을 위한 별도의 디렉터리를 생성하여 마지막 대안에서 했던 것처럼 시작할 수 있습니다.
cd ~
mkdir configs
다시 디렉터리 내부로 이동한 다음 git 저장소를 초기화합니다.
cd configs
git init
상황이 어떻게 변할지 보여주기 위해 지금 git status가 무엇을 말하는지 봅시다.
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
디렉토리를 참조하고 두 번째는 그보다 한 단계 더 나아가 홈 디렉토리를 가리킵니다.
기본적으로 우리는 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
# ../.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을 repo 파일로 안내하는 줄입니다.
<예비>
이렇게 하면 모든 것이 원활하게 작동합니다.
원격 Git 서버 설정
필요에 따라 파일을 저장할 원격 리포지토리를 설정하는 다양한 옵션이 있습니다.
분명한 선택은 구성 리포지토리를 GitHub로 푸시하는 것입니다. 이것은 어떤 사람들에게는 훌륭한 접근 방식일 수 있지만 실수로 중요한 데이터를 노출할 가능성이 있음을 명심하십시오.
자신의 개인 git 리포지토리로 푸시하여 이를 방지하려면 GitLab이 탁월한 선택입니다.
DigitalOcean에서 클릭 한 번으로 GitLab 이미지를 사용하여 시작할 수 있습니다.
또 다른 옵션은 GitLab을 직접 설치하는 것입니다. 이 가이드는 자체 서버에 GitLab을 설치하고 구성하는 방법을 안내합니다.
설정 방법에 관계없이 원격 대상 역할을 할 새 빈 리포지토리를 만들어야 합니다.
빈 리포지토리를 생성하면 GitHub 또는 GitLab에서 구성 파일을 리포지토리로 가져오는 방법에 대한 명령이 포함된 페이지를 제공합니다. 이미 SSH 키를 추가하지 않은 경우 버튼을 클릭하여 SSH 대신 HTTP 명령으로 전환할 가능성이 높습니다.
다음과 같이 표시됩니다.

명령 제안을 사용하여 구성을 원격 리포지토리로 가져옵니다. 아마도 다음과 같은 내용일 것입니다.
<예비>
이렇게 하면 구성이 GitLab 저장소로 푸시됩니다.
원격 저장소에서 구성 가져오기
이제 원격 리포지토리에 구성 파일이 있으므로 다른 시스템에서 가져올 수 있습니다. 구성 파일을 추가하려는 서버를 "대상\ 시스템으로 참조합니다.
대상 머신에 git이 설치되어 있는지 확인하십시오. 우분투에서는 다음과 같이 다시 수행됩니다.
sudo apt-get update
sudo apt-get install git
이것을 설치했으면 기본 구성 변수를 다시 설정해야 합니다.
<예비>
다음 단계는 이 시스템이 git repo 파일과 상호 작용하는 방식에 따라 달라집니다.
홈 디렉토리를 버전 제어하에 놓기
전체 홈 디렉토리를 git 버전 제어 아래에 두려면 여기에서 빈 git repo를 시작해야 합니다.
cd ~
git init
여기에서 GitHub 또는 GitLab 저장소를 이 저장소의 원본으로 추가할 수 있습니다.
<예비>
이 시점 이후에 이 시스템에 이미 저장소에 있는 파일과 충돌할 수 있는 파일이 있는 경우 약간 다른 작업을 수행해야 합니다. 예를 들어 ~/.bashrc
파일은 일반적으로 각 사용자에 대해 기본적으로 포함됩니다.
한 가지 옵션은 repo 파일과 충돌하는 각 파일을 삭제하거나 이동하는 것입니다. 그러나 충돌하는 모든 파일을 원격 버전으로 덮어쓰도록 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 저장소를 초기화하는 대신 복제를 사용합니다.
<예비>
이제 새로 복제된 디렉토리로 이동할 수 있습니다.
cd configs
여기에는 모든 구성 파일이 있습니다. 그런 다음 개별적으로 홈 디렉토리에 연결할 수 있습니다.
ln -s .vimrc ~/
ln -s .screenrc ~/
다시 말하지만 새 파일과 충돌하는 파일을 이동하거나 삭제해야 할 수 있습니다.
rm ~/.bashrc
ln -s .bashrc ~/
이는 보다 수동적인 프로세스이지만 이 컴퓨터에서 활성화하려는 파일을 보다 세밀하게 제어할 수 있습니다.
별도의 Git Repo 및 디렉터리 구현
시드 머신에 대해 이야기한 분리된 작업 디렉토리 및 리포지토리 설정을 구현하기 위해 리포지토리를 다시 복제할 수 있습니다.
이 방법의 차이점은 리포지토리가 파일을 홈 디렉터리로 직접 언로드하기를 원하기 때문에 복제 시점에 파일을 체크아웃하지 않는다는 것입니다.
<예비>
이제 ~/configs/.git
디렉터리(홈 디렉터리) 위의 두 계층에 위치한 디렉터리에 파일 압축을 풀고 싶다고 git에게 알려야 합니다.
cd configs
git config core.worktree "../../"
이제 파일을 명시적으로 체크아웃할 수 있습니다. 다시 말하지만, git이 현재 파일을 덮어쓰도록 강제해야 합니다. 원격 저장소에서 파일이 있었던 상태로 다시 "재설정\하여 이를 수행할 수 있습니다.
git reset --hard origin/master
이제 새 컴퓨터에서 구성 파일을 사용할 수 있습니다.
결론
이제 버전 제어에서 개인 구성 파일을 유지하는 방법에 대한 몇 가지 옵션이 있습니다. 구성 파일에 대한 변경 사항을 원격 리포지토리에 지속적으로 커밋함으로써 원격 시스템에서 환경의 가장 중요한 부분을 빠르고 쉽게 다시 생성할 수 있어야 합니다.