Hallo nochmal. Woche (dieser Artikel wurde sehr lange im Rückstand eingelegt) Vor einiger Zeit habe ich darüber gesprochen, wie man rcm für das normale Konfigurationsmanagement verwendet . Wir haben ein Puppenmodul in unserem Unternehmen, das die persönlichen Einstellungen des Benutzers an alle Hosts verteilt, auf die er Zugriff hat. Dementsprechend möchte ich Folgendes:
- Habe meine eigenen Einstellungen für alles, was ich benutze (vim, zsh, git, etc ..)
- Aktualisieren Sie sie, während sie im Dotfiles-Repository aktualisiert werden
- All dies - ohne unnötige Gesten
Die Werkzeuge
Alles, was benötigt wird, wird von mir bereits verwendet, nämlich:
Hier gibt es nichts Schwieriges: Wir stellen Tarballs bereit, indem wir ihren Inhalt auf Hosts entpacken. Es werden nur Dateien und Verzeichnisse aus einer bestimmten Liste verwaltet, wobei jede Krone bei jeder Bereitstellung vollständig geschliffen wird. Wenn sich der Tarball geändert hat, wird dementsprechend alles in der $HOME Liste gerieben. Wenn nicht, bleibt der Inhalt von $ HOME unverändert. Ein separates Skript ist dafür verantwortlich, den Ordner mit den Quelldateien der persönlichen Dateien (neu) zu packen. Es sieht ziemlich trivial aus:
So erstellen Sie einen neuen Commit-Ball-Tarball
Stellen Sie Dotfiles bereit, die nicht in $ HOME enthalten sind
Da ich bereits ein Tool habe, mit dem ich Konfigurationen auf verschiedenen Hosts bereitstellen kann, werde ich es natürlich verwenden. Sie müssen nur etwas reparieren und rcm die Dateien rcm kopieren, wo ich sie brauche. Rcm setzt die Punktdateien jedoch immer in $ HOME. Es gibt keine Befehlszeilenargumente, um dieses Verhalten zu ändern.
Nach einigen Experimenten und dem Auswählen der Quelle wurde mir klar, dass Sie $ HOME direkt ändern können. Dann ändert sich das Verhalten der Dienstprogramme aller rcm-Befehle wie folgt: Jedes der Dienstprogramme lsrc, mkrc, rcdn, rsup liest ${HOME}/.rcrc und verwendet ${HOME}/.dotfiles standardmäßig. Dementsprechend reicht es aus, dasselbe ${HOME}/.rcrc mit allen erforderlichen Parametern zu erstellen.
Am einfachsten ist es, den Home-Ordner "leer" zu machen und ihn bei jedem Commit von Grund auf neu zu füllen. Ein Beispiel dafür, wie es aussieht, finden Sie im Repository . Dieser Ordner wird auf allen Hosts ohne das persönliche Tag ignoriert und beeinträchtigt dementsprechend nicht die Hauptkonfiguration. Eine einzelne .rcrc- Datei enthält alle Parameter für die Dateikopierlogik. Ich werde nur einige Anmerkungen machen:
- Ohne
$SYMLINK_DIRS funktioniert rcup hoffnungslos lange und erstellt eine vollständige Liste der zu kopierenden Dateien. Mit dieser Option $COPY_ALWAYS Dienstprogramm zusammen mit $COPY_ALWAYS einfach den gesamten Ordner ohne unnötige Probleme als cp -r - Offensichtlich wird auf Remote-Servern nicht viel benötigt, all dies ist in
$EXCLUDES (mit Ausnahme von vim-Plugins müssen sie im Hook entfernt werden, da $SYMLINK_DIRS ). - Da
${HOME}/.dotfiles aus offensichtlichen Gründen nicht mehr funktioniert, müssen Sie auch $DOTFILES_DIRS
Das ist alles. Jetzt können Sie den Tag-Personal-Ordner an eine beliebige Stelle kopieren, ${HOME} für eine Weile überschreiben und rcup
WORK_DIR="${HOME}/.dotfiles/tag-personal" _OLD_HOME=$HOME HOME="${HOME}/some/long/custom/path" cp -r "${WORK_DIR}" "${HOME}" rcup -v HOME=$_OLD_HOME
Wow! Aber ich will noch etwas ...
Wir automatisieren die "Bereitstellung" von Konfigurationen für benutzerdefinierte $ HOME
Es ist einfach, dieses „Etwas“ zu machen. Git an dieser Stelle hilft bei seinen Haken. Es gibt eine ausführbare Datei .git/hooks/post-commit folgendem Inhalt:
Nach jedem Commit in das Repository mit Punktdateien wird dieses Skript gestartet.
Alles danach bleibt es, ein Commit + Push mit persönlichen Daten in das Repository zu machen und zu warten, bis die Automatisierungsmagie meine Konfigurationen zu funktionierenden Hosts bringt.
Warum solche Dinge komplizieren?
Tatsache ist, dass das Unternehmen zwar keine Tools zum Bereitstellen einer persönlichen Konfiguration auf Hosts hatte, ein solches Kit jedoch nicht erforderlich war. Aber sobald sich die Gelegenheit ergibt, wächst der Appetit sofort. Einige meiner Kollegen waren zufrieden mit der Tatsache, dass sie drei Dateien auf die Hosts gebracht haben, z. B. .vimrc .bashrc .gitconfig . Ich hatte jedoch lange Zeit liebevoll eine ganze Reihe verschiedener Werkzeuge geschärft, korrigiert und poliert. Nur der ~/.vim nach der Installation aller Plugins wiegt 427 MB (ja, 218 davon sind YCM, und ich ziehe ihn nicht auf die Server, und nach dem Reinigen und Packen verliert alles Gewicht bis zu 3 MB).
Wahrscheinlich wird jemand denken, dass dies irgendwie zu viel ist und mit den Händen hätte getan werden können. Vielleicht wird nicht jeder damit einverstanden sein.
Ich hoffe, dass jemand anderes ein fast körperliches Bedürfnis hat, sich an Arbeitsplätzen, fast zu Hause, wohl zu fühlen, und die Werkzeuge erlauben es ihm. Nutzen Sie Ihre Gesundheit und vielleicht ist die Automatisierung bei uns!