babushka
1.0.0
Je n'ai pas l'intention de travailler supplémentaire sur Babushka (en fait, je ne l'ai pas fait depuis un certain temps).
J'ai eu l'idée et j'ai commencé à travailler sur le projet en 2009. À l'époque, Docker et même Vagrant n'avaient pas encore été conçus. Je voulais en partie construire une alternative plus simple et à petite échelle à des goûts de chef et de marionnettes, et en partie, il a commencé comme une expérience dans la mesure où je pouvais affiner un Ruby DSL et dans quelle mesure je pourrais m'y pencher faire un travail utile. J'avais une balle qui y travaillait et j'en ai appris beaucoup, et je suis fier du fait que le design initial s'est avéré son. Je suis moins fier de certaines parties de la mise en œuvre - Hoowee j'écrirai quelques morceaux de ce code différemment aujourd'hui - mais nous étions tous jeunes une fois.
Ces jours-ci, les choses sont très différentes. Avec les conteneurs modernes et l'immuabilité qu'ils fournissent, ainsi que des outils comme Terraform, Kubernetes, etc., Babushka et son approche basée sur la mutation sont assez datées. En fait, exiger un bon vieux Babushka pour un travail d'infrastructure sérieux aujourd'hui pourrait être considéré comme une sorte de signe d'avertissement.
Quant à la configuration d'un nouvel ordinateur portable et ainsi de suite, j'ai appris le long chemin qu'un script de shell stupide qui copie certaines préférences en place, exécute quelques commandes defaults write , et ainsi de suite, ainsi que quelques étapes manuelles, c'est beaucoup plus facile à entretenir. Plus un processus automatisé atteint un macOS, plus il est rapidement de la compatibilité, et en tout cas, la configuration d'une nouvelle machine est un événement suffisamment rare pour moi qu'il ne vaut pas la peine de viser une automatisation parfaite.
Merci à tous ceux qui ont contribué et utilisé au fil des ans. Comme toujours, si vous souhaitez en faire usage de quelque manière que ce soit, allez pour votre vie - je n'ai tout simplement pas l'intention d'apporter des modifications à ce dépôt principal. Eh bien peut-être un jour de pluie, je vais refacter les morceaux poilus - nous verrons.
Bravo et tout le meilleur.
Babushka est un outil de ligne de commande pour automatiser les tâches informatiques. Chaque partie distincte du travail est exprimée comme une dépendance (DEP), qui comprend un test et le code pour faire passer ce test.
dep 'on git branch' , :branch do
met? {
current_branch = shell ( 'git branch' ) . split ( " n " ) . collapse ( /^ * / ) . first
log "Currently on #{ current_branch } ."
current_branch == branch
}
meet {
log_shell ( "Checking out #{ branch } " , 'git' , 'checkout' , branch )
}
end Ci-dessus, un DEP explicatif qui peut atteindre le but modeste d'être sur la branche GIT correcte (notez le paramètre indiqué par le symbole: branche). Il est construit en utilisant les deux mots DSL met? et meet , qui contiennent chaque logique de chaque Dep, séparant le test (la dépendance est-elle satisfaite?) Du code (respecter la dépendance).
L'exécution de ce DEP lorsqu'un changement de branche est requis montre comment Babushka fait son travail dans des blocs de Met / Mething / Met: un test d'échec, une action à l'aveugle, puis le même test, passant maintenant en conséquence.
$ bin/babushka.rb 'on git branch' branch=stable
on git branch {
Currently on master.
meet {
Checking out stable... done.
}
Currently on stable.
} ✓ on git branch
Si nous sommes déjà sur la bonne branche, le test initial passe déjà, et il n'y a donc pas de travail à faire.
$ bin/babushka.rb 'on git branch' branch=stable
on git branch {
Currently on stable.
} ✓ on git branch
C'est très bien pour une tâche isolée. Pour réaliser quelque chose de plus grand, les tâches doivent déclencher d'autres, c'est là que le troisième mot DSL requires .
dep 'on git branch' , :branch do
requires 'git'
# ...Avant que Babushka ne traite un DEP dans la mode Met / Meet / Met / Met décrit ci-dessus, toutes ses exigences sont traitées pour s'achever de la même manière. Cela reflète la réalité: demander si nous sommes sur la bonne branche Git n'a même pas de sens si Git n'est pas installé.
$ bin/babushka.rb 'on git branch' branch=stable
on git branch {
git {
'git' runs from /usr/bin.
✓ git is 2.3.8, which is >= 1.6.
} ✓ git
Currently on stable.
} ✓ on git branch
Le mot DSL complexe requires_when_unmet peut être utilisé pour spécifier les dépendances requises uniquement lorsqu'un DEP donné n'est pas satisfait, et qui peut être ignoré lorsque le DEP est déjà rempli. (Les outils de construction sont un bon exemple d'une telle exigence.)
Il y a d'autres choses à apprendre, comme les modèles de dépap, les sources Dep et les quelques mots restants dans le DSL de Babushka, mais ce qui précède en est la noix. Si vous chaîne quelques dizaines de dépassements comme celui-ci ensemble, vous pouvez provisionner un serveur à partir de zéro ou faire tout ce que vous aimez.
Il y a une documentation beaucoup plus détaillée sur le site Web, ainsi que la documentation par méthode qui peut être consultée ici.
Babushka est plus facilement installée à l'aide de babushka.me/up , un script shell qui installe Babushka via Git (et ses dépendances, Ruby et Git, via le gestionnaire de packages de votre système si nécessaire). Il est sûr de fonctionner sur les systèmes existants et destiné à être utilisé comme première commande de shell sur un nouveau système. Vous pouvez installer Babushka de cette façon en utilisant curl ou wget :
sh -c "`curl https://babushka.me/up`"
Si vous préférez vous installer manuellement, tout ce que vous avez à faire est de cloner le repo git (ou d'extraire une archive de celui-ci) et si vous le souhaitez, liez bin/babushka.rb dans votre chemin comme «Babushka».
Consultez la documentation d'installation pour plus de détails sur la personnalisation de l'installation, y compris le verrouillage vers des versions spécifiques et l'installation à partir de fourches à l'aide de babushka.me/up .
Babushka elle-même devrait fonctionner sur n'importe quel Unix; Il n'y a rien dans le cœur de Babushka qui nécessite autre chose que Unix, Ruby et Git.
Je développe Babushka sur macOS et je l'utilise principalement sur Ubuntu, donc Homebrew et APT sont les gestionnaires de package les mieux soutenus. Il y a aussi un soutien Yum (Redhat / Fedora / Centos) et Pacman (Arch), grâce aux contributions des autres. Sur d'autres systèmes, des opérations spécifiques (comme l'installation d'un package en utilisant le gestionnaire de packages de ce système) échoueront avec un message d'erreur, mais sinon Babushka devrait fonctionner correctement. Dans tous les cas, les correctifs sont les bienvenus.
Babushka profite de ces bibliothèques Ruby:
Merci beaucoup à tous ceux qui ont contribué à Babushka, que ce soit en soumettant des correctifs, en discutant des idées de conception avec moi, en testant ou en donnant leurs commentaires.
Une liste de contributeurs ici tombe inévitablement à l'écart - la page des contributeurs contient la liste complète. De plus, les engagements de version de version détaillent toujours ce qui a changé et qui a aidé dans leurs messages de validation.
Babushka est autorisé en vertu de la licence BSD à trois clauses, à l'exception de lib/levenshtein/levenshtein.rb , qui est autorisé en vertu de la licence du MIT.
La licence BSD peut être trouvée dans son intégralité dans le fichier de licence, et la licence MIT peut être trouvée en haut de lib/levenshtein/levenshtein.rb .
